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
Yep. I didn't even "pass" some of the coding challenges despite hiring, firing, and writing coding challenges myself!
What I often saw was many of those jobs were sitting on the market for months and months just getting relisted every few weeks. The ones that actually led to interviews, I had one dipshit proudly tell me about his 2-hour commute five days a week. Another told me they wanted to vomit-out mini-MVPs and were replacing the new guy who wasn't doing it fast enough. Just an ocean of fake jobs and awful jobs lol.
I had a coding challenge where if you didn’t implement what was essentially a Set in the exact way that they expected, you couldn’t proceed since the evaluation assumed you’d match their ordering (which was arbitrary). One of those automated test things and there was no way to contact a human and say, your process is broken. I’m eagerly counting down the days until I can retire. Between broken hiring processes and the rise of LLM coding, I’m left wondering if this is how I want to spend my precious time.
The cynical mind would assume that would be an excellent way for a corporation to rig the hiring process by preventing American qualified applicants from progressing and therefore making a claim that foreign labor must definitely be imported at a fraction of the salary and under visa-indenturement who … wouldn’t you know … magically happen to know the answers and pass the very arbitrary coding challenge somehow.
The only way this gets solved is by making any and all H-1B hires require the hiring corporation pay a 200% tax in addition to all other employment related taxes for the absolutely necessary and critical H-1B talent.
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've been interviewing the last few months after having had the same leadership role for 7+ years and never really having interviewed before. Your point about maintaining interview-readiness is something everyone should tattoo on their arm. I wish I had kept a log of accomplishments, projects with associated tradeoffs, anecdotes, etc. I've been polishing my interview responses and sometimes I remember something I had done that would have been great to bring up in an interview but I hadn't thought about in years.
And to add on - not directed at you more to other people where this isn’t crystal clear - neither you nor I said to be “interview ready” means “grinding leetcode so you can reverse a btree on the whiteboard”.
You and I are both basically referring to being able to describe accomplishments, challenges, and results in STAR format.
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.
- 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.
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.
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.
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. 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.
> 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).
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.
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.
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.
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.
By "trick question", people usually mean the questions that won't occur in real job. This does not seem the case here.
I have no idea what the OP's actual questions was, but as a made-up example: If the problem is solvable with static sqlite database copied to every node during deployment, but candidate suggests master-master postgres cluster instead, I would not want them. I shudder just thinking what kind of monstrosity they'd build if hired.
Maybe different people use the term differently? To me a trick question is one where answering it requires intuiting some specific secret to solving the problem. In this case, it would be intuiting that, unlike most interviewers, this one wants you to give a simple solution instead of showing off your knowledge of system design techniques.
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.
In this case, the most scalable is the simplest. Do the math on where errors can occur and accumulate, storage costs, latency, where rate-limiting can haunt you. The "throw in every feature you learned in certifications" will mess it all up.
> 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".
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'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.
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.
Or they just don’t trust the exam process. Lot of people with degrees and certifications but no idea. And people with no certifications and great skills.
They’re looking for both. I’m just saying compress the Leetcode rigmarole to a one-time certification exam and then save the interview for the specific people questions. Like how other engineering disciplines do it.
The one time I took a bunch of tests was out of school for a government job--which I didn't take because it was the lowest of my offers.
I do think the unsatisfactory (to many people here) answer is to assume that if you graduated from the right schools you're probably OK with respect to certification.
Ultimately the status quo of getting bombarded with Leetcode rounds every time you want to switch jobs seems untenable, even if in theory each round should get easier with the grind.
What happened to DRY. Just take it once and have it be recognized by all.
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?
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.
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.
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.
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.
almost, what you're seeing there is the too cute by half smug nugget of wisdom tone, which is really the trademark of the self-styled "writer", but because self-styled writers wrote most of the internet it has reflected onward in becoming the trademark llm tone. but there are still og hacks in the game!
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
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.
Yep. I didn't even "pass" some of the coding challenges despite hiring, firing, and writing coding challenges myself!
What I often saw was many of those jobs were sitting on the market for months and months just getting relisted every few weeks. The ones that actually led to interviews, I had one dipshit proudly tell me about his 2-hour commute five days a week. Another told me they wanted to vomit-out mini-MVPs and were replacing the new guy who wasn't doing it fast enough. Just an ocean of fake jobs and awful jobs lol.
I had a coding challenge where if you didn’t implement what was essentially a Set in the exact way that they expected, you couldn’t proceed since the evaluation assumed you’d match their ordering (which was arbitrary). One of those automated test things and there was no way to contact a human and say, your process is broken. I’m eagerly counting down the days until I can retire. Between broken hiring processes and the rise of LLM coding, I’m left wondering if this is how I want to spend my precious time.
Greatly enjoying working on my own software for now!
Any tips for doing that and making money?
The cynical mind would assume that would be an excellent way for a corporation to rig the hiring process by preventing American qualified applicants from progressing and therefore making a claim that foreign labor must definitely be imported at a fraction of the salary and under visa-indenturement who … wouldn’t you know … magically happen to know the answers and pass the very arbitrary coding challenge somehow.
The only way this gets solved is by making any and all H-1B hires require the hiring corporation pay a 200% tax in addition to all other employment related taxes for the absolutely necessary and critical H-1B talent.
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've been interviewing the last few months after having had the same leadership role for 7+ years and never really having interviewed before. Your point about maintaining interview-readiness is something everyone should tattoo on their arm. I wish I had kept a log of accomplishments, projects with associated tradeoffs, anecdotes, etc. I've been polishing my interview responses and sometimes I remember something I had done that would have been great to bring up in an interview but I hadn't thought about in years.
And to add on - not directed at you more to other people where this isn’t crystal clear - neither you nor I said to be “interview ready” means “grinding leetcode so you can reverse a btree on the whiteboard”.
You and I are both basically referring to being able to describe accomplishments, challenges, and results in STAR format.
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.
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.
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.
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.
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. 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.
> 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).
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.
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.
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.
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.
By "trick question", people usually mean the questions that won't occur in real job. This does not seem the case here.
I have no idea what the OP's actual questions was, but as a made-up example: If the problem is solvable with static sqlite database copied to every node during deployment, but candidate suggests master-master postgres cluster instead, I would not want them. I shudder just thinking what kind of monstrosity they'd build if hired.
Maybe different people use the term differently? To me a trick question is one where answering it requires intuiting some specific secret to solving the problem. In this case, it would be intuiting that, unlike most interviewers, this one wants you to give a simple solution instead of showing off your knowledge of system design techniques.
Every time they complexify it, they add latency, storage costs and probability of failure. It's all easily quantified.
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.
In this case, the most scalable is the simplest. Do the math on where errors can occur and accumulate, storage costs, latency, where rate-limiting can haunt you. The "throw in every feature you learned in certifications" will mess it all up.
> 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".
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'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.
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.
I assume the alternative is that you give some standardized "civil service" exam.
Honestly if it’s an exam you only take once or once every decade it’s an improvement over the current system.
I can't speak to developer exams so much but companies are often looking for specific people who aren't well categorized by standardized exams.
Or they just don’t trust the exam process. Lot of people with degrees and certifications but no idea. And people with no certifications and great skills.
They’re looking for both. I’m just saying compress the Leetcode rigmarole to a one-time certification exam and then save the interview for the specific people questions. Like how other engineering disciplines do it.
The one time I took a bunch of tests was out of school for a government job--which I didn't take because it was the lowest of my offers.
I do think the unsatisfactory (to many people here) answer is to assume that if you graduated from the right schools you're probably OK with respect to certification.
Ultimately the status quo of getting bombarded with Leetcode rounds every time you want to switch jobs seems untenable, even if in theory each round should get easier with the grind.
What happened to DRY. Just take it once and have it be recognized by all.
Highly related and high quality thread https://news.ycombinator.com/item?id=45064284. Several actors describing how it works in auditions among other great insights.
I wonder if it was the inspiration for OP.
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 decided a while ago to train for the job and not the test.
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.
Anyone capable of writing this and defending it is overqualified, but I would want to hire them, anyway.
Honestly, I’d rather just be true to myself.
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.
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.
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.
Half of the interviews out there are designed to be gameable enough to block out US citizens at will in favor of visa holders anyway
As long as you keep telling yourself that instead of honing your skills, passing an interview will continue being a struggle.
[dead]
Is that why my chair feels like a casting couch and I feel very dirty afterwards?
not accusing the author, I agree with the article, but whenever I read prose like:
"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.
almost, what you're seeing there is the too cute by half smug nugget of wisdom tone, which is really the trademark of the self-styled "writer", but because self-styled writers wrote most of the internet it has reflected onward in becoming the trademark llm tone. but there are still og hacks in the game!