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'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.
Do you think you’re a productive and valuable employee with marketable skills?
If the answer was yes, why do you think we’re in a situation where you need to dedicate that much of your own free time, sans compensation, just to make yourself attractive to companies so you can at best fall back on temporary employment?
I do not mean to attack you personally, but your comment is incredibly black pilling and dystopian to me. It’s seems like every year we are going to be asked to do more, get culled if we don’t, and half of the commentary from our community is about how you can avoid the yearly culling by working even harder.
The company gets a simple deal from me. They put the amount of money in my account they agreed to every month and in return they get 40-45 hours a week from me and all of my experience and skills.
They want me to fly out to a customer’s site or sit on a zoom call to close a deal? They got me. They want me to lead a large cloud implementation? No problem. They want a 50+ page management consulting style assessment with pretty diagrams? Say the word. They have a customer with an empty AWS account and they want someone who can do AWS architecture from the “DevOps” [sic] perspective and development? Say the word.
What they don’t get from me is burnout, time away from my wife and exercise in the evening, weekends or on call work. They get 40-45 hours of work from me.
It doesn’t take that much time to write down a summary of what you accomplished every quarter and keep an updated resume and in my case go on LinkedIn and post a banal “thought leadership” bullshit post once a quarter to keep me on the top of people’s mind if things go sideways at my current employer.
I would much rather be in my position where interviewing means some behavioral questions and talking to people than having to grind leetcode and reverse a btree on the whiteboard.
Respectfully, You are not putting in 40--45 hours a week if you are
>I’m 51 and I stay interview ready. My resume and my career documents are updated quarterly and I keep my network warm.
All of the extra bits of work you have to do outside of the 40-45 to stay "interview ready" count as work, youre just not getting paid.
Speak to other professional fields about the requirements they have for getting a job. Even in ones where there is an expectation of continuing education like for doctors, that is usually covered both in time and money by the employers of said doctors, not just something they are expected to moonlight on.
The other professions are even more agahst when they hear things like having to go through 10 round interviews or being grilled on the same set of college basics that dont get used in the day job, as a part of every single interview
At some point since the dotcom bubble, employers figured out a way to convince software engineers that since a bunch of nerds who were interested in this skillset as a hobby were doing it in their free time, the rest of us should be doing that too
How much extra time do you think it takes to summarize what you did at the end of a project? I do that anyway on the job during working hours to prepare for performance reviews and put it in our performance tracking system.
The banal “thought leadership” posts I’ve done on LinkedIn was also done during working hours. It’s encouraged at my level as marketing for the company and it also helps me.
I work remotely, do you really think I don’t do all this during working hours?
> Speak to other professional fields about the requirements they have for getting a job. Even in ones where there is an expectation of continuing education like for doctors, that is usually covered both in time and money by the employers of said doctors, not just something they are expected to moonlight on.
We get $1000 per completed professional AWS certification and a few others the first time and renewal and have time to study between projects. Even when I didn’t work in consulting and working in product companies - the last one as the lead architect - I took time during working hours to study.
You did see where I said I haven’t done a side project outside of work for my entire 30 year career?
> The other professions are even more agahst when they hear things like having to go through 10 round interviews or being grilled on the same set of college basics that dont get used in the day job, as a part of every single interview
My interview at AWS was one full day and five rounds of behavioral questions. But all of my other interviews were two rounds and then an offer. The last two companies I worked for before AWS, it was talking to the director and CTO about business outcomes and strategy and my previous experience. Do you really think high up people in their 40s are going to ask another 49 year old to balance an AVL tree?
Well then congratulations, you seem to have progressed high up enough in your career to not have to deal with that.
I have literally never had an interview process with a company consist of less than 4-5 hours of interview rounds or an equivalent sized take home project. Roughly 50-60 interview cycles over 12 years. That includes companies where I was referred in by the hiring manager.
Tell me about it. I'm in the 9th circle of interview hell and if I wrote a blog post about my recent experiences it would die as a [flagged] post because it seems too made up.
I just today spoke with a recruiter for a position that is 3 steps back in my career, but asking for more skills than I have.
The compensation is also going back about 5-6 years in nominal payment, not even accounting for inflation. It’s titled and compensated like what looks to me a 3-6 year in their career senior engineer working at a successful but not mag7 level company like a DraftKings.
They won’t even move to the first stage of the interview process until their CTO has personally read and approved it.
At this point I’m more mystified as to why everyone’s wasting their time like this on filtering. I can’t see a rational situation where it’s worth executive time to bother filtering for a role that’s so minor to the organization, but that’s the circus we’re in now so I guess I’ll jump through the hoops
> If the answer was yes, why do you think we’re in a situation where you need to dedicate that much of your own free time, sans compensation, just to make yourself attractive to companies so you can at best fall back on temporary employment?
Do you think good products just sell themselves? Do you think marketing departments exist because companies love to waste money? There's your answer.
Do you understand that what you're saying is that in order to be hired, you not only need all the skills needed to do the job, but also all the skills of a full-fledged marketing department, regardless of whether the job requires any of that?
Yes. Because knowing the job and showing people you know the job are two complementary skillsets. Spends some time working with technically-illiterate managers and clients and you'll see. Don't do it and you'll be left hanging wondering why people can't see your brilliance and competence.
I'm sorry you don't live in the world you'd like to live in but that's life. Been at this game for 25 years and it has never been different.
It’s about doing the work and telling people you do the work. It was never my intention to land in BigTech at 46. I was actively opposed to it because I didn’t want to move from my big house in the burbs and we were fine. I had spent the last seven years at startups leading projects and “transformations”, learning AWS and updating my LinkedIn profile. AWS reached out to me in 2020 (as has GCP since I left but I rather get an anal probe with a cactus than go to BigTech again and I’m damn sure not going into an office) and I said why not interview?
While I was there, I was building a network with coworkers and clients, learning how strategic consulting works on the highest level, contributing to an official very popular open source “AWS Solution” in its niche. Releasing my own open source solutions in their official repository, did a couple of blog post that are still on their website, etc.
When Amazon started Amazoning, I waited for my severance offer and had multiple job offers within two weeks with a $40k+ severance in the bank just by reaching out to my industry contacts I had made.
It may be bullshit. I might think gravity is bullshit. But that doesn’t mean I’m going to jump off of a 25 story building out of defiance. I play the game because I have an addiction to food and shelter.
How are employers supposed to know you're productive and valuable if you won't even maintain a decent resume?
Honestly you come off as whiny and entitled, everyone has to present themselves through a CV. If you want to stand out you need to put some work into it.
I work as a consultant/contractor, so I am actively encouraged to polish my resume during work hours. You could look into the same if you also want to be paid to polish your resume. I don't see why other kinds of employers would want you to work on it, the only thing you could use it for would be to leave them.
Maintaining a resume is burying the lede. Being "interview ready" in software means maintaining a separate set of skills that are rarely used in the day to day.
When companies are asking for people to reverse red black trees and then turn around and expect their employees to hook up wordpress sites, or build generic REST based CRUD apps, they are implicitly putting the burden of training on the employees.
I posit that the software field is one of the worst fields when it comes to this
I have never been asked to reverse a red black tree. Maybe they all do that in SV but in my corner of the world I haven't seen nor heard about anyone doing that. I've been asked to write a class to store Car objects and get them by plate number and some stuff like that. I've been asked to write a simple tax calculator with the specific tax rules and brackets provided.
I thought these were perfectly reasonable tasks, certainly within my capabilities. To me, being "interview ready" is simply being competent at my job. Nobody's expecting me to memorize obscure algorithms that I could just look up if I needed them. They're just asking me to demonstrate that I can solve a simple task by programming. That's totally fair, I wouldn't want to work with the people who went through 3 years of university (and even years of actual work afterwards) without learning how to solve these kinds of basic tasks.
I don't even remember what a red black tree is, I think they were covered in our DSA class but not much. Despite that I think I could give a pretty solid go at reversing one, given an implementation and maybe a summary of how it works. I wouldn't mind getting that task, sounds like a fun challenge. Maybe I'd complete it in 30 minutes, maybe I wouldn't, in either case I'm sure I'd be able to show that I'm pretty good at programming. That's all I've ever needed for my interviews. Haven't done an interview that hasn't resulted in a job offer.
Meanwhile I see all you people on the internet complaining that interviews are so unfair and require this "interview prep", so I'm left to conclude that either employers in my country are way less selective than they are in yours, or you're only applying to the most selective employers, or you're simply exaggerating the difficulty of the interviews. If you want to work at Google earning $500k then you're going to have to be exceptional. For everyone else there's plenty of very lucrative jobs that aren't nearly as hard to get. And if you can't even get those then maybe you're just not particularly good?
I’m not young or new to the industry. Not every place is this bad but it’s still highly common to get asked questions that seek to test out how many algorithms you’ve memorized.
This is not 500k/yr jobs but 150-250k year jobs where companies try to ape the practices of mag7 but fail at it because they are unwilling to implement fundamental aspects of those processes.
I also(until this current economy, lol) didn’t really ever have a problem crossing this barrier and getting jobs. But I still hate the extra effort needed and the extra hours of my personal life I have to sacrifice to brush up on or keep up to date on skills that the employers have, in my experience, never once had me use or even worse, blocked my efforts on working on tasks that would make use of the skill.
I grin and bear it because the moneys worth it but I think it’s inefficient posturing done to filter out social classes at this point, like how unpaid internships are used in the finance field
To be fair, $150k is still a very good salary. That's like 3 times as much as most other people make. So it seems to me like we're still talking about fairly high-tier jobs, where I live most developers make less than $100k. The only devs I know who make north of $150k are self-employed contractors which comes with a lot of downsides.
I can see how it might be frustrating to have to maintain a separate set of skills just for interviews. I just haven't experienced that myself.
High col area, was paying 3 grand per month before utilities for 1000 sq ft and rats. Surroundings are fun at least. 150k is well off still but not secure from financial problems after being out of work for even a few weeks.
Like I said, the moneys worth going through the hoops but it’s aggravating to go through them when I don’t think they are benefiting anyone, even the employer.
I also felt this way when I was on the other side of the table doing hiring mind you.
I explicitly said “being interview ready” for me was not doing coding interviews on the whiteboard. It was being able to talk about my past accomplishments and how I would benefit the company.
Yes I am self aware enough to realize that I have been able to avoid that because I was 50 years old when I interviewed last year, with industry experience, connections and AWS ProServe.
But on the other hand, cry me a river that younger developers must prepare for coding interviews for a few months and make $160k+ straight out of school. A former intern I mentored when they were an intern and when they came back is now 25 years old and making over $200K as an SA at AWS.
I am not at all bitter. I am happy for all of the up and coming fresh college grads I met when I was there.
While I have never been encouraged to work on my resume on the job, I have been paid to post to the company’s blog and various “thought leadership” posts to LinkedIn and at a previous company open source work.
While it was marketing for them, it also helped build my visibility
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.
Or just establish the H-1B salary by some third party through evaluating what similar positions pay in the most expensive areas of the US and making each sponsoring company pay whatever it costs to get that data.
There's many awful things, but HN who's hiring isn't one of them IMO. Because HN has maintained an image of being for "smart in the know" people and discussions despite being huge, connections fostered here tend to start off with a stronger weight than completely cold interactions, there's some minor level of inherent trust there.
I can't remember the last time someone didn't reply to me from here, but then again I choose my applications very carefully. You also get to meet a truly diverse set of people and opportunities rather than "more of the same".
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.
There is a difference between knowing how to find and use the ordered list of complexities for big O notation, and knowing these by heart. The difference is irrelevant when you design or code, but it’s important for interviews and exams.
> 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".
> 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.
I don't think it was money that caused this, but that many beloved tech giants were intentional built as fraternities by college dropouts and recent college graduates, many of whom did not themselves join a fraternity in college but got soaked in a lot of the atmosphere of them. It's most obvious in the case of Facebook, as publicly documented in things like the movie The Social Network, but it's a foundational DNA strand in Microsoft and Google and nearly any other big tech company that still prefers to call its headquarters/office park a "campus". (It's kind of a through line in the HBO show Silicon Valley too, how much tech companies intentionally copy the "pizza and beer and all-nighters and weird dorm room living" college vibe.)
(The presumption that most of these company executives never were themselves directly involved in college fraternities is that fact that they allow/encourage/build hazing rituals. Fraternities have had somewhat strict anti-hazing education requirements since the 1990s and most Universities have also had strict No Hazing Policies since around then. Since 2024, that education and policy enforcement has spread outside the Greek System to all students at most major Universities that get federal funding directly or indirectly, but before that it is certainly easy to understand how many might have missed the messages and education if they only saw fraternities from the outside.)
But the same kind of self-congratulatory exclusionary clique thinking behind frat pledging, and the same thinking behind the historical attendant hazing, could still be at play?
Not necessarily because company leadership and random interviewers are mindlessly mimicking what they experienced in school, but because some ideas tend to arise from power/privilege baggery.
(Though we also now have the mimicking of other tech companies, and we could just call it that, but "frat hazing" is still a better understood term, already with negative connotations.)
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.
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.
- 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.
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.
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.
> you think the proxy is accurate because it provides some feel-good binary.
Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities. If you prefer, there are absolutely companies that don’t use the process, and they’ll hire you after a quick resume conversation. Frankly, I wouldn’t want to work there, having seen the abysmally bad talent hired through lax processes, but Godspeed if that’s where you want to work.
> the fact that a person actually had the same or similar jobs successfully over many years.
No matter how good you think you are, if you can’t pass a basic live coding exercise, you have no place on my team.
…You’re not being asked to invert a binary tree in 20 minutes with your eyes closed, you’re being asked to traverse a string and use a set. Stop whining.
I think in reality though what you're doing is asking people to grind out puzzles until they're good. It's kinda like saying high math scores equal financial sucess. It is true in general but you're basically proxying hard workers not that the basics you test for are right. Getting an A in calculus doesn't mean that calculus helped you be a top engineer I bet most engineers would fail their old tests.
The leetcode interviews to me basically signal:
1. This person is of minimal intelligence required
2. They work hard
The real problem I have is that this system requires an endless calculus test requirement. Most proffessions have one big test to get in then you're basically done. Refreshers are given but once you pass that initial bar no doctor is required to pass their entire medical exam for every interview.
"Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities."
Genuine question; how do you know? Presumably you have some good feedback on the accuracy of your process when you hired the candidate, but do you have any measure of how accurate your process was on the ones you turned down? I'm sure some of the ones you turned down would have been bad hires, but some would have been good hires; is there a measure of that?
>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 number of times I've worked at places where the competent people likely could not pass their own interview questions if they hadn't thought of them themselves is too goddamned high.
I'm getting tired of having to coach other senior devs on how to interview like they mean it instead of like it's a drinking game.
Google has come right out and said that none of their interview strategies have made a statistically significant difference in employee outcomes.
> Interviewing is mostly a different skillset from day to day work.
It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.
There are plenty of places that have lower bars for hiring if you can call a JSON API in Python and run some Linux commands - but for the places everyone wants to work, you should expect a high bar. And that’s a good thing! A players want to work with A players. I would not want to work at a place that has a low technical bar for hiring.
> 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)
It goes without saying that interviewer successfully passed that interview process to get hired there. So they have demonstrated at some point that they can do the problems they’re asking you to do.
Blowing a technical interview sucks, I get it - I have blown dozens of them. It’s humiliating, I’m aware, and so people find all sorts of copes (I would’ve been better than my interviewer at the actual job if I had just been given a chance! They couldn’t solve that problem anyway!) but they don’t want people that can just do the job - they want really talented engineers that can grow with the company and build all sorts of things.
Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.)
And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.
>It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.
I don't write websites at all. I have had to deal with performance issues but frankly it is rarely a major concern for anyone. Furthermore, interviews don't resemble work, they resemble LeetCode or other competitions.
>Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.)
Having a degree and a long employment history implies that you are a good engineer more strongly than your performance on a random puzzle question. Most interviewers are not that good.
>And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.
Yes, these companies want a process that provides superior vetting compared to 4 or more years of intensive schooling, or else something so far out that it can distinguish among expert candidates (while taking no more than an hour). It's a stupid objective. Coding interviews should mainly determine if you lied on your resume or not. It should not be seen as a magic way to spot "good engineers."
If you want to filter out bad engineers, just ask them questions that you expect bad engineers to do badly. These are mostly design questions and not coding questions.
> Interviewing is mostly a different skillset from day to day work.
> It’s not, really:
Funny -- I'm halfway down the page now, and haven't seen your top-level post stating how and why the entire point of TFA is wrong.
> this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.
Yeah, that was the point: Most day-to-day jobs are writing basic websites without huge scale constraints (or equivalent), but interviews are usually conducted as if those huge scale constraints were relevant.
Do you have some particular reason to believe that most actual jobs do involve "real performance or scale constraints"? Or that interviews aren't conducted as if they did? (Or did I somehow miss the point, and that wasn't what TFA was all about?)
>>>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 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.
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?
So we’ll do both: have a high bar for technical interviews and a culture of psychological safety. That should be the best of all worlds and create a high performing team.
I’m not sure your point here. Yes, high performing teams have psychological safety.
> 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.
Those that don’t know CS fundamentals end up making bad technology decisions.
I can’t tell you the number of times I’ve failed a “senior” level engineer because when I asked, “Tell me why you chose X database on Y project,” the only thing they could come up with was, “Well, we were storing JSON data, so we used Mongo.”
I don’t want to be left cleaning up the mess that guy makes.
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.
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.
I always begin system design interviews by repeating and clarifying the framing of the question. Some simple ones: "what kind of service/website is this? what's our expected peak load today? 2 years from now? 5 years from now? [regarding data structures] what's the biggest value we'd reasonably want to store?"
You're backing into things like QPS, size of the data you're responsible for hosting, uptime requirements, real-time requirements, write load vs read load.
Often the natural walk is "let's assume it's a low load, design for that, and then we'll get to higher load at the end". Other times, it's an actual systems-y problem they're facing as a company, and that they have a putative solution to compare your knowledge against.
But yeah it is generally really important to codify and at least state (if not explicitly clarify) your assumptions before recommending a solution.
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.
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.
> 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 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.
The worst question I've been asked recently was how to make something robust.
When I started running down the laundry list of footguns with the basic solution, he clearly became impatient. I never did figure out what he was after, but I worry for the team.
> 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.
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.
It’s true if you’re a cutting edge company doing real R&D and parting with capital and agency to your workers as a result of it.
Every company whose CEO thinks he’s a mag7 but scoffs as paying more than >150k/yr to an engineer because that’s executive money that tries to ape that kind of risk management ends up with a hiring process that is optimized for rejecting people since their offered compensation will never meet the demand of people with the skill set they are looking for
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 almost like software wants to be a real profession when it grows up, like Doctor or Lawyer or Engineer. Doctors generally only take the one MCAT. Lawyers generally only take the one Bar Exam per state they expect to work in. Civil/Mechanical/Chemical Engineers only take the one FEng/PE combo of exams for their discipline.
It's fascinating how many people in the software industry want the title "Engineer" but don't want benefits of the title like standardized tests and ethics boards because they are afraid of standardized tests and ethics boards.
Outside of civil engineering PEs aren't common. There was one for CS but no one took it. PEs are mostly useful for people signing stuff off for regulators.
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.
1.) "Every time" is 10+ years apart for a lot of folks
and
2.) If you look at the requirements for things like PEs (at least the last time I looked at them), you have requirements like 4-year degrees, having worked under a PE for some number of years, etc. in addition to the tests, which I assume a lot of people here would object to.
1) Not so much in tech hubs, especially during the long boom of the last decade. And having to take the same test at potentially a dozen different companies every ten years is still a poor experience.
2) Surely an attempt at standardization in this industry, like the similarly hypothetical pipe dream of a widespread software tech worker's union, would include adapting to the unique characteristics and mores of the industry? There's no need to fully copy other disciplines' practices in complete detail. Though we should include the ring ceremony, that would be cool.
The whole point of this is that Leetcode has essentially become a de facto standardized test for many many jobs in this industry, and if we are to recognize that reality, we might as well make it DRY.
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.
...So anyone who coded on their own, you'd just reject out of hand?
And (granting, for the moment, your premise that everyone worth hiring used the LLMs) how do you know what they do with the code after they take it from the chat window? My limited experience with the code from LLMs is that there's only so much massaging it's worth giving it through the chat interface, and then you need to just take it and edit it by hand.
Well, if they have never released open source, they might not be the right developer for us. We don't have to chase after every type of person, we have specific needs.
Having said that, if I was hiring for a big corporation, I'd still get a lot of information from how they interact with the LLMs, and I wouldn't want them to 'game it' a couple weeks in advance so I'd look for older entries. I love how LLMs for the first time give me a real way to assess what people have been doing. And can even use them to vet crazy ideas people send to me.
> 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.
The mistake was not answering the question. There would have been nothing wrong with expanding your answer with notes about how you might avoid having a million items in an array in the first place, but the question was how do you sort it when you have it and you should answer the question you're asked before answering questions nobody asked.
It has nothing to do with language of engineering, and everything to do with him not answering the simple question he was asked. And then he goes on to complain that interviewers value complexity right after the story about how he fumbled a simple question by overcomplicating his answer to the point that it didn't even answer the given question at all.
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.
Do you go through the whole process? I never know if I should just bow out in the middle if I they've scared me off. Just say I think I can save us both our afternoon.
The alternative is to try to keep up the pretense and I'm terrible at that, so I end up sandbagging the interview and then they of course don't make an offer. And no matter how many times I look at it, I can't decide which is less likely to cause me problems in the long term.
I think it's important to go into an interview with the mindset that I am interviewing them as well as they are interviewing me. Why give them a reason for withdrawing an application if they don't ask for one? If they ask for a reason, it starts to become a negotiation.
I’m saying I’ve already interviewed them and I don’t want to work here, because they’re nuts/toxic. Do I tell them that at 1:15 and go grab a fancy coffee, or do I let them finish the interview?
How many people really remember someone they interviewed at another place four years ago?
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.
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 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.
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.
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
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.
Thanks for mentioning star method. Didn't know about it yet.
Do you think you’re a productive and valuable employee with marketable skills?
If the answer was yes, why do you think we’re in a situation where you need to dedicate that much of your own free time, sans compensation, just to make yourself attractive to companies so you can at best fall back on temporary employment?
I do not mean to attack you personally, but your comment is incredibly black pilling and dystopian to me. It’s seems like every year we are going to be asked to do more, get culled if we don’t, and half of the commentary from our community is about how you can avoid the yearly culling by working even harder.
Who said anything about working harder?
https://news.ycombinator.com/item?id=45089377
The company gets a simple deal from me. They put the amount of money in my account they agreed to every month and in return they get 40-45 hours a week from me and all of my experience and skills.
They want me to fly out to a customer’s site or sit on a zoom call to close a deal? They got me. They want me to lead a large cloud implementation? No problem. They want a 50+ page management consulting style assessment with pretty diagrams? Say the word. They have a customer with an empty AWS account and they want someone who can do AWS architecture from the “DevOps” [sic] perspective and development? Say the word.
What they don’t get from me is burnout, time away from my wife and exercise in the evening, weekends or on call work. They get 40-45 hours of work from me.
It doesn’t take that much time to write down a summary of what you accomplished every quarter and keep an updated resume and in my case go on LinkedIn and post a banal “thought leadership” bullshit post once a quarter to keep me on the top of people’s mind if things go sideways at my current employer.
I would much rather be in my position where interviewing means some behavioral questions and talking to people than having to grind leetcode and reverse a btree on the whiteboard.
Respectfully, You are not putting in 40--45 hours a week if you are
>I’m 51 and I stay interview ready. My resume and my career documents are updated quarterly and I keep my network warm.
All of the extra bits of work you have to do outside of the 40-45 to stay "interview ready" count as work, youre just not getting paid.
Speak to other professional fields about the requirements they have for getting a job. Even in ones where there is an expectation of continuing education like for doctors, that is usually covered both in time and money by the employers of said doctors, not just something they are expected to moonlight on.
The other professions are even more agahst when they hear things like having to go through 10 round interviews or being grilled on the same set of college basics that dont get used in the day job, as a part of every single interview
At some point since the dotcom bubble, employers figured out a way to convince software engineers that since a bunch of nerds who were interested in this skillset as a hobby were doing it in their free time, the rest of us should be doing that too
How much extra time do you think it takes to summarize what you did at the end of a project? I do that anyway on the job during working hours to prepare for performance reviews and put it in our performance tracking system.
The banal “thought leadership” posts I’ve done on LinkedIn was also done during working hours. It’s encouraged at my level as marketing for the company and it also helps me.
I work remotely, do you really think I don’t do all this during working hours?
> Speak to other professional fields about the requirements they have for getting a job. Even in ones where there is an expectation of continuing education like for doctors, that is usually covered both in time and money by the employers of said doctors, not just something they are expected to moonlight on.
We get $1000 per completed professional AWS certification and a few others the first time and renewal and have time to study between projects. Even when I didn’t work in consulting and working in product companies - the last one as the lead architect - I took time during working hours to study.
You did see where I said I haven’t done a side project outside of work for my entire 30 year career?
> The other professions are even more agahst when they hear things like having to go through 10 round interviews or being grilled on the same set of college basics that dont get used in the day job, as a part of every single interview
My interview at AWS was one full day and five rounds of behavioral questions. But all of my other interviews were two rounds and then an offer. The last two companies I worked for before AWS, it was talking to the director and CTO about business outcomes and strategy and my previous experience. Do you really think high up people in their 40s are going to ask another 49 year old to balance an AVL tree?
Well then congratulations, you seem to have progressed high up enough in your career to not have to deal with that.
I have literally never had an interview process with a company consist of less than 4-5 hours of interview rounds or an equivalent sized take home project. Roughly 50-60 interview cycles over 12 years. That includes companies where I was referred in by the hiring manager.
Tell me about it. I'm in the 9th circle of interview hell and if I wrote a blog post about my recent experiences it would die as a [flagged] post because it seems too made up.
I just today spoke with a recruiter for a position that is 3 steps back in my career, but asking for more skills than I have.
The compensation is also going back about 5-6 years in nominal payment, not even accounting for inflation. It’s titled and compensated like what looks to me a 3-6 year in their career senior engineer working at a successful but not mag7 level company like a DraftKings.
They won’t even move to the first stage of the interview process until their CTO has personally read and approved it.
At this point I’m more mystified as to why everyone’s wasting their time like this on filtering. I can’t see a rational situation where it’s worth executive time to bother filtering for a role that’s so minor to the organization, but that’s the circus we’re in now so I guess I’ll jump through the hoops
> If the answer was yes, why do you think we’re in a situation where you need to dedicate that much of your own free time, sans compensation, just to make yourself attractive to companies so you can at best fall back on temporary employment?
Do you think good products just sell themselves? Do you think marketing departments exist because companies love to waste money? There's your answer.
Do you understand that what you're saying is that in order to be hired, you not only need all the skills needed to do the job, but also all the skills of a full-fledged marketing department, regardless of whether the job requires any of that?
Some of us think that's top-shelf bullshit.
Yes. Because knowing the job and showing people you know the job are two complementary skillsets. Spends some time working with technically-illiterate managers and clients and you'll see. Don't do it and you'll be left hanging wondering why people can't see your brilliance and competence.
I'm sorry you don't live in the world you'd like to live in but that's life. Been at this game for 25 years and it has never been different.
Look up the concept of “luck surface area”.
https://modelthinkers.com/mental-model/surface-area-of-luck
It’s about doing the work and telling people you do the work. It was never my intention to land in BigTech at 46. I was actively opposed to it because I didn’t want to move from my big house in the burbs and we were fine. I had spent the last seven years at startups leading projects and “transformations”, learning AWS and updating my LinkedIn profile. AWS reached out to me in 2020 (as has GCP since I left but I rather get an anal probe with a cactus than go to BigTech again and I’m damn sure not going into an office) and I said why not interview?
While I was there, I was building a network with coworkers and clients, learning how strategic consulting works on the highest level, contributing to an official very popular open source “AWS Solution” in its niche. Releasing my own open source solutions in their official repository, did a couple of blog post that are still on their website, etc.
When Amazon started Amazoning, I waited for my severance offer and had multiple job offers within two weeks with a $40k+ severance in the bank just by reaching out to my industry contacts I had made.
It may be bullshit. I might think gravity is bullshit. But that doesn’t mean I’m going to jump off of a 25 story building out of defiance. I play the game because I have an addiction to food and shelter.
How are employers supposed to know you're productive and valuable if you won't even maintain a decent resume?
Honestly you come off as whiny and entitled, everyone has to present themselves through a CV. If you want to stand out you need to put some work into it.
I work as a consultant/contractor, so I am actively encouraged to polish my resume during work hours. You could look into the same if you also want to be paid to polish your resume. I don't see why other kinds of employers would want you to work on it, the only thing you could use it for would be to leave them.
Maintaining a resume is burying the lede. Being "interview ready" in software means maintaining a separate set of skills that are rarely used in the day to day.
When companies are asking for people to reverse red black trees and then turn around and expect their employees to hook up wordpress sites, or build generic REST based CRUD apps, they are implicitly putting the burden of training on the employees.
I posit that the software field is one of the worst fields when it comes to this
I have never been asked to reverse a red black tree. Maybe they all do that in SV but in my corner of the world I haven't seen nor heard about anyone doing that. I've been asked to write a class to store Car objects and get them by plate number and some stuff like that. I've been asked to write a simple tax calculator with the specific tax rules and brackets provided.
I thought these were perfectly reasonable tasks, certainly within my capabilities. To me, being "interview ready" is simply being competent at my job. Nobody's expecting me to memorize obscure algorithms that I could just look up if I needed them. They're just asking me to demonstrate that I can solve a simple task by programming. That's totally fair, I wouldn't want to work with the people who went through 3 years of university (and even years of actual work afterwards) without learning how to solve these kinds of basic tasks.
I don't even remember what a red black tree is, I think they were covered in our DSA class but not much. Despite that I think I could give a pretty solid go at reversing one, given an implementation and maybe a summary of how it works. I wouldn't mind getting that task, sounds like a fun challenge. Maybe I'd complete it in 30 minutes, maybe I wouldn't, in either case I'm sure I'd be able to show that I'm pretty good at programming. That's all I've ever needed for my interviews. Haven't done an interview that hasn't resulted in a job offer.
Meanwhile I see all you people on the internet complaining that interviews are so unfair and require this "interview prep", so I'm left to conclude that either employers in my country are way less selective than they are in yours, or you're only applying to the most selective employers, or you're simply exaggerating the difficulty of the interviews. If you want to work at Google earning $500k then you're going to have to be exceptional. For everyone else there's plenty of very lucrative jobs that aren't nearly as hard to get. And if you can't even get those then maybe you're just not particularly good?
I’m not young or new to the industry. Not every place is this bad but it’s still highly common to get asked questions that seek to test out how many algorithms you’ve memorized.
This is not 500k/yr jobs but 150-250k year jobs where companies try to ape the practices of mag7 but fail at it because they are unwilling to implement fundamental aspects of those processes.
I also(until this current economy, lol) didn’t really ever have a problem crossing this barrier and getting jobs. But I still hate the extra effort needed and the extra hours of my personal life I have to sacrifice to brush up on or keep up to date on skills that the employers have, in my experience, never once had me use or even worse, blocked my efforts on working on tasks that would make use of the skill.
I grin and bear it because the moneys worth it but I think it’s inefficient posturing done to filter out social classes at this point, like how unpaid internships are used in the finance field
To be fair, $150k is still a very good salary. That's like 3 times as much as most other people make. So it seems to me like we're still talking about fairly high-tier jobs, where I live most developers make less than $100k. The only devs I know who make north of $150k are self-employed contractors which comes with a lot of downsides.
I can see how it might be frustrating to have to maintain a separate set of skills just for interviews. I just haven't experienced that myself.
High col area, was paying 3 grand per month before utilities for 1000 sq ft and rats. Surroundings are fun at least. 150k is well off still but not secure from financial problems after being out of work for even a few weeks.
Like I said, the moneys worth going through the hoops but it’s aggravating to go through them when I don’t think they are benefiting anyone, even the employer.
I also felt this way when I was on the other side of the table doing hiring mind you.
I explicitly said “being interview ready” for me was not doing coding interviews on the whiteboard. It was being able to talk about my past accomplishments and how I would benefit the company.
Yes I am self aware enough to realize that I have been able to avoid that because I was 50 years old when I interviewed last year, with industry experience, connections and AWS ProServe.
But on the other hand, cry me a river that younger developers must prepare for coding interviews for a few months and make $160k+ straight out of school. A former intern I mentored when they were an intern and when they came back is now 25 years old and making over $200K as an SA at AWS.
I am not at all bitter. I am happy for all of the up and coming fresh college grads I met when I was there.
While I have never been encouraged to work on my resume on the job, I have been paid to post to the company’s blog and various “thought leadership” posts to LinkedIn and at a previous company open source work.
While it was marketing for them, it also helped build my visibility
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.
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.
Or just establish the H-1B salary by some third party through evaluating what similar positions pay in the most expensive areas of the US and making each sponsoring company pay whatever it costs to get that data.
Greatly enjoying working on my own software for now!
Any tips for doing that and making money?
I'm betting on Steam's "early access" personally.
> Just an ocean of fake jobs and awful jobs lol.
Oof. Is that true of the "who's hiring" posts here on HN?
There's many awful things, but HN who's hiring isn't one of them IMO. Because HN has maintained an image of being for "smart in the know" people and discussions despite being huge, connections fostered here tend to start off with a stronger weight than completely cold interactions, there's some minor level of inherent trust there.
I can't remember the last time someone didn't reply to me from here, but then again I choose my applications very carefully. You also get to meet a truly diverse set of people and opportunities rather than "more of the same".
[flagged]
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.
That was just the stated feedback. They just didn't like you, and found a reason not to. This effect is well studied.
The better you understand this, the more it won't make a difference, sadly. At least you can get through the rest of the week though.
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.
Why did you design it that way then? Actually asking, not taking the piss.
There is a difference between knowing how to find and use the ordered list of complexities for big O notation, and knowing these by heart. The difference is irrelevant when you design or code, but it’s important for interviews and exams.
Sorry I meant the systems we built not the interview itself.
> 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".
> 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.
I don't think it was money that caused this, but that many beloved tech giants were intentional built as fraternities by college dropouts and recent college graduates, many of whom did not themselves join a fraternity in college but got soaked in a lot of the atmosphere of them. It's most obvious in the case of Facebook, as publicly documented in things like the movie The Social Network, but it's a foundational DNA strand in Microsoft and Google and nearly any other big tech company that still prefers to call its headquarters/office park a "campus". (It's kind of a through line in the HBO show Silicon Valley too, how much tech companies intentionally copy the "pizza and beer and all-nighters and weird dorm room living" college vibe.)
(The presumption that most of these company executives never were themselves directly involved in college fraternities is that fact that they allow/encourage/build hazing rituals. Fraternities have had somewhat strict anti-hazing education requirements since the 1990s and most Universities have also had strict No Hazing Policies since around then. Since 2024, that education and policy enforcement has spread outside the Greek System to all students at most major Universities that get federal funding directly or indirectly, but before that it is certainly easy to understand how many might have missed the messages and education if they only saw fraternities from the outside.)
But the same kind of self-congratulatory exclusionary clique thinking behind frat pledging, and the same thinking behind the historical attendant hazing, could still be at play?
Not necessarily because company leadership and random interviewers are mindlessly mimicking what they experienced in school, but because some ideas tend to arise from power/privilege baggery.
(Though we also now have the mimicking of other tech companies, and we could just call it that, but "frat hazing" is still a better understood term, already with negative connotations.)
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.
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.
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.
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.
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.
> you think the proxy is accurate because it provides some feel-good binary.
Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities. If you prefer, there are absolutely companies that don’t use the process, and they’ll hire you after a quick resume conversation. Frankly, I wouldn’t want to work there, having seen the abysmally bad talent hired through lax processes, but Godspeed if that’s where you want to work.
> the fact that a person actually had the same or similar jobs successfully over many years.
No matter how good you think you are, if you can’t pass a basic live coding exercise, you have no place on my team.
…You’re not being asked to invert a binary tree in 20 minutes with your eyes closed, you’re being asked to traverse a string and use a set. Stop whining.
I think in reality though what you're doing is asking people to grind out puzzles until they're good. It's kinda like saying high math scores equal financial sucess. It is true in general but you're basically proxying hard workers not that the basics you test for are right. Getting an A in calculus doesn't mean that calculus helped you be a top engineer I bet most engineers would fail their old tests.
The leetcode interviews to me basically signal: 1. This person is of minimal intelligence required 2. They work hard
The real problem I have is that this system requires an endless calculus test requirement. Most proffessions have one big test to get in then you're basically done. Refreshers are given but once you pass that initial bar no doctor is required to pass their entire medical exam for every interview.
Why not just have a certificate and be done?
"Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities."
Genuine question; how do you know? Presumably you have some good feedback on the accuracy of your process when you hired the candidate, but do you have any measure of how accurate your process was on the ones you turned down? I'm sure some of the ones you turned down would have been bad hires, but some would have been good hires; is there a measure of that?
>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 number of times I've worked at places where the competent people likely could not pass their own interview questions if they hadn't thought of them themselves is too goddamned high.
I'm getting tired of having to coach other senior devs on how to interview like they mean it instead of like it's a drinking game.
Google has come right out and said that none of their interview strategies have made a statistically significant difference in employee outcomes.
> Interviewing is mostly a different skillset from day to day work.
It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.
There are plenty of places that have lower bars for hiring if you can call a JSON API in Python and run some Linux commands - but for the places everyone wants to work, you should expect a high bar. And that’s a good thing! A players want to work with A players. I would not want to work at a place that has a low technical bar for hiring.
> 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)
It goes without saying that interviewer successfully passed that interview process to get hired there. So they have demonstrated at some point that they can do the problems they’re asking you to do.
Blowing a technical interview sucks, I get it - I have blown dozens of them. It’s humiliating, I’m aware, and so people find all sorts of copes (I would’ve been better than my interviewer at the actual job if I had just been given a chance! They couldn’t solve that problem anyway!) but they don’t want people that can just do the job - they want really talented engineers that can grow with the company and build all sorts of things.
Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.)
And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.
> It goes without saying that interviewer successfully passed that interview process to get hired there
It does not.
Also, even at the places with the most consistent interviews difficulty is pretty all over the place (or questions are well-known).
Anyway, for me the answer to my interviewing woes was a propranolol prescription
>It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.
I don't write websites at all. I have had to deal with performance issues but frankly it is rarely a major concern for anyone. Furthermore, interviews don't resemble work, they resemble LeetCode or other competitions.
>Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.)
Having a degree and a long employment history implies that you are a good engineer more strongly than your performance on a random puzzle question. Most interviewers are not that good.
>And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.
Yes, these companies want a process that provides superior vetting compared to 4 or more years of intensive schooling, or else something so far out that it can distinguish among expert candidates (while taking no more than an hour). It's a stupid objective. Coding interviews should mainly determine if you lied on your resume or not. It should not be seen as a magic way to spot "good engineers."
If you want to filter out bad engineers, just ask them questions that you expect bad engineers to do badly. These are mostly design questions and not coding questions.
> Interviewing is mostly a different skillset from day to day work.
> It’s not, really:
Funny -- I'm halfway down the page now, and haven't seen your top-level post stating how and why the entire point of TFA is wrong.
> this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.
Yeah, that was the point: Most day-to-day jobs are writing basic websites without huge scale constraints (or equivalent), but interviews are usually conducted as if those huge scale constraints were relevant.
Do you have some particular reason to believe that most actual jobs do involve "real performance or scale constraints"? Or that interviews aren't conducted as if they did? (Or did I somehow miss the point, and that wasn't what TFA was all about?)
>>>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.
Why is expecting senior engineers to have an understanding of, frankly, basic fundamentals of how computers work is so upsetting to you?
If you want to hire and work with people who don’t know those, by all means, hire them… I certainly won’t stop you.
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?
Great idea.
So we’ll do both: have a high bar for technical interviews and a culture of psychological safety. That should be the best of all worlds and create a high performing team.
I’m not sure your point here. Yes, high performing teams have psychological safety.
Ironically, that's my point right there. Zero real thought, zero follow-through. There's plenty of research but nope, it's all vibes no data.
> 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.
Those that don’t know CS fundamentals end up making bad technology decisions.
I can’t tell you the number of times I’ve failed a “senior” level engineer because when I asked, “Tell me why you chose X database on Y project,” the only thing they could come up with was, “Well, we were storing JSON data, so we used Mongo.”
I don’t want to be left cleaning up the mess that guy makes.
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.
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.
I always begin system design interviews by repeating and clarifying the framing of the question. Some simple ones: "what kind of service/website is this? what's our expected peak load today? 2 years from now? 5 years from now? [regarding data structures] what's the biggest value we'd reasonably want to store?"
You're backing into things like QPS, size of the data you're responsible for hosting, uptime requirements, real-time requirements, write load vs read load.
Often the natural walk is "let's assume it's a low load, design for that, and then we'll get to higher load at the end". Other times, it's an actual systems-y problem they're facing as a company, and that they have a putative solution to compare your knowledge against.
But yeah it is generally really important to codify and at least state (if not explicitly clarify) your assumptions before recommending a solution.
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.
Huh. The most scalable solution is never the simplest. Simple solutions scale fine up to a point, and no more. The two are at odds.
It's not whether it scales. It's _how_ the components scale.
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.
> 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 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.
The worst question I've been asked recently was how to make something robust.
When I started running down the laundry list of footguns with the basic solution, he clearly became impatient. I never did figure out what he was after, but I worry for the team.
I would question if I want to work in place where absurd problems are so commons their solution is evaluated during interview.
> 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.
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.
It’s true if you’re a cutting edge company doing real R&D and parting with capital and agency to your workers as a result of it.
Every company whose CEO thinks he’s a mag7 but scoffs as paying more than >150k/yr to an engineer because that’s executive money that tries to ape that kind of risk management ends up with a hiring process that is optimized for rejecting people since their offered compensation will never meet the demand of people with the skill set they are looking for
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.
It's almost like software wants to be a real profession when it grows up, like Doctor or Lawyer or Engineer. Doctors generally only take the one MCAT. Lawyers generally only take the one Bar Exam per state they expect to work in. Civil/Mechanical/Chemical Engineers only take the one FEng/PE combo of exams for their discipline.
It's fascinating how many people in the software industry want the title "Engineer" but don't want benefits of the title like standardized tests and ethics boards because they are afraid of standardized tests and ethics boards.
Outside of civil engineering PEs aren't common. There was one for CS but no one took it. PEs are mostly useful for people signing stuff off for regulators.
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.
Yet:
1.) "Every time" is 10+ years apart for a lot of folks
and
2.) If you look at the requirements for things like PEs (at least the last time I looked at them), you have requirements like 4-year degrees, having worked under a PE for some number of years, etc. in addition to the tests, which I assume a lot of people here would object to.
1) Not so much in tech hubs, especially during the long boom of the last decade. And having to take the same test at potentially a dozen different companies every ten years is still a poor experience.
2) Surely an attempt at standardization in this industry, like the similarly hypothetical pipe dream of a widespread software tech worker's union, would include adapting to the unique characteristics and mores of the industry? There's no need to fully copy other disciplines' practices in complete detail. Though we should include the ring ceremony, that would be cool.
The whole point of this is that Leetcode has essentially become a de facto standardized test for many many jobs in this industry, and if we are to recognize that reality, we might as well make it DRY.
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.
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.
...So anyone who coded on their own, you'd just reject out of hand?
And (granting, for the moment, your premise that everyone worth hiring used the LLMs) how do you know what they do with the code after they take it from the chat window? My limited experience with the code from LLMs is that there's only so much massaging it's worth giving it through the chat interface, and then you need to just take it and edit it by hand.
I can see their commits presumably?
Only if the software they're working on is open-source.
Many, many software engineers work on internal programs that will never see a public repository.
Well, if they have never released open source, they might not be the right developer for us. We don't have to chase after every type of person, we have specific needs.
Having said that, if I was hiring for a big corporation, I'd still get a lot of information from how they interact with the LLMs, and I wouldn't want them to 'game it' a couple weeks in advance so I'd look for older entries. I love how LLMs for the first time give me a real way to assess what people have been doing. And can even use them to vet crazy ideas people send to me.
Here is a real example that I did today, see what I mean: https://chatgpt.com/share/68b878b8-8608-800a-8b6a-6bac1af36e...
> 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.
Seems like a bit of a contradiction.
Yes, obviously? It was an example, intended to show how using the language of day-to-day engineering in interviews is a mistake.
The mistake was not answering the question. There would have been nothing wrong with expanding your answer with notes about how you might avoid having a million items in an array in the first place, but the question was how do you sort it when you have it and you should answer the question you're asked before answering questions nobody asked.
It has nothing to do with language of engineering, and everything to do with him not answering the simple question he was asked. And then he goes on to complain that interviewers value complexity right after the story about how he fumbled a simple question by overcomplicating his answer to the point that it didn't even answer the given question at all.
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.
Do you go through the whole process? I never know if I should just bow out in the middle if I they've scared me off. Just say I think I can save us both our afternoon.
The alternative is to try to keep up the pretense and I'm terrible at that, so I end up sandbagging the interview and then they of course don't make an offer. And no matter how many times I look at it, I can't decide which is less likely to cause me problems in the long term.
I think it's important to go into an interview with the mindset that I am interviewing them as well as they are interviewing me. Why give them a reason for withdrawing an application if they don't ask for one? If they ask for a reason, it starts to become a negotiation.
I’m saying I’ve already interviewed them and I don’t want to work here, because they’re nuts/toxic. Do I tell them that at 1:15 and go grab a fancy coffee, or do I let them finish the interview?
How many people really remember someone they interviewed at another place four years ago?
Anyone capable of writing this and defending it is overqualified, but I would want to hire them, anyway.
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.
Funnily enough, TFA links to an article on that subject too: https://idiallo.com/blog/how-meetings-should-be
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 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.
[dead]
I decided a while ago to train for the job and not the test.
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.
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!
Is that why my chair feels like a casting couch and I feel very dirty afterwards?
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]