back
174 comments
What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat.

The best interviews I’ve ever taken and in turn, host, are the ones where we break down a problem with low code, no gotchas, little examples of specifics just to make sure they know how to write it in language of their choice. That they understand the problem, can satisfactorily break it down into actionable tasks, and come up with a solution to the problem.

Everything else: tech stack, jira, agile, culture - is company specific and should be taught to your employees and not be made the bar. If you need someone who can hit the ground running you can focus on a tech stack but ultimately it’s up to you, the company, to ensure they fit. Not the new hire.

Yeah, I try and background check my interviewer thoroughly because of the “threat” issue. I always ask who will be interviewing me and look them up.

I specifically try and answer their questions and “hold back” a bit when answering if I can. I also sometimes will drop a nugget of knowing more and study their reaction. Some interviewers react quite poorly if you hint you know considerably more about a subject than they might want you to know.

I have friends with a lot more education than myself (PhD, masters, very senior) and they say they have to do this A LOT.

The goal is to see how the interviewer handles not being the smartest in the room about everything. This is a big deal because it can suss out whether the other person is “on good behaviour for the interview” but otherwise has an enormous ego during regular work hours.

No one wants to work for an ego maniac vetting out all the A+ candidates out of fear of competition.

I have done 300+ interviews in a 13 year career in FAANG companies and anytime I get a sense a candidate knows more than me, I get all excited and will work extra hard in the debriefs to get the person hired. If the spot is for my own team, even better ans will nudge my manager to hire the candidate. The prospects of learning from the person on the job is too enticing.
I never heard about having to do this during an interview, but it sounds concerning.

My advice would be to not play mind games and just interview as yourself. Interviews go both ways, so if your interviewer is a psychopath you'd want to know sooner. Then just give the job a pass.

> What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat.

Story time.

A few years back I was in hiring loops as an interviewer. Half a dozen engineers in my company interviewed a candidate during a morning. Everyone had their notes and we were discussing if we should hire the guy or not. Everyone gave thumbs up except one engineer. It turned out he tested the candidate on data structures and algorithms, and the candidate hadn't memorized the computational complexity of some bullshit algorithm that only shows up in lame trivia games no one cares about. Based in that, that particular interviewer gave thumbs down. We discussed everything, went through all notes, and ultimately based on all feedback the hiring leader gave a thumbs up. The data structures engineer threw a tantrum. In his opinion, we would be lowering the hiring bar if we hired a candidate that failed to meet his bar on what he felt were basic competences. The hiring leader asked how many times he used that algorithm in his everyday work. The data structures engineer answered that alas he never used it at all, but still he felt that everyone working in his org should know that.

I feel some companies don't have good hiring managers and give free reign to bad engineers who have no idea what it takes to deliver production code.

This personality defect is painfully common. They view themselves as "the bar."

It's always trumped up nonsense blown out of proportion. In one debrief, they made a stink because they botched an implementation of a red-black tree. it was the most pretty, trivial nonsense. The only time people are implementing red-black trees by hand are... when they're studying for our bullshit software interviews.

We also had a guy with a Ph.D in.. something. He wanted everyone to know he was very smart. Especially the interviewees. The problem he asked was so bizarre and complex that it took those of us already at the company several hours to figure it out upon giving it a try. it's just, like, dude, what is the point of what you're trying to do here? How small is your ego that you need to bully strangers on irrelevant nonsense?

That’s why you need experienced hiring managers. The questions should be discussed and approved before the interview. You just don’t let an engineer ask whatever they want. An interview plan needs to be shared to avoid overlapping questions or topics between interviews. In this particular example the hiring leader did the right thing, only after doing the wrong thing: not review or having an interview plan discussed beforehand and training the interviewers. The interviewing principles need to be clear to all your interviewers.
That is a major problem in interviewing. Everyone has their own set of internal guidelines!

I have worked on teams trying to improve our interviewing process, and one key goal was aligning everyone in exactly what technical and personal attributes we were trying to hire for.

Allow me to add.

“If you need someone who can hit the ground running…” then you need to have documented the crazy decisions that led to the awkward implementation that is your product. I have yet to meet a company who is using standard, recommended, tried-n-tested, well-known solutions to typical problems. Unless you write docs or stick to standards, no outsider has the context to “hit the ground running.”

Some people can still hit the ground running when there is a complex codebase with zero docs. They are just very expensive.
I've conducted hundreds of interviews and I agree about the tech stack, but disagree about culture.

Tech is usually easy to pick up, and highly company specific. Any good engineer should be able to learn new tech, and things will change over time.

Culture is much harder to "teach". For me testing for culture fit has become much more important than tech acumen, particularly at more senior levels. You need to have a sense of at least whether the candidate aligns with the company culture, and is willing to fit.

Not doing this risks several scenarios:

a) The candidate takes a while, but finally fits with the culture. This is suboptimal but ultimately a good outcome.

b) Candidate refuses to fit with the culture. This will likely cause performance issues, and the employee will ultimately leave or get fired. Not a good outcome.

c) Candidate actively subverts the company culture. This is the most destructive outcome and can be quite damaging, particularly at higher levels.

Checking that someone will be a good fit for the company is better for both the company and the candidate.

With most employees not staying at a job for more than two years, why wouldn’t you hire someone who can hit the ground running? If they spend six months doing negative work ramping up and leave in two years, your investment in them didn’t go far.

Yes, I know the answer is to keep them at market wages and don’t fall into the salary compression trap.

But often that isn’t under your control as a hiring manager. HR won’t give you a budget for raises. But will give you the budget to hire at market rates.

Personally I really dislike very specific questions you can Google an answer to in 3s and consequently no one remembers it while doing an actual job. IMO when it comes to verification of actual technical ability the candidate should be told an example of an actual task she/he would be expected to complete routinely and they should either do it during the interview or explain how would they go about doing it.
I’m not going to justify going in depth in topics not relevant for the job. However going deep in tech topics is necessary to evaluate experience and seniority. The “best interviews” process you described is adequate for the first eng levels but if you want to interview for senior, staff, principal; etc it gets harder and going into depth and breadth is necessary.

Heck. Sometimes going into topics “not relevant” for the job is revealing. If their cv says they spent 5yrs writing Linux dev drivers but the position is to write golang web services I may still ask about device drivers if I can get a domain expert. Good people tend to understand very well the things they’ve worked on.

> You need to be good but not too good you’re a threat.

I will happily hire someone who’s a threat to take my job. If I don’t, I can’t ever move up either.

> so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat

Maybe only about 10% of people who are sadists or calculating assholes actually follow that motivation? Unless you had a very special sample pool. Most interviewers i've met - both good and bad - were just trying to do what they think is right, with varying degrees of competence.

Yeah - my last interview was a bit like that. Uninteresting, lazy factorial question, some syntax bits on Python, can you list some canonical definition of object orientation, no probing at all on any topic of interest, and then a brief trivial squabble on what a list comprehension is.
This definitely rings true to me. We give an interview that’s basically a simple parser, and ask candidates to do it recursively(in Elixir) using function head instead of Enumerable. We link to the relevant docs and it’s a paired exercise with tests built in. It’s generally been a good predictor of candidates ability to work in our code base and collaborate. The whole thing can be done in 50loc and is not meant to be terribly hard.
> You need to be good but not too good you’re a threat.

For what it is worth; based on what I've seen in interviews. Programmers can only rank people who are close to their own level. If someone like Terry Davis of TempleOS fame shows up for an interview, should the interview declare them as a madman? a genius? both? If we need to build an OS, are his design choice eccentricities sly moves of genius or evidence of a diseased mind?

It isn't as much that strong programmers are a threat (that might be a factor) but more that big gaps in though lead to both productivity and inscrutability. And people avoid things they don't understand.

I find the author giving just plain bad advice.

"The tech stack in your CV should NOT look like this: [fig of bullet points of techs]"

Why not? In resume screening they look for keywords. You need to list the thing they want.

"If you have worked with a technology years ago, your experiences is not up to date anymore. Tech evolves so fast, and you get rusty and forget things."

This is a trope. Tech hardly move at all and it is way faster to refresh, dunno, 8 year old Java Spring experience, than learn it from scratch. The hiring manager might believe that you need recent experience though ...

A resumé is a tool for you to guide the interviewer, and you should use it for your advantage.

If you stuff your CV with a contextless list of random tech keywords, half of which are things you did a "hello world" with years ago, the interview is now a game of Russian roulette, and the gun is aimed at your face. Sure, you'll pass the resumé screening, but at what cost? You're leaving a lot to the interviewer's imagination, and what they imagine you should know is not necessarily what you know.

"So, your CV mentions you have MongoDB and DevOps experience. We're actually having some weird issues with it recently, it seems that under very intense loads, some of our nodes get locked and time out, and then the cluster loses quorum. Do you have any thoughts on what we could do?" It sucks to get a question like this, when all your previous experience in the matter is that you pressed the "create instance" button in the Atlas UI three years ago, and decided that was enough MongoDB-ing and DevOps-ing for a CV bullet point.

You can prevent this by showing those tech keywords in the context in which they're relevant. "Created and deployed an online application for candy bar enthusiasts, using React, NestJS and MongoDB on the cloud". Now you might get questions like "I see on your CV that you worked on an app for... candy bar enthusiasts? Could you tell me more about it?", or, "Your CV mentions that you built an app using MongoDB and NestJS, how was the experience of using MongoDB in a Node application?", which you are more qualified to answer. By adding relevant human context to what you did, you guide the interviewer towards the questions you'd want them to ask.

Listing all the tech you've worked with is pretty pointless in my opinion.

If you've learnt all that, you can learn to use more.

At most I would detail what you feel your expertise is and what other skills you have that the company is asking for. Have you programmed in C# for 5+ years and continue to do so? You might think you're really good at it, so make that point.

Did you use React for a little while and the job asks for that experience? Mention it.

Did you use OCaml 5 years ago and not touch it since? Probably don't mention it.

CVs should always be tailored for the job. It's not a life story, it's an advertisement. Car advertisements don't list page after page of tech specs. They focus on the key things they think are selling points. You should do the same for your CV and that will change depending on the requirements of the job you apply for.

Why not? In resume screening they look for keywords. You need to list the thing they want.

It depends if you want to work for a company that hires based on keywords on resumes, or one where the hiring manager reads and understands resumes. In my experience the second type of company is a lot better to work for.

> In resume screening they look for keywords. You need to list the thing they want.

I agree with this. One way or another, as an interviewer I need to know what your skill/experience set is. Skills/experience can always be developed, but that should be a known factor at the point of hire.

One positive point that TFA made was the need to 'Listen Carefully and Answer on Point'.

As someone who interviews regularly, I cannot count the number of times that interviewees have not followed this simple advice. To the question "Give an example of when you last frustulated a gibbet..." they will describe in detail their general thoughts on the many finer points of gibbet frustulation, but not actually give an example.

Also, be "Concise and Offer Details on Demand"

Top tip: when you have finished answering a question, stop answering the question.

> Why not? In resume screening they look for keywords. You need to list the thing they want.

If you’re an experienced developer and still randomly submitting your resume to an ATS instead of depending on your network you’re doing it wrong.

I have never in 25+ years across eight jobs randomly submitted my resume to an ATS hoping and praying someone would find it based on keywords. I’m much more strategic.

Yes, I’ve applied for (and currently work) for very large organizations.

Sure for a lot of jobs you have to submit your resume to an ATS to start the process. But I only do that as a perfunctory step after talking to someone who is already looking for my resume in the system when I submit it to start the process.

> This is a trope. Tech hardly move at all and it is way faster to refresh, dunno, 8 year old Java Spring experience, than learn it from scratch.

I last wrote a line of C# in 2020 after doing C# in for over a decade. But the last time I was in the weeds as a heavy C# developer was probably around 2018. Even in that brief amount of time, I know that the ecosystem has gone under changes and what are considered best practices have changed. More importantly, new features and frameworks have been added.

The advice on this is all over the place. It comes down to a matter of to whom you should appeal. Are you trying to pass an HR filter so that a human actually reads the resume or do you appeal to common sense and write a resume actually intended to be read by humans but immediately rejected by HR staff?
I agree. I’m a contractor and I feel the tech list allows the client to know upfront what I know out the gate and what I don’t. They can make an informed decision around who they want to get in for their project.
> Why not? In resume screening they look for keywords.

I think - what he meant was - only to include ones strongly applicable to the job.

The best interview that I ever experienced was when I applied for a Software Engineer position at VMware. The interviewers brought a laptop with an IDE and a project with a bunch of source code (based on one of their real in-house projects), and the task was to understand the exising code base and add a few new features to it. A real everyday task, no crazy algorithms or other menthal gymnastics.
Assuming an interview is a typical 30-60 min time slot is this actually a realistic ask? It seems pretty crazy to 1) get up to speed on a codebase and context in such a short amount of time to 2) then be able to actually develop against the codebase in a meaningful way to add more than one feature to it.

Can you share any additional details about what the process actually looked like or what type of task you were actually performing in the interview? Size of the project (~LoC), tech stack, complexity of the feature, etc.

Can be a fraught approach; interviewees could (and do) assume their answers will be used for production.
This is naïve and looks like the guy doesn't have all that much experience

"Good candidates now ask many diverse questions about the team setup, role expectations, challenges, the tech stack, career and mentoring opportunities, work times, etc."

And if the interviewer doesn't like these questions, because they have too much ego in this? Because I can't actually ask good questions because I don't have enough knowledge of the inside of their company (other than off the website, which is their public face so they're going to be distinctly partisan about how good they are), whereas they have a potted summary of me in front of them in the form of my CV?

Or if they out right lie about the tech stack, the "career and mentoring opportunities", how fucking bad the management is…?

Because this is exactly what happened at a number of companies I've interviewed for, and most especially the one I'm working for now.

My experience is you make yourself look cute and cuddly, don't challenge too much (eg. don't ask if they have an bug tracker because often they don't[1] and they'll get irritated).

Great advice for an ideal world, not this one.

[1] And if you find out they do have one, especially don't ask if they actually use it.

The flip side is 'do you want to work for someone who's ego is so fragile that asking a couple of questions might tank your interview'?

Maybe you're OK navigating around that person, but many are not, and I'd rather not have to bother.

Yeah, there's only so much you can glean, but just like they're looking for red flags from you, you're looking for red flags from them.

Sounds like you've had some rough interviews. I think you're also right, though; it is generally rough out there these days.

At the same time, the "candidate asking questions" portion is 10 minutes if you're lucky, and it's between two strangers who've known each other for maybe 45 minutes up to that point. It's understandable why the interviewer might give canned answers.

I think it's still worth asking the questions. The Joel Test [1] may be older than many candidates these days, but a large number of companies still fail most questions.

For the trickier questions, I think you have to read between the lines and look at what's not said. If you ask about work-life balance and the interviewer gives a little "hah" before answering — well, there's your answer. If you ask about the build system or deploy process and they keep hand-waving — well, they're still telling you something very important about the engineering culture.

[1]: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

I would actually argue that the best jobs are rarely advertised or filled through traditional interview processes.

In my experience, building strong relationships and networks within the industry has been far more effective in securing meaningful employment opportunities. Rather than focusing solely on perfecting your interview skills, I would encourage folks to prioritize developing their network and cultivating relationships with potential employers.

That's completely true! But... that can make it very hard. I personally struggle a lot with socializing and networking for personal reasons. However, I would say I definitely have useful skills and would consider myself very employable. But I simply cannot compete with someone who has better social skills, regardless of skill level.
You're probably not going to walk into a 450k/yr job through networking and connections - just saying. Those will require a traditional interview process, I can almost guarantee it.
> First, you need to understand how a hiring manager approaches an interview.

I stopped reading there. Does the author know before your resume even gets to an interviewer that it will go through keyword screening software then be reviewed by HR and binned, all long before a hiring manager sees it?

I've worked at dozens of companies, startups and big tech, none of them used keyword screening, none of them got reviewed first by HR. I'm sure it happens at some places but certainly it's not 100%.
I can honestly say that I have never once worried about keyword screening software. I don’t blindly submit my resume.

But even if that’s the case, I’m still going to use keywords as part of the narrative.

“Using <technology> accomplished <result>”

On my resume, I use English descriptions of what I did to develop business-level features. At the end is "Keywords: Python, AWS, Kubernetes, Terraform" for the keyword screening software.

A human can see I learned different tech for each job, and other tech has been mastered and is re-used over the years.

Talking about your family is way easier when you're a heterosexual married couple with 2.5 kids and a dog.
We are told at BigTech interview training that if a candidate starts talking about any area that is protected, immediately change the subject.

But when I was interviewing at your normal corp dev or startup, I would purposefully try to squeeze in tidbits about my personal life to hint at how important I found work life balance so companies who didn’t respect that would filter me out.

on the flip side (if you're not), the talk is much more interesting and memorable
How much XP does it take to become a rockstar coder, Philipp? Is CEO a class we can spec into or a race?

This misapplied market research that tries to make jobs "cool" (upskill!) gives me powerful Ballmer "I love this company" vibes.

It seems like these days unless you have 8yrs of experience it's impossible to even be considered for these interviews.

Once you get them, unless you've been perpetually practicing for a year or more the odds you pass are slim to none.

From the language they use, it sounds like they're trying to attract kids, or at least people who would unironically identify as "Gamers".
> You need to be good but not too good you’re a threat.

Even worse for CTOs. If you make the development look too easy your CEO will wonder what you even do.