9 ms·
You're Not Interviewing for the Job. You're Auditioning for the Job Title
- gchamonlive 1y agoIs that why my chair feels like a casting couch and I feel very dirty afterwards?
- quectophoton 1y agoAnd 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.
- ghaff 1y agoI assume the alternative is that you give some standardized "civil service" exam.
- Apocryphon 1y agoHonestly if it’s an exam you only take once or once every decade it’s an improvement over the current system.
- ghaff 1y agoI can't speak to developer exams so much but companies are often looking for specific people who aren't well categorized by standardized exams.
- Apocryphon 1y agoThey’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.
- ghaff 1y agoThe 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.
- Apocryphon 1y agoUltimately 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.
- ghaff 1y agoYet: 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.
- Apocryphon 1y ago1) 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.
- Gigachad 1y agoOr 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.
- WorldMaker 1y agoIt'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.
- ghaff 1y agoOutside 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.
- solotronics 1y agoIt'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
- wccrawford 1y agoI was 14 years in a job at senior level and got laid off. And yeah, it's pretty much as bad as you describe.
- benoau 1y agoYep. 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.
- dhosek 1y agoI 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.
- benoau 1y agoGreatly enjoying working on my own software for now!
- horns4lyfe 1y agoHalf of the interviews out there are designed to be gameable enough to block out US citizens at will in favor of visa holders anyway
- vrnvu 1y agoHonestly, 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.
- JustExAWS 1y agoBeing 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.
- quantified 1y agoHa. 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.
- OutOfHere 1y agoThank 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.
- quantified 1y agoIn 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.
- OutOfHere 1y agoHuh. The most scalable solution is never the simplest. Simple solutions scale fine up to a point, and no more. The two are at odds.
- quantified 1y agoIt's not whether it scales. It's _how_ the components scale.
- gen220 1y agoI 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.
- stephenpontes 1y agoI 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.
- rahimnathwani 1y agoIn 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 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.
- platevoltage 1y agoI decided a while ago to train for the job and not the test.
- djoldman 1y ago> 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).
- bigmattystyles 1y agoYou’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?
- random3 1y agoHighly related and high quality thread https://news.ycombinator.com/item?id=45064284 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.
- omosubi 1y agonot 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.
- cagenut 1y agoalmost, 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!
- satisfice 1y agoAnyone capable of writing this and defending it is overqualified, but I would want to hire them, anyway.
- jjk166 1y agoI 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.
- ajmurmann 1y agoI'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.
- hinkley 1y agoThe 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.
- ponector 1y agoI would question if I want to work in place where absurd problems are so commons their solution is evaluated during interview.
- sheepscreek 1y agoI 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.
- enraged_camel 1y agoThe 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.
- lovich 1y agoIt’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
- EGreg 1y agoIf 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.
- danaris 1y ago...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.
- EGreg 1y agoI can see their commits presumably?
- danaris 1y agoOnly 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.
- EGreg 1y agoWell, 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-6bac1af36ec3 https://chatgpt.com/share/68b878b8-8608-800a-8b6a-6bac1af36e...
- sneak 1y agoIt’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.
- p1dda 1y agoGreat 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.
- hinkley 1y agoDo 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.
- p1dda 1y agoI 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.
- hinkley 1y agoI’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?
- neilv 1y ago> 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".
- WorldMaker 1y ago> 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.)
- Esophagus4 1y agoEvery 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.
- wakawaka28 1y ago>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.
- Esophagus4 1y ago
- sfn42 1y ago> 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.
- CRConrad 1y agoYes, obviously? It was an example, intended to show how using the language of day-to-day engineering in interviews is a mistake.
- sfn42 1y agoThe 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.
- SunlightEdge 1y agoI 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.
- thunderfork 1y ago[dead]
- McAlpine5892 1y ago> 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.
- seethishat 1y agoMost 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.
- CRConrad 1y agoFunnily enough, TFA links to an article on that subject too: https://idiallo.com/blog/how-meetings-should-be https://idiallo.com/blog/how-meetings-should-be