There are two sides to an interview
and you're probably worried about the wrong half
I talk to a lot of software engineers who are gearing up for a job hunt. Sometimes they left willingly, sometimes unwillingly, and sometimes they just anticipate leaving soon. In all these cases, they tend to be primarily worried about how to best represent themselves: in resumes, in take-home tests, and in interviews.
Much of that concern is well-founded. Interviewing is notoriously imprecise, because humans are too complex to assess in 5 hours. And yet, you have no other option1: the metrics are narrow and simplistic, so they are easy to game, so you have to game them because everyone else is.
I find this focus on interview prep to be appropriate, but disproportionate. You should spend some time on self-presentation, and there are a number of resources I recommend for this. But if you spend all your time there, you’ll be in deep trouble when you get an offer. You need to determine which job would the best fit for you, way before any offers appear.
Short on time, short on data
That’s because when you get an offer, it will come with some time pressure; usually on the order of weeks!2 Your first order of business will be to inform other companies in the running that you’ve received an offer, give them a chance to expedite their process, and then complete that process3.
After all that, by the time you have multiple offers in hand, you only have a few days to decide between them. That is not enough time to both decide what you want and understand which of those offers is best for you. So let’s talk about how we can accomplish both of these earlier in the process.
Decide what you want
It’s tempting to focus solely on the compensation and title, because money and status are, let’s admit it, quite nice. But they are far from the only things that matter. Reflect, if only for a moment, on each of these:
Size or stage of company (How many rounds of funding? How many engineers? How many non-engineers?)
Remote/hybrid/in-person (also location, if hybrid or in-person)
Technology stack4
Product domain (e.g. finance, medicine, media, manufacturing)
Mission5 (For example, I’d have a hard time getting excited about high-frequency trading)
Following people you’ve worked with previously
Culture (e.g. collaboration vs. independence, wide vs. narrow focus, familiarity between coworkers)
(credit to Brian Mascarenhas for much of this list)
It’s very difficult for any of us to guess what makes us happy; we usually have to examine our anecdotal data to infer it. So when you scroll through this list of factors, don’t just ask yourself “Which of these sound nice?” Instead, try asking “In my career thus far, when have I felt most happy and fulfilled? During those periods, what was my job/company like?”6 For any factors that you don’t have any anecdotal data on, view your next role as an exciting experiment, and try to do something deliberately different than what you’ve done in the past.
Understand the job
Now that you understand what factors matter to you, let’s talk about how you assess each company, and the role you’d occupy within it. Remember that, since you’ll be short on time when the offer arrives, you need to understand the job before you get the offer. You might not be able to discover the compensation early in the process, but you can and must learn the rest.
Most of the factors listed above are easy to ask about but also easy to forget to ask about, so write them down somewhere7. Culture, on the other hand, is quite tricky to get a good signal on. The key here is to interview your interviewers with tough behavioral questions8. Deliberately construct these questions to make it easy for the other person to shed light on the factors that matter to you.
“Roughly what does the promotion process look like? Have you ever seen someone who struggled to get promoted, even though you thought they deserved it?”
“What’s the most painful or obnoxious part of your job?”
“How frequently do you collaborate with your teammates on a project? Can you give me a representative example of what that looks like?”
“What kind of critical feedback have you heard from your manager? How often does that happen?”
“What about positive feedback?”
“What about feedback you gave to your manager?”
“What’s a typical conversation that you have with a product manager over some feature you’re implementing or debugging?”
“Can you give an example of a time that a major part of the product failed? How did the company handle it?”
“What sorts of topics are typically covered during manager 1:1s, and in what ratios?”
If you have other fun questions to ask interviewers, let other readers know by leaving a comment!
Oh, and remember to ask the same question to multiple interviewers. If you get wildly different answers, that’s not exactly a red flag, but it’s definitely worth digging a bit deeper9.
You’re an interviewer, too
Having interviewed the interviewers, you’ll have a clear picture in your head of which job will best satisfy your needs. Compensation can be negotiated, but culture cannot10.
A ham-handed metaphor: it takes two to tango, and it takes a lot of time to learn to tango. Tango is just like signing a job offer (in this one very specific way). So take the time. Prepare yourself to be interviewed and to interview, and make sure to do both in every call.
Yes, OK, sometimes a company will give you a 20-hour project instead of an interview. Those give better signal, but I’m sympathetic to SWEs who don’t want to do those.
1-2 days is an unfair window, but 1-2 weeks is not. Have some sympathy for the company’s second choice, waiting anxiously by the phone.
I’m simplifying a bit, here; let me know if you want more detail about this process in another article.
It’s OK to avoid something you tried and hated, but don’t tunnel on the technology you know best.
As a very funny joke, my CTO in 2014 announced that our new company mission was “Maximization of shareholder value at all costs” before admitting that it was actually “Enable effortless credit based on true risk.”
If your answer is “This is my first job” or “I’ve always been happy” or “I’ve never been happy”, you can skip this section; there are plenty of other things for you to worry about.
I like Notion for this. (Notion is not a sponsor of this newsletter, but they could be if they want)
Incidentally, interviewing your interviewers is also a great way to demonstrate that you are a thoughtful and intentional engineer.
Maybe one team is managed well and another is managed poorly? Maybe the culture varies strongly by demographic? There are a bunch of possible explanations for this.
“This whole package is mostly looking great, but could the CMO be just a smidge less bigoted?”
Let me just call out Isaac Adam's great, recent article on a related topic: https://betterprogramming.pub/how-engineers-can-identify-good-and-avoid-bad-companies-d241b94ee2ff.
He gives an exhaustive breakdown of methodologies you can use to assess a company from the outside.
I always close every interview round with the question, "At this point, are there any concerns that you have that might prevent me from moving on to the next round in the interview process?" I love it for several reasons. 1, it's quite disarming. Folks don't usually expect someone to be so forward about the situation, and it invites a candid discussion. 2, it affords you early feedback. One of the worst parts about the interview process is that the interviewee rarely gets appropriate feedback during the process. 3, and arguably most importantly, if any of the feedback you get is negative, you have an early chance to address it before any mulling and review happens. You can clarify points that may have been misinterpreted. Conversely, if the negative feedback does not make sense, it may be indicative that the team you are entertaining joining is not for you.