You're Not Interviewing for the Job. You're Auditioning for the Job Title

I haven't interviewed for a job in many years, but on a whim, I decided to pursue a new role. I made it to the final interview with senior executives and was expectedly grilled about my qualifications. During the interview, I described several projects I worked on from start to finish, covering all stages such as gathering requirements and architecture. However, I received feedback that it seemed I had taken on too much responsibility, making them unsure of how much I actually contributed. Yes, totally agreed.

I was 14 years in a job at senior level and got laid off.

And yeah, it's pretty much as bad as you describe.

Why did you design it that way then? Actually asking, not taking the piss.

It is the natural result of an industry where:

- There are low barriers to entry (education is not required, profession licences is not a thing, etc.)

- A strong culture of "job hopping" has emerged, which means companies are continuously interviewing candidates, and candidates are continuously looking for jobs.

- A big willingness to sacrifice the false positives, for the sake of keeping out the false negatives. Basically companies will increase the threshold/bar to keep out the "fakers" and bad hires, even if it means rejecting legitimate hires. The mantra that it is very expensive to hire the wrong people rings throughout the industry, and has for the past decades.

- Candidates are willing to play the game. Some people are willing to grind leetcode questions for months, years, if it means they get a shot at big tech companies. Smaller companies cargo cult.

In the past 10 years and I was already 40 years old in 2014, I’ve interviewed:

- at a company where they launched a new division in a satellite office in another city to separate the team from the old guard to create a “tiger team” of experienced developers. I was the second hire. I just spoke to the manager as an experienced professional and we talked about how I solved real world problems

- a new to the company director who needed a lead software engineer to integrate systems of acquisitions that the PE owner was buying.

- the new to the company CTO after the founders found product market fit and wanted to bring technology leadership into the company from a third party consulting company. I was eventually tasked with making everything cloud native, scalable, resilient etc. I was his second technical hire. Our customers were large health care companies where one new contract could bring in 10K new users and even more ETL integrations. He knew I didn’t have any practical AWS experience. He later told me I seemed like a smart guy and I could figure it out.

- AWS itself in the ProServe division - 5 round behavioral interview where I walked through my implementations.

- (2024) third party cloud consulting company in a staff role. They asked how would I architect something and I made sure I hit all of the “pillars” of AWS Well Architected and talked through 12 Factor Apps.

I’m 51 and I stay interview ready. My resume and my career documents are updated quarterly and I keep my network warm.

I believe right now if I were looking for a job, someone would hire me quickly if not for a permanent position, at least I could hustle up on a contract.

In general:

- At a large tech company, a referral can help you get an interview; it rarely affects the actual hiring decision or the offer.

- As an interviewee, I might feel like I did great, but I don’t know what signal the interviewer wanted or what their bar is for that level.

My son’s school uses an adaptive test three times per year (MAP Growth). It’s designed so each student answers about 50% of the math questions correctly. Most students walk out with a similar perception of:

- how hard the test was, and

- how well they did.

Those perceptions aren’t strongly related to differences in their actual performance.

Interviews are similar. A good interviewer keeps raising the difficulty and probing until you hit an edge. Strong candidates often leave feeling 50/50. So “I crushed it” (or “that was brutal”) isn’t a reliable predictor of the outcome. What matters are the specific signals they were measuring for that role and level, which may not be obvious from the outside, especially when the exercise is intentionally simple.

Many years ago, when I interviewed at an investment bank for a structuring role, I answered all of their questions correctly, even though some of them were about things I'd never heard of (like a 'swaption'). I answered at what I thought was a reasonable pace, and only for one or two questions did I need a minute or two to work out the answer on paper. At the time, I thought I'd done well. I didn't get the job. I now know more about what they were looking for, and I'd say my performance was somewhere between 'meh' and 'good enough'. I'm sure they had better candidates.

When I interviewed at Google (back in 2014), I was asked the classic https://github.com/alex/what-happens-when question. I didn't know it was a common question, and hadn't specifically prepared for it. Nonetheless, I thought I crushed it. I explained a whole bunch of stuff about DNS, TCP, ARP, subnet masks, HTTP, TLS etc.

I said nothing about equally important things that were much less familiar to me: e.g. keyboard interrupts, parsing, rendering, ...

Luckily I passed that interview, but at the time I thought I'd covered everything important, when in reality my answer helped show the interviewer exactly where the gaps were in my understanding.

One of the worst things about the employment market in the US is that you almost never get accurate feedback about how well you actually performed. The reasons for this are of course legal (i.e. the company doesn't want potential liability in case the rejected employee uses the feedback to sue), but it is one of those things that work out against job seekers in a major way.

I mean, you know that the answer the interviewer was looking for was "use a trie/prefix-tree, want me to implement it", not "that's not my job, ask another team to setup elasticsearch".

If you're going to do coding interviews, you can say "I would use X tool", but you can't _just_ say that, you also have to say "but if I can't, I would write X algorithm, should I write it?"

Also, based on your description, you're suggesting going from entirely client-side, to having a server round-trip, to make it more performant. I could be misunderstanding the full question and context though.

I'm with you on this as an interviewer but as an interviewee have had interviewers who clearly didn't like it when I did this or even started to get impatient when I called out different problems than they cared about. There is a really terrible feedback loop around interview expectations.

Isn't that just another kind of trick question? It seems like that relies a lot on the interviewee guessing that you aren't looking for a standard complex solution.

Thank you! What are the right questions for a candidate to ask?

As a candidate, I feel that I should ask the interviewer if they're seeking a simple solution or a very scalable one. In this way, I can try to tune the response to the specific interviewer's expectations.

The problem is you want a proxy for that which you really can’t evaluate and you think the proxy is accurate because it provides some feel-good binary.

Fundamentally, you can’t really figure out the things you are interested that way. This is the underlying problem with tech and CS bros which results in the broken system being even more broken.

If anything these types of interviews are really only to validate the interviewers bias which is that they think they are smarter than everyone else and anyone else that came before them. Otherwise why would they have been entrusted to being the gatekeeper of shiny job and privilege to work along the interviewer.

One may as well just defer to SAT scores, GPA, or the fact that a person actually graduated from a reputable CS program, or dare we say, the fact that a person actually had the same or similar jobs successfully over many years.

The reason people bomb these are precisely because they don’t need to exercise that “deep knowledge” that often in the first place. It doesn’t mean they aren’t capable it just means they’ll need to walk thru it longer than possible in a contrived situation. And the fact that they haven’t needed it is telling —these jobs aren’t really hitting the edge of CS research; it’s just a CRUD app.

The autists need to get off their high ponies and look at every other professional industry out there. Those industries have smart people too. Somehow humanity survives and the industry evolves…go figure.

The interviews are wrong. Check with your favorite frontier LLM. There has been a lot of research on what's predictive for job performance and what's not, but it's largely ignored.

An easy example: Google's "Project Aristotle" - https://psychsafety.com/googles-project-aristotle/

tl;dr: psychological safety was the determining factor of highly effective teams. Then Google goes and does large-scale layoffs. Think about your workplace, do you feel safe? Do you think these interviews help people feel safe?

> Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem.

Eh, no it doesn't? I guess it's one of those questions - what makes a good software engineer - that people will never universally agree on like many other topics in the field but still think their own truth is universal.

>Yes - that means regardless of seniority, I expect you to know CAP theorem. Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem.

There are lots of good engineers who don't encounter this, but who will understand the CAP theorem to the same level you and most other people you consider "good engineers" do, after simply reading the top of the Wikipedia article about it. Ultimately you need to be the kind of person who can understand such a thing to be a good engineer, not someone who knows any particular random thing. On the other hand I would like to know that the candidate knows the CAP theorem if we are working on a distributed database or massive web service. In that case it is actually relevant.

>Every few weeks, someone posts an article about how broken tech interviews are, and the articles always follow the same formula: but I’m really good at REAL engineering… it’s the INTERVIEWS that are wrong!

Interviewing is mostly a different skillset from day to day work. That is why everyone complains about it. Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview), is hella frustrating. If you urgently need a job, it is even worse.

The way it was explained to me many years ago is that a bad hire can cause tremendous damage that goes above and beyond the harm of inadvertently missing out on a good hire. I've never really thought about whether that is true, but it is undoubtedly the reason why so many companies are risk-averse in hiring decisions.

I assume the alternative is that you give some standardized "civil service" exam.