And most of the steps in the interview process are not even technical (depending on the company), so most of your final score probably comes from your sales presentation^W^Wcommunication skills.
It's been 10 years since I did an interview and I think I would rather retire and grow rare lizards than jump through the interview hoops at a new company. I am 90% sure I couldn't pass the interview for my current position but I'm the one who designed the whole thing. -staff level backend engineer
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.
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.
- 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.
If you play the game too much, you risk ending up on teams full of “senior software architects” with 20 years of experience in event-driven microservices with TDD + CQRS + AI.
Or these days they’re probably vibe coding and writing RFCs with emojis.
Being true to myself has never paid a single bill or supported my addiction to food and shelter. I’m 51 and play the game with the best of them including the banal “thought leadership” bullshit.
Ha. I like to give a systems design scenario that rewards simplicity. Candidates who complexify it (usually in very predictable ways) get rejected. The few who see the simple path have been great hires. Because they also asked the right questions.
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.
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.
I had almost this exact interview experience recently with a popular AI startup. The exercise was to build a search UI over a static array of dictionary terms. It was a frontend role so I wired it up with filter and startsWith and spent more time polishing the UI and UX.
The final interview question was: “Okay, how do you make this more performant?” My answer was two-tiered:
- Short term: debounce input, cache results.
- Long term: use Algolia / Elastic, or collaborate with a backend engineer to index the data properly.
I got rejected anyway (even with a referral). Which drove home OP's point: I wasn't being judged on problem solving, but auditioning for the "senior eng" title.
With candidate interview tools and coding aids increasingly hard to detect in interviews, this gap between interview performance and delivering in the role is only going to widen. Curious how many of these "AI-assisted hires" will start hitting walls once they're outside of the interview sandbox.
> Next, you cover the whiteboard in boxes, arrows, and at least one redundant Kubernetes cluster. Add a message queue, Kafka obviously, regardless of whether you need one. Sprinkle in some microservices because monoliths are for peasants, and draw load balancers like protective talismans around every component.
Loved this. TFA is so true: interviewing is unfortunately a performance (for both sides, but mainly the interviewee).
You’re also likely not interviewing for what you’ll be doing if you get the job there anyways cause who’s got time to update the interview scripts, right?
I have interviewed many people. I have never once been impressed by someone figuring out a convoluted way to force a round peg into a square hole. The people I recommend are the ones who question why I would want to do something. If need be, I can always follow up with "but what if you had to do it this way." But for a question meant to evaluate technical ability, I am going to ask you how to do something which is a best practice. If I'm asking you how you would solve an absurd problem, the purpose of the question is to evaluate how you approach problems, and I will let you know that's the purpose of the inquiry.
I found the article’s premise intriguing. As I read through it, I noticed the author wrote:
> Hiring committees fear false negatives more than false positives.
If positive = a strong candidate, then a false positive = incorrectly labelling a candidate strong.
Conversely then I would think that a false negative = incorrectly labelling a candidate weak (when they were actually strong).
In my experience, hiring committees are more clear about who they don’t want than who they do. But there’s only so much insight you can gather from interviews. So when lacking more data, they are happy to pass over great candidates if that means their process avoids some bad ones.
It’s an imperfect system that optimizes for the employers’ convenience at the expense of the interviewer. So ‘auditioning’ under the circumstances is a great analogy.
If I were hiring engineers for a big company, I’d simply ask to see the interviewees’ chat transcripts with ChatGPT or Claude from the past 6 months. I can learn so much from that, for how they go about actual modern coding.
If I see them arguing with the LLM and nudging it to fix cases, I can see how they’d actually have to code, and the more nuanced their fixes the better. I can spot their attention to detail, how they think thru architecture and software design, the works. If they just take the code given and accept it, that’s a red flag.
If word gets out about how we interview, I’d simply ask for even older chats.
It’s funny to me that a lot of articles about how to more effectively undertake being a W2 wage slave come through a website dedicated to entrepreneurship.
If you run your own company (or even just your own small business) you don’t have to do this performative crap, and are actually economically incentivized and rewarded for implementing the practical and efficient solution.
Of course, there’s more variance. But there’s a special feeling when your name appears four times on your paycheck and you know you did a better job than others would have.
Great article!
My opinion: the ones interviewing you for a position should be the ones you will be working with from day to day. This way the both of you get to evaluate how you feel about working together. I have declined job offers where I didn't like the persons I was going to work with.
> This isn't malicious. It's structural, driven by several interconnected forces:
An additional reason is religion. People were told that these are the interview rituals you should do, they spent a lot of time rehearsing for it (to the exclusion of learning or doing useful things), and they think everyone should have to do it, or they are bad people.
An additional reason is that some people don't know much about the field, other than particular interview rituals.
An additional reason is that most people who know how to do their jobs, still don't know how to interview, so just mimic what they've seen.
An additional reason is justifying your existence/status. Sometimes, when I see a job description with requirements seemingly puffed up to sound impressive, I get the impression that it's not by someone who doesn't understand the role, but rather by someone who wants to make the role look impressive to their boss, for their own status or that of their team. Similar with interview practices.
An additional reason is frat hazing, for the sake of frat hazing. When easy upper-middle-class money entered the field, it attracted some baggery.
Not all organizations or interviewers have all the above reasons, but you can probably guess at least one of these is at play any time you get an ineffective/counterproductive interview "loop".
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!
It sounds like the author may have faced a bad interviewer, but I’d be curious to see their feedback on the author so we get both sides.
As I comment each time: you’re not being asked to sort a million item array because it represents the job, you’re being asked to sort a million item array because I want to see how you think, how you solve problems, and how good your underlying CS fundamentals are.
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.
The job will change from project to project, but the CS skills should carry through.
>>>Yes - that means regardless of seniority, I expect you to know CAP theorem
You can have the same result asking for a chess.com score. Anyone with score lower than 1400 is a bad engineer. I'm sure you'll have even better results than asking some CS theorems.
> The interviewer asked: "If you have an array containing a million entries, how would you sort the data by name?" [...] Surely the right answer was to explain why you shouldn't be sorting millions of records in JavaScript. Pagination, database indexing, server-side filtering. So I said exactly that.
> In real-world engineering, simplicity is king. In interviews, complexity is currency.
I am wondering if the best way to interview IT people is:
1. Give them an IQ test
2. Have a coffee chat with them about their experience and ask a few technical questions
If people are smart, and decent communicators and broadly have worked in the role you are looking for (doesn't have to be same tool) they will likely be fine. I don't think testing for coding skills is needed - but that's just my opinion.
> You're being evaluated on whether you can perform the role of someone who could theoretically build Google.
I can't agree with this enough. Companies want to believe they're Google or going to be Google. As a result they invest time, money, and engineers in problems they quite literally don't have and likely will never have.
> Then Drop the Act...
This, in my experience, depends. KPIs, goals, or whatever goofy games usually require the appearance of doing something impressive. Doing things that make sense isn't impressive.
Most corporate meetings are this way too. It's not about discussing how best to get things done. It's about performing in front of others. Human nature I guess.
38 comments
[ 0.25 ms ] story [ 66.5 ms ] thread- 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.
- 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.
If you play the game too much, you risk ending up on teams full of “senior software architects” with 20 years of experience in event-driven microservices with TDD + CQRS + AI.
Or these days they’re probably vibe coding and writing RFCs with emojis.
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 final interview question was: “Okay, how do you make this more performant?” My answer was two-tiered:
- Short term: debounce input, cache results.
- Long term: use Algolia / Elastic, or collaborate with a backend engineer to index the data properly.
I got rejected anyway (even with a referral). Which drove home OP's point: I wasn't being judged on problem solving, but auditioning for the "senior eng" title.
With candidate interview tools and coding aids increasingly hard to detect in interviews, this gap between interview performance and delivering in the role is only going to widen. Curious how many of these "AI-assisted hires" will start hitting walls once they're outside of the interview sandbox.
Loved this. TFA is so true: interviewing is unfortunately a performance (for both sides, but mainly the interviewee).
I wonder if it was the inspiration for OP.
"In real-world engineering, simplicity is king. In interviews, complexity is currency.
Job interviews aren't assessments. They're auditions for a job title: The Architect Who Solves Hard Problems™."
it just sounds so much like it's written by ai.
> Hiring committees fear false negatives more than false positives.
If positive = a strong candidate, then a false positive = incorrectly labelling a candidate strong.
Conversely then I would think that a false negative = incorrectly labelling a candidate weak (when they were actually strong).
In my experience, hiring committees are more clear about who they don’t want than who they do. But there’s only so much insight you can gather from interviews. So when lacking more data, they are happy to pass over great candidates if that means their process avoids some bad ones.
It’s an imperfect system that optimizes for the employers’ convenience at the expense of the interviewer. So ‘auditioning’ under the circumstances is a great analogy.
If I see them arguing with the LLM and nudging it to fix cases, I can see how they’d actually have to code, and the more nuanced their fixes the better. I can spot their attention to detail, how they think thru architecture and software design, the works. If they just take the code given and accept it, that’s a red flag.
If word gets out about how we interview, I’d simply ask for even older chats.
If you run your own company (or even just your own small business) you don’t have to do this performative crap, and are actually economically incentivized and rewarded for implementing the practical and efficient solution.
Of course, there’s more variance. But there’s a special feeling when your name appears four times on your paycheck and you know you did a better job than others would have.
An additional reason is religion. People were told that these are the interview rituals you should do, they spent a lot of time rehearsing for it (to the exclusion of learning or doing useful things), and they think everyone should have to do it, or they are bad people.
An additional reason is that some people don't know much about the field, other than particular interview rituals.
An additional reason is that most people who know how to do their jobs, still don't know how to interview, so just mimic what they've seen.
An additional reason is justifying your existence/status. Sometimes, when I see a job description with requirements seemingly puffed up to sound impressive, I get the impression that it's not by someone who doesn't understand the role, but rather by someone who wants to make the role look impressive to their boss, for their own status or that of their team. Similar with interview practices.
An additional reason is frat hazing, for the sake of frat hazing. When easy upper-middle-class money entered the field, it attracted some baggery.
Not all organizations or interviewers have all the above reasons, but you can probably guess at least one of these is at play any time you get an ineffective/counterproductive interview "loop".
It sounds like the author may have faced a bad interviewer, but I’d be curious to see their feedback on the author so we get both sides.
As I comment each time: you’re not being asked to sort a million item array because it represents the job, you’re being asked to sort a million item array because I want to see how you think, how you solve problems, and how good your underlying CS fundamentals are.
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.
The job will change from project to project, but the CS skills should carry through.
You can have the same result asking for a chess.com score. Anyone with score lower than 1400 is a bad engineer. I'm sure you'll have even better results than asking some CS theorems.
> In real-world engineering, simplicity is king. In interviews, complexity is currency.
Seems like a bit of a contradiction.
1. Give them an IQ test
2. Have a coffee chat with them about their experience and ask a few technical questions
If people are smart, and decent communicators and broadly have worked in the role you are looking for (doesn't have to be same tool) they will likely be fine. I don't think testing for coding skills is needed - but that's just my opinion.
I can't agree with this enough. Companies want to believe they're Google or going to be Google. As a result they invest time, money, and engineers in problems they quite literally don't have and likely will never have.
> Then Drop the Act...
This, in my experience, depends. KPIs, goals, or whatever goofy games usually require the appearance of doing something impressive. Doing things that make sense isn't impressive.