The salary range for my level at my company is like $70k - $198k. Problem solved.

Hopefully the ecosystem will put pressure on this kind of bull****. For example: I would not even apply at a place like that. For the most part if a company starts giving me the "what was your last salary" hassle and won't back down on it, the interview is over.

Not everyone has that option, I know. But if people see that they're losing out on potential hires because they want to game the system, maybe they'll do it less.

Butnahh is right. Today almost no one posts salary ranges. And if they do they're like suzzer describes and absurdly wide.

Had my first technical phone interview in a while yesterday and I bombed. It was an easy question and I just got stuck trying to work out kinks in an inferior approach and missed the the little bit of insight that leads to an elegant solution. Right after the call it came to me. Still beating myself up about it. Any advice to help me just let it go?

Even the best people will have hiccups. You stumbled a few times before you were able to walk.

I bombed several interviews and of course had my share of screwing up easy questions. Nothing you can do but to move on.

Just schedule more interviews. And practice coding on paper and using the coderpad while timing yourself. Speed and fluency comes with practice. Most interview coding queestions cannot be too complicated because of time constraints. I started to setup interviews. About 3 years since my last one, got 5 next week.

Update on my first-ever-job-search in case anyone's interested:

I'm invited to start working "on probation" soon (which is standard in my country), so, **** yeah!

Pretty tough to get everything set up with them though, they seem to be a bit overworked but I guess that can be construed as a good thing; they are about 20 people now and plan to hire about the same amount over the next year. I really like that they are (trying to) going places and it's not a static environment like a bank or insurance company or something. Also the boss is pretty cool and I'm emailing back and forth with him because the HR person doesn't seem to have the time, lol.

FWIW I wasn't asked a single technical "quiz" question in the application process, it's a junior (web) dev job but hopefully / seemingly not much front-end stuff, at least from what they described would be my first couple assignments (there is also no "web" in the job title). I did show them my code and answered why / how I implemented certain features, so they did kinda check that I'm not coding-illiterate, though.

I had this happen to me in my most recent interview cycle. It was not a complicated question really, I just missed something and afterward I saw it immediately. Bugged me really bad for a few months.

I also really badly bombed a live coding problem once. Again, a crucial thought did not occur to me until too late. In my case it occurred to me while I was still working, but it was too late, not enough time to get it running.

This is more about open-source vs closed-source that multipo vs monorepo, not that there isn't any correlation. Regardless, do you feel, for instance, that people having access to Linux source code but not Windows source code (and likewise for various open-source vs closed-source libraries) makes Linux programmer think badly? I think most people would rather not read other people's code and where they do, it's usually because they have a good reason - enabling them with open access often leads to a better ecosystem. I think you're also underestimating how brittle things like API specs are, especially at scale when you're in need of high reliability. For services, things like performance and reliability are often left unspecified - consider changing database systems and expecting existing queries to just work because they both implement SQL specs. Authentication and permissioning at scale are almost always a hairy mess and often require end-to-end control to properly handle changes.

A mult-repo system where people don't have access to other repos and what not (for no reason other than internal bureaucracy) leads to situations like this:

The way to get to the highest possible point is by empowering people and moving barriers and friction out of the way.

This is probably something that could be fixed with better tools, but for example, my editor of choice will scan from it's root directory and find all the code relationships. So if I'm looking at a function call and want to see the file where that function is defined, it's just a keystroke away

We use a multi-repo setup, but it's managed a bit like a mono-repo. We have some in-house tooling that we use. There's a "master" repo which defines clusters, and for each cluster, a repo per service. Each cluster is basically one json file that describes the names and types of the services in the cluster.

We use a tool to manage the repos - you can check out the whole enterprise, or a specific set of clusters, or even just a specific set of services. You can also update or check in at any of these levels.

In my editor I can load something at the service, cluster or enterprise level. Loading at the enterprise level means long scan times so I don't usually do it. Usually I am working on 1-2 clusters at a time, so I have one editor per cluster, and that seems to work OK.

The clusters share a common docker base container that contains a great deal of config, and our in-house common libraries. Each service will layer their custom bits of config onto that.

Probably the biggest PITA is that git grep doesn't work at the enterprise level - I mean, you can run it via our tool, but it's going to do a couple dozen git greps, one for each repo. Compared to doing a git grep on a real multi repo it's pretty slow.

I should also mention, this is tied into our build and deployment systems. If you add an entry to a cluster's json file, once you push that, it will
* create a git repo for your service, creating a directory and file structure that is appropriate for your service, with templated files
* create a build system for your repo that is set to automatically build, test and deploy whenever someone checks into your repo
* create a deployment system that will create an AWS cloud environment for your service and automatically deploy to it whenever a new build is ready
* create monitoring pages/rules in datadog that will produce alerts if the service (obviously) becomes unstable (you usually need to make more intelligent tests, this will just alert if the service is down or becomes unresponsive)

Creating a new service is literally a fire and forget procedure, and your new service will deployed and running within about 10-15 minutes after you add your entry to the cluster file.

This really encourages people to make new skunkworks projects as microservices. Before this system people would typically make a new test service by glomming it onto an existing one, because getting a devops guy to get your service up and running might take a day, if there was a devops guy with time. Periodically we reap services that were stood up and are not currently used.

no i didn't mean that by "unsee". it makes no difference you have access to the source code. what i'm talking about is either depending on what's supposed to be some internal implementation detail, or else, eg, adding an API call that you want because it's easy, when say the API has already been really well thought out and you don't understand the proper way to use it. whereas if the API is just the API, you have no choice in the matter. and that's a good thing most of the time. certainly if the API has been done well.

it boils down to a fundamental belief that if you just let people do whatever they want, you end with sloppy and entangled. whereas if you have good engineers who own projects, you might end up with something well designed.

Thanks for sharing - this is becoming a common setup these days and obviously better than having every team doing whatever they like but this imposes more structure than a straightforward monorepo IMO and results in very tight coupling. It's still going to be very difficult to change the meta-structure or boundaries. This includes both boundaries in terms of whether a given feature belongs in this service or another service and also whether something is an application/service-level concern or a system-level concern. Also, using templated files as opposed to a shared library for common functionality often leads to changing templates becoming the lowest friction way to provide new functionality or changed functionality without breaking existing applications. Over time, this means you have to support services that are stuck at every possible version of your template. I suspect that this will age rather poorly as the best practices for organizing large systems, orchestrating containers, etc, continue to evolve. Also, bespoke tools for this type of setup are typically not that robust, are usually subject to race conditions and often miss other edge cases.

Again, it's not that anything ages well in our industry and there are pitfalls everywhere, but just wanted to share some concerns in case people who haven't seen this kind of setup in the wild feel like it's some kind of holy grail.

By "template" I just mean that it creates essentially a stub service. If your service is an API, it will make the bare minimum (a health check endpoint that returns "I am up")

I would prefer it was a single repo, tbh. Our company has a pretty good argument for having like 5ish repos - we have some fairly distinct products that really don't share anything in common.

I wrote a service architecture someplace else, we used one repo, and basically which services would be available on any given server was a matter of configuration. This also meant we could hot-swap services without re-deploying. Need more of X and less of Y? Tell X to become Y. You can have a few servers of spare capacity ready at the drop of a hat to serve whatever endpoint needs extra capacity.

Because I tend to use one editor window per cluster, I usually have at least 3 windows open: 2 services and our core library that everything shares. Also, I will often have to wait for up to 3 builds to get something to prod, if I have to change the core library:
build core lib
build base docker image (includes lib)
build service (depends on base image)

It can get frustrating if I'm not sitting in front of 2 giant monitors.

Sure I think it's great to have well-thought-out APIs and not so great to have code that depends on undocumented implementation details but I don't see how this has anything to do with the number of repos. The only major sense in which it's related is that in a monorepo setup, when people do **** this up, you can fix it; in a multirepo setup, when people do **** this up, you may be stuck with the consequences forever. The only constant in our industry is that people do **** up and we should design our systems as to minimize the consequences. I'm sort of mixing trunk-based development and the monorepo setup together (the latter enables the former, but does not force it, as I think jj sort of pointed out in different terms) but it is actually the best way to avoid exactly what you're trying to avoid in the long run.

For example, there are all these crazy stories about how the design of Windows evolved around not breaking third-party software:

https://www.joelonsoftware.com/2004/...t-the-api-war/

It's important to see that the multirepo setup in this case, incentivized the original culprit to ship buggy code because it worked at that point in time and they weren't going to be held accountable in the long run. And it incentivized the API developer to ship the terrible workaround because because they had no way to correct the original broken code and they were going to be accountable for the original buggy code written by someone else if they didn't provide the workaround. The incentives are similar in a big company - I don't get to break client code written 3 years ago by someone who's not even there any more and pretend that well, it's not my fault, since it's not something I own. The monorepo (again along with trunk-based development and appropriate tooling) can save the day - you can just fix the client code, which lets you have the cake and eat it, nothing broken and no terrible workaround. If you're paranoid, the monorepo even allows you to enforce this exact thing in ways that's not possible in a decentralized multirepo system - you can search for client code that's doing things that it's not supposed to be doing to warn them ahead of time. If you have the blessings, you can even detect this programmatically and reject commits that are doing this.

Call or email them back with the answer and tell them it came to you. I did that with business.com. It was a random walk across a grid problem. I did ok in the interview, but didn't nail it. Went home and thought about it, sent in my answer. I got the job - although I may have gotten it anyway.

Europa - even in the US lots of jobs say you're on probation. I think you have to kill someone to not make it through the probationary period. The worst developer I ever worked with, who I literally think somehow scammed his way into the job - Catch Me If You Can style - sailed through probation.

Btw talk about typing speed - how about someone who can barely navigate around a computer? I knew that was a red flag. He was on a PC at work (we didn't have a choice back then). I asked him if he was a Mac guy and he said no. Unfortunately that one encounter was all I had and the other devs gave him passing grades.

Anyway - just have an open mind and realize that literally anything you learn, even if it's a bunch of how-not-to-dos will be valuable to your career.

Yeah I did this. Interview was Thursday and I didn't get a rejection on Friday so who knows. Fully expecting to get rejected next week, but we'll see.

Just hearing that this stuff happens to you guys makes me feel a lot better. I've got one more of these technical calls next week and a handful of take home projects to do. Not really looking forward to doing these but whatever at least I won't get randomly stuck on them.

Personally I don't think being able to perform in an interview situation is the most important quality of a dev. Although unfortunately usually it's all we have.

If that kid who was supposedly great, that we gave two chances including a cool down period in between, had emailed us a really good solution later - we might have hired him. Of course you have to worry a tiny bit about faking it. But if a lot of other signs point to a good dev - the odds of that are very low. No one even knew how the Catch Me If You Can guy got hired - except that our mostly useless head architect though he was great. The whole thing was really shady.

If you go home and figure out a problem, then send it in, that shows them a) you care about the job being offered and b) you might be one of those contemplative devs who need to think about things a little more, but often come up with the best solutions. The worst thing you could do in the real world is give yourself 7 minutes to solve a problem and run with the best thing you can come up with. *Good* technical interviewers should be aware of that.

When I got my current job, my boss told me he really liked when I said that some problems I need to go home and meditate on for a night.

Yeah it's kinda crazy. For me "on the spot under time pressure" solutions / fixes are not so bad, I usually can find something that works. The good stuff tho, that comes subconsciously while asleep! There's so many times I've woken up with some revelation how to re-architect something in a far superior method to the kludge I put in place the previous day / week / whatever. Not necessarily even sleeping, sometimes just doing anything else is enough to let the subconscious mull it over for a little.

It's sorta the opposite of "Don't think about elephants!".

Which is exactly why I emailed business.com. I wanted them to know I cared, and also I could come up with a good solution given a little more time to think about it. Seriously if a technical interviewer can't appreciate that, you don't want that job.

https://www.buzzfeed.com/craigsilver...ews#.vjY5LaVW6

Some things never change. The internet is pretty much all bull****.

It's also illegal to specify gender, age, distance from zip-code, and so on. It doesn't stop half the ads on indeed from suggesting and outright specifying all of that though.

The other day, I was asked that in a question box. I was half-tempted to link that article.

I know that many people do "practice interviews" where they apply to places they don't care about, then once they are feeling confident, they apply to places they do care about. The only time I really kicked myself was during interviews for jobs I really wanted.

In any case, I finally got an important clue about my struggle. This past weekend, I was doing an on-site contract tangentially related to programming. I got to talking to the owner about programming, contracting, interviewing, and so on. This was his feedback:

"Clearly, you are a nice guy, smart, and have an insane work-ethic. I'm pretty sure you'd be able to learn Node in two weeks and be just as good, if not better, than my guys. The problem is that I can't bring you in... you are completely burned out. I'm not even sure if you want to program anymore."

Basically, my take on contracting is that... I feel like I've been lied to. I'm good enough to fix all the problems, but I'm not good enough to create these problems? it's also just a ton of work, constant chasing down clients for status updates, unpaid invoices, and so on. I had to dump a client last week because she was just batty. I'm thinking of dumping off two more clients now. Granted, it pays a better hourly than digging holes, but I'd rather do an honest day's work now and then.

I told him that if I had to be honest, I probably wouldn't last two months on a full-time job programming, so he asked me if I'd be okay managing programmers. It wouldn't require any coding.

I don't even know what burn-out is, so it's kind of strange to hear that about myself, lol, but yeah, burned out. I suppose that's an apt description.

It most likely means that you have a pretty bad attitude, and TBH would explain a ton of the struggles you've described itt for years. You probably come off as the grumpy guy. Take it from the semi-grumpy guy who's always worried about crossing over to full grumpy. Never go full grumpy.

You should probably do some deep soul-searching about whether or not this career is for you. And if it is, dedicate yourself to work on your attitude. Start out by just faking it until you make it. If a grumpy thought comes up, suppress it. Try hard to come up with something positive to say. Eventually you should start a feedback loop that re-enforces your good attitude - and then you won't be faking it anymore.

Hopefully you have someone close to you that you can lean on for specific strategies and examples of the kind of behavior you want to change. On this topic, they know you much better than you know yourself. I have a therapist. But I also have some female friends that I've used as defacto therapists. Everyone's situation is different though.