Here's the traditional engineering interview script:
Ask the candidate how they'd solve a problem you either recently solved or are currently working on. Where does their mind go? What questions do they ask? Do they make the same mistakes you made? Are they different? Do those complement one another? Are they excited?
Honestly, one of the best things to do is get people to talk about their passions. For a lot of engineers their passion is related to their work. You WANT this as a business. They'll work hard because they're having fun doing the work. They'll learn more on the side and get a lot of expertise and ideas you wouldn't have on your own. If you make the job interesting and fun, they'll stay despite offers of higher pay too! But all of that depends on managers. A good manager participates and their most important job is preventing engineers from spending too much time in rabbit holes. You need to go down some but some unravel forever and your engineer will get stuck in an infinite loop.
You really really need to go through an actual code exercise with them. It’s staggering how many people I’ve interviewed who can talk the talk but when confronted with with a 50 line class full of glaring issues for a code review exercise, they can’t find any of the actual problems. The great thing about it is that the good people will spot the super obvious ones in about 5 seconds and you can just move on from it very quickly.
We’re talking c++ programmers with a decade of experience not spotting basic RAII, missing pointer checks and straight up logic bugs for the domain that we interview for and hire in (games).
This lets you get a feel for their coding style, comments, unit testing and so on. The "explain why you did it the quirky way" is for proof of authorship. You may learn something from it as well.
It's a bit of work for interviewer, but far less stressful for the applicant than coding tests. But it's easier for the interviewer in some ways too, as you don't need conversation starters - the "tell me about this project" step is a perfect way to find out about their previous experience.
As you say, the charlatans are very good. I even tried bring in sales, with explicit instructions that their job was to spot the bullshitter. They were no better at it than we engineers.
If this were the standard interview process, of course, I'm sure I could figure it out. There would be a site called "Leetportfolio", and I'd prep for interviews by implementing dozens of Leetportfolio mediums, and people would come to HN to complain about the obnoxious companies that expect you to include some Leetportfolio hards. For me this sounds significantly more time consuming and no less artificial or frustrating than Leetcode grinding.
15m recruiter screen (1hr Take home goes here if you’re doing it) 30m hiring manager call 1hr tech interview 1hr team fit
And a go/no go at that point. You can put the hiring manager call at the end if the hiring manager is a senior enough person that you need to protect their time.
The tech test should be actual code, but not evaluated for syntax. I like a code review test but we’ve also done problem solving and writing pseudo code in the past. No let code, no algorithms and no tricky formulas. If you want one of those you should provide the formula. A good tech interview should be open ended enough that you can dig into whatever direction the candidate goes - if they go hard onto concurrency then follow that track, or if they go into testing then follow that track.
class foo {
public:
foo() {
ptr = new other();
}
~foo() {
}
};
Interviews are inherently high pressure situations for the candidate, the only way to avoid that is to just let people try out on the job and fire them if it isn’t working out. That’s unfair to everyone.
The glaring bug here is that ptr is - or rather the object being pointed to is - on the heap and allocated in the constructor, but the deconstructor doesn't free it?
- ptr is not being deallocated in the destructor
(personal preference - use of class member without explicit `this->`)
I mean it’s psychotic to half-manage it like this but I don’t think the lack of a destructor is suspicious here; in fact I think it’s correct once the global pointer was introduced
First, if `ptr` is declared in the translation unit before and outside defining `class foo`, then there is no check for previous initialization and thus is likely a run-time defect.
Second, if `ptr` is not declared in the translation unit before and outside defining `class foo`, then it is likely a missing member definition and is a compile-time defect.
that comment was not a comment but an interview. and you just failed it.
Would this work with any language other than C++? In almost every other language the only ways the code can actually be broken is if there's undefined variables or something. Sure, any language can have logic bugs, but that would require more than 50 lines to be certain of.
I mean, even if the code says something like `total /= 0`, yeah, it looks wrong, but, I'm not 100% certain it's wrong with just 50 lines of context.
Were these programmers lying about their decades of experience? Or did they really get by with writing broken C++ all those years without knowing the basics? What a language! I think C++ is a special case when it comes to interviews.
> Or did they really get by with writing broken C++ all those years without knowing the basics?
Having inadvertently hired a handful of people, it’s this. They write shonky c++, it just about works, but they spend all their time patching up the mess they’ve left behind rather than doing it right in the first place
> I'm not 100% certain it's wrong with just 50 lines of context.
These are blatant issues that we would expect a reviewer to catch in isolation. It’s also an interview, we expect you to ask questions. You’re told as part of the brief to ask questions if you’re unsure. It’s not a trick, we’re looking to see if you can actually write the code or if you just can rattle off some of the rules.
A good example is DIY. How do you install a shelf - you drill a few screws into the wall and stick a piece of wood on it. Being able to tell you that is very different to being able to do that level on a wall. I can tell you “use SQL to select the name of the users who have used X resource without any duplicates”, but I might not actually be able to write that query (“select name from table group by X where Count(X) > 1”)
> I think C++ is a special case when it comes to interviews.
I disagree. Give me a language and I can give you 50-100 lines of code that just about does what it’s supposed to do but is littered with issues. Offhand I could write the same thing for C#, go, python and SQL with very little issue.
> even if the code says something like `total /= 0`
I mean... it might run or compile but our best case scenario is what, javascript where it returns infinity? But I'd certainly take issue with any program where I saw an explicit division by zero. If you were just trying to create an infinity there's got to be a good explanation for doing it that way.
I just have a deep technical conversation. If they run out of things to say, they are not right for the job. They run out of BS, because I keep the conversation on specific things that you can't make up, yet keep it open enough that you have to bring your own experience.
That's it, (spoiler alert!) it's like the great reveal in Kung Fu Panda.
> For a lot of engineers their passion is related to their work.
This is the guy you find with this method. He can talk forever, because he loves what he does and can't not keep doing it.
I can’t exchange “passion” for food clothes or shelter.
I’m 51 now and can afford to choose work life balance over money. But if I were younger and it’s advice I give all younger graduates in CS is to “grind leetCode and work for a FAANG (or equivalent paying company)” and by pay I mean cash and RSUs in publicly traded companies not “equity” that will statistically be worthless.
I show proficiency, professionalism, expertise, and the ability to bring that to a job.
I’ve had 10 jobs everything from startups, random big enterprise, and BigTech.
Am I suppose to show passion about - bill printing? Field services sending technicians to people’s houses? Railroad car repair?
Admittedly my first job as an architect was for a company that managed sending nurses to the homes of special needs kids and the next two were in the health care industry, but after that it was dealing with cloud consulting (full time jobs) first at AWS directly then other consulting companies (currently a staff architect at a 3rd party cloud company)
I can talk about technical solutions, be a post sales architect, lead implementations and do system design and coding all day long without being “passionate” about the business. It’s just professionalism and my addictions to food and shelter
You can “trust” I have those skills because I can talk about my past experiences, you can throw any architectural or business problem at me and I can talk through it including tradeoffs and why I made the decisions I made. How I deal with organizational challenges, etc.
My being able to dig into a topic is not “passion”. It’s my job. I get paid to know my subject matter deeply and to be able to ramp up fast on technology and the business domain.
The deal is if I work at your company, you agreed to give me $x amount of money, benefits and for me remote work and in exchange I agreed to give your company all of my expertise gained over 30 years of working for 40-45 hours a week.
You need me to code those 40 hours a week? You got me. You need me to be on a zoom call or fly to a client site? No problem. You want me to do pretty diagrams and spit out 40 page requirement documents or business proposals? I can do that too. Along with leading projects, cloud architecture, etc.
Just understand, you get 40-45 hours a week. You don’t get late nights, you don’t get on call, you don’t get weekend work, and my bullshit tolerance level is relatively low before I am looking for another job - ask my last nine employers.
I laid out what __I__ consider different forms of passion and while explaining yourself you met some of that criteria. So I'm not sure where the anger is coming from. I hope you're doing okay and I really hope we can have fewer abusive employers. I'm really empathetic to that, and have quit several jobs because situations like you mention.
These are the people who don’t show “passion” unless when they get off of work they are doing side projects related to software development and usually end up getting burned out.
I’ve also avoided burn out, stress over work and I am able to survive in the industry for 30 years because I understand the transactional nature of the job and set boundaries.
Someone who does there job well doesn’t mean they are “passionate”, they are “professional”.
Oral exams, live coding exams, system architecture exams, take-home exams, behavioral examinations, code review exams, extended essay writing exams, case study exams, sample work trials.
You can't be a real professional if you have to take exams in every job change.
In serious professions, people take exams early in their careers for being certified. Sometimes they take additional exams to renew their certificates. And that's all.
They don't take exams from random people in random companies that know nothing about evaluating knowledge. They take official, standardized exams prepared by professional testers/educators.
Engineering jobs can't be standardized. Engineering and required skills and knowledge is too broad for that.
An interview is not an exam. It's a meeting. The interviewer asks questions to learn about the candidate. The interviewer may ask some questions to learn about the company and the position. That's all. That's the universal definition of a job interview. All the other things are additional tests and exams.
Do they need to do those exams for better selection? Probably not. Their "hiring process"es are not backed by any science. Then why are they doing that? They have to filter somehow. If there are 1 to 100s ratio of candidates for each position, they need to filter hard. Exams are the standard method for ranking and filtering.
But we are professional engineers, not students.
Most devs are doing work that more closely resembles pipe fitting or carpentry than any engineering discipline.
We do exist, but as you said very rare. There were 12 of us in my graduating class in 2004.
For example, UC Berkeley's EECS department lost its ABET accreditation in 2020 (which it had maintained since 1983.) Stanford University lost its ABET accreditation in Electrical Engineering in 2014 (which it had maintained since 1936.) In contrast, nearby Santa Clara University and San José State University both have ABET-accredited EE and CS programs. So, consider hiring some of their graduates!
Many computing professionals are members of professional societies such as ACM or IEEE (and many are not since they don't see the value in the expensive dues.)
What has also not been widely adopted, and has even been opposed, is standardized professional engineering certification (exams, licensing, continuing education requirements, etc.) for computing professions such as software development.
I think this may be related to the computing industry's remarkable success in avoiding liability and associated regulation, particularly for software and online services.
Yet plumbers and carpenters (and electricians) are all licensed.
The field of programming emerged from mathematics, not engineering unfortunately. So we lack any useful certification processes.
However, it does not seem to be common practice for computing professionals to acquire professional engineering certification. (Perhaps graduation from an accredited program is considered to be equivalent?)
There do seem to be Professional Engineer (PE) certifications for computer engineering at least:
https://ncees.org/exams/pe-exam/electrical-and-computer/
https://ncees.org/wp-content/uploads/2025/01/FINAL_PE-Electr...
There are also company-specific certifications (from Microsoft, Cisco, etc.) but those are less general.
Not saying it’s not possible to focus on fundamentals that have only changed superficially in decades (like the networking stack or data structures), but it is more difficult in this field.
I started the engineer-in-training track when I was in the offshore drilling industry but then I left and never went back.
I don't know why people are so against it in this field
Because the vast majority of failing software just means inconvenience, rather than disaster.
Quarter of a million dollars in a suitcase, loaded gun, and a copper ticking clock on the table next to you. Picture of your kids that need new school clothes.
Miss one question and you fail. Must also be confident, friendly, and not too old while doing it.
—> “I can’t find anyone that can pass my simple test, they must all be frauds.”
This is not how proper exams work, and for good reason.
Hey, that's my PhD entrance exams!
If you get nervous, the main thing you can do is more interviews. My personal anxiety peaks right before the start time, luckily my bathroom is next door to my office! But after doing dozens of interviews I settle in once it gets rolling.
If you hate leetcode, well just get good at it. Yeah it is kinda dumb but it is straightforward to practice. And there is a lot more to a leetcode interview than knowing tricks - you need to communicate well.
Take homes? Yeah they are time consuming. If you really need a job do them, otherwise pass on the company!
Overall as a candidate you really need to try and go one level up on selling yourself - not just why you are a great candidate (which you are of course!), but why you would succeed at this role in particular.
For better feedback there are some good mock interview companies out there, or you can ask a friend or mentor. I've also had really good luck just talking to Gemini/Chat GPT.
There's never been a single one that went poorly and I didn't know exactly why without a word of feedback from the company I was interviewing with.
Failing a take-home is an entirely different thing. It's a huge loss in time and mental energy.
I've only done 3 of those in my career and only because the projects sounded interesting. 1 of those 3 resulted in a job offer which I can now confidently say in hindsight was the worst job in my career (...so far!).
I'm now leaning towards just filtering out companies that do take-homes because it signals to me that they don't care about their candidate's time and how a company treats its candidates is usually a good indicator of how they treat their employees.
With a take home I can demonstrate how I would perform at work. I can sit on it, think things over in my head, come up with an attack plan and execute it. I can demonstrate how I think about problems and my own value more clearly. Using a take home as a test is indicative to me that a company cares a bit more about its hiring pipeline and is being careful not to put candidates under arbitrary pressures.
On the other hand, with takehomes I get to approach a project as if it were my own little hobby thing. I get to approach it in ways that are comfortable for me to work, with my music on, in my own editor, on my own setup, with no time pressure (or at least very light time pressure, just like during the actual job). I always use it as an opportunity to try out something new as well, so I'm also learning in the process even if I don't get the job. And in my experience even when rejected, I've always gotten detailed feedback for areas of improvement, which has never happened in leetcode interviews for me.
Basically all big companies doing industrial scale hiring ( and firing) that don't have time or patience for take homes.
Is Scala the right choice for hiring and firing, though? If they need to fire quickly, why not straight machine code?
It didn't hurt that the person in question ran the products group. (And I went to the same school as the ultimate hiring manager.)
People obviously have different experiences at different companies but networks matter a lot in many cases whether a lot of folks like it or not.
Things still took a few months to coordinate meetings and interviews but it was still the only job I (sort of) applied for.
Get good at it and you can do hundreds of interviews with no prep.
Take homes are a proxy for hiring most desperate ppl who can spend most time on it.
In my experience the more impressive somebody is at leet code, the worse their production code. Full of bugs, no error handling. Assuming the inputs never stray from the happy path.
Not saying it's always the case of course. But I did interview almost 400 people over my career.
On the other hand, most people cannot code to save their life. So I have no answers. Only more questions.
Used to think this too, until I met some truly impressively bad engineers where I'm pretty sure they would not have passed a leetcode screen either. People acing leetcode is at the minimum a good signal for people having the patience to sit down and learn non-trivial things over a somewhat longer time period by themselves.
Good signals comes from questions that uncover attributes that will grow your team snd fill deficits.
The best method yet for a technical interview is a work sample test based on recent work actually performed by the team. I've never encountered a leetcode problem in the wild. Data structures and algorithms, of course. Leetcode? Nope.
But leetcode is easy to administer and someone else already wrote the question. The big companies don't even try to differentiate between those who clearly have practiced the given leetcode problem type vs someone who derives a solution by working the problem.
>with no prep.
You contradicted yourself in the same sentence. You can't get good at leetcoding interviews with no prep
Do you know the "use it or loose it" phrase? How long do you stay good at leetocde to not require anymore prep whenever you interview again?
For some people, doing an AI assisted take home might take less time than having to restudy and re-exercise leetcode for months which they won't use again. Plus a lot of people suck at live coding when put on the spot due to anxiety, which means even more time investment for something not related to work.
>Is that so hard to understand?
I understood just fine, I'm calling it out as being incorrect for a lot of people.
1. 60 minutes interview with the CTO.
2. At home coding challenge. Candidates can pick one from 2 coding challenges. But we try to keep them engaging and fun, but still complex in details. Sometimes people don’t want to invest this time. That’s acceptable, but in this case you have to show os some of your work from the past, so we can discuss this.
3. Interview with 2 engineers from the team. We are doing coding challenges as a base for this interview. It’s just a way to get people talking with each other on technology and how they work.
4. Make an offer or say no to the candidate. Everyone involved in this process from our side has a veto right. So if one person says no - it’s a No.
5. Send contract to the candidate, if they accept the offer. This is the first time in the process where HR is involved. Everything else before was done by the Dev Team.
I think this is the most important part, show respect by taking care of the process by yourself and communicating with the candidate.
From our experience just posting a junior web developer job gets up to 1000 resumes into our inbox. And we just a small company without an established name.
The only possible first step for us is to automatically send everyone an at home coding challenge. This narrows down the list to only about 50 developers that would reply. Only 10 of them would send working code. And only at that point we can actually start to interview.
> At home coding challenge
Which is a reasonable stance to take! But not if you want to be paid for take homes, but not for interviews.
I think any reasonable person can interpret that there is a meaningful difference between an hour of work and several. The same way you might drive your friend across town for free but you're probably going to ask them for gas money and some beers if they ask you to help them move across state. An hour of my time is just less valuable than my entire day.
Ask yourself why not
I get where you're coming from, and I've tried to fight to get people paid to do our take homes because I also feel it's only fair if we're expecting them to spend ~3 hours of their own time, but you also end up in situations where people will do the interviews just for the money. We had a small trial run with a pretty laughable sum, something like 40 bucks just to test the waters and see how people reacted (this was for a very high paying role, mind you), and we got a staggering amount of people who clearly didn't care at all about the role and just wanted the free money. Like literally would just post a link to a random repo or whatever, completely unrelated to the takehome, and you as the company don't really want to be in the situation where you argue with candidates about what constitutes a "real assignment" for the purposes of payment.
It's one of those situations where a handful of dickheads can ruin a good thing for the decent folk.
At least personally, I dedicate as much time to reviewing the takehomes as the candidates themselves put in. I write extremely detailed feedback covering every single line they present us and we supply that feedback to candidates regardless if we're moving forward with them or not. Also importantly, in the candidate gives us an actual assignment, we always move them through to the discussion part of the interview, except for cases where the assignment was basically not done at all or was egregiously terrible. I feel mixed on this one, because sometimes it's clear from the assignment that chances are slim for the candidate, but I've also seen some pretty bad takehomes end up with super strong hires at the end (and vice versa!) from the discussions.
HR even tells me that a few candidates reached out and wanted to thank me personally for the feedback I gave them even when they didn't end up getting hired, so at least from what I can tell people don't mind the way we do it. I personally fucking hate doing interviews, regardless of which side of the interview table I'm on, so at least when I'm the one doing the breathing-down-the-neck thing, I try to make it as good of an experience as I possibly can.
IMO it's the fairest interview method, and the one I personally prefer to do when I'm the one interviewing (as in, when I interview for jobs). In my experience it's always been pretty obvious that the takehomes aren't for any actual work (obviously I can't speak for everyone here, I'm sure it does happen) and it's always a pretty made up scenario that is loosely tied to what the domain is. I know that it can be unfair for people with a lot on their plate, at least I've been lucky enough that 2-4 hours out of my week is pretty doable, and especially compared to something like leetcode (which most people still have to study for, so the 2-4 hour thing is pretty moot IMO) it's just incomparably better. I've tried doing "just talking" types of interviews, but there are a lot of good bullshitters out there, so there has to be some type of actual programming just to weed them out.
I honestly disagree with the veto right because it makes it too easy to be abused. In my opinion, a supermajority (66% or even 75%) agreement should be sufficient. They said that Liberum Veto rotted the Polish-Lithuanian parliament.
I won't do a coding challenge unless you do mine too. Don't they always say interviewing should be mutual evaluation?
Here's the deal: You give me your standard coding challenge, then we reverse roles for an equivalent one I prepared. We do this for the full interview duration.
If you can't solve mine, that tells us something important about the technical bar at your company. After all, if coding puzzles are truly predictive of job performance and essential for determining candidate quality, then presumably everyone on your team, and especially those making hiring decisions should excel at them... ;-)
If your coding challenges are going to determine my professional future, and your company claims it only hires "the best," then you should have zero problem demonstrating that same level of excellence. I wouldn't want to work somewhere where the interviewers can't meet the standards they are imposing on candidates.
Either these challenges are meaningful indicators of ability (in which case you should welcome the chance to prove your team's competence), or they are arbitrary hoops and in that case, why are we doing this?
Caveat: I hate the concept of HR and the phone screen is an excuse to waste their time instead of mine. Also none of this applies if you have < 100 employees.
That is not always possible. There is always an NDA in contracts. Imagine me going around and revealing the code I have done for your company...
3.
Are you going to pay extra those two engineers of your company for doing something that is clearly outside what they were hired for at beginning or outside their competences?
4.
The same as 3. Are you going to pay those employees for doing manager work instead? Or the managers of your company are paid for doing nothing while showing doing something and soon ready, as in your message, to download their responsibilities to simple engineers (company's leaves )?
Edited.
However, here we are talking about at the general level. Not a single instance as your experience.
Engineers are hired for engineering jobs not for manager jobs or mopping the floor.
On the other side, if a lately hired person wasn't find himself comfortable inside the team, I, _as manager_, can always complain the team and accuse them being guilty because they weren't able to say NO at interview level or because they said YES at the wrong candidate. Do you see the faulty thought of our time? I as manager earn a lot for managing people but in reality I download my responsibilities of not being able to interview a candidate and so find the right person _downloading_ that on the team that actually is not responsible for new hired person. Fantastic.
Than's the meal they want you digest in some cultures. In mine, as manager, I decide who is on board, and I clarify clearly the roles of every one. No space for interpretation.
I din't come out from a manager school, but I started from the ground and I put myself _every time_ in the shoes of who is managed by me.
My humble opinion
It’s really not that weird to have the team decide who they want to join their team
This is not kindergarden anymore. We're taling adult stuff here. If the manager is not able to interview, analyse and understand who is in front of him, then it is time to change job.
Iff the candidates has personal work to show then it is considered a plus, but it is not madnatory.
3. No, normal wage and is expected of them.
A hired person is supposed to fill a role and not a double or more roles just because the manager is not able to subdivides tasks, roles etc. I don't expect engineer or technical roles to do manager job.
4. That’s not manager work. It’s a tech talk, it needs to be with the tech people. It’s really not that weird to have the team decide who they want to join their team
It might work in your culture.
in my culture, who is going to take a manager role _manages_ technical people _and_ as such he _must_ know the technical stuff to a certain degrees otherwise the job is not for him. Here managers don't download their responsibilities to engineers they manage.
At the same time, engineers are not supposed to judge or like or dislike their coworkers. Working in a team is a prerequisite that they have to accept, either you like it or not. Full stop. There is no space for interpretation or for leisure. They have tasks and they finish their tasks. Full stop.
Why is it outside (and not just outside, but clearly outside) of what they were hired for or what their competencies are? Engineers work on the product. Engineers review each other's code. Engineers are a stakeholder in this whole process — after all, the candidate may become their future colleague, and engineers are best positioned to know what they want to see in a prospective colleague. Engineers can appreciate whether their peers have the desired skills.
Why does this activity require a higher pay than developing a new feature with your teammates?
During the past decade, that has been as a “senior” employee of some sort. By senior I don’t mean just “I codez real gud”.
That has meant:
- Being on calls or flying out to a customer’s site to support sales in closing deals when I was working with B2B companies and later full time working at consulting companies.
- Interviewing candidates
- leading teams and come project management work.
- hands on keyboard coding
- DevOps [sic] setting up architecture for empty AWS accounts.
But I’m always up front about tradeoffs to management. If they want me to do one thing on the list, there is an expectation that something else on the list won’t get done. I don’t put in more than around 40 hours a week aside from the infrequent business travel.
No, it doesn't matter that much what task the candidate is doing in the interview. It matters what the interviewer is looking at. I'm sure plenty of interviewers don't understand this, and I think this is often missed when people debate about Leetcode interviews - including in this article.
> most interview questions have very little to do with day-to-day responsibilities
You're missing what the interview questions are. Yes, one part of the interview is "here is a puzzle, can you solve it?", but many of the other questions should be things like "explain why this doesn't work", "why did you start with this approach?" and "are you sure that is the best name for that function?"
Leetcode interviews are perfectly "applicable", as long as the interviewer is using them as a convenient frame to see how you think, communicate, and write/read/edit code and isn't trying purely to assess your skill at quickly solving leetcode puzzles.
> cannot distinguish a senior programmer from a marketer using chatGPT
This is empirically false, because companies haven't suddenly lost all their hiring signal since ChatGPT came out. But if a company has this problem, they suck at interviewing.
(I admit the style of interviewing I'm describing has its own problems, and in particular doesn't address what I think is the biggest issue: the fact you're partly testing people's ability to (appear to) perform under acute pressure.)
But knowing the good solution by heart is not the point! For that reason, when I ran code interviews, I often gave hints to the candidate, or sometimes just stated that a particular algorithm is a good solution, and it's usually implemented using this and that. ("Use BFS. You'll need a queue.")
This is where the demand for realistic conditions kicks in: at work, you're not going to invent an algorithm, you'll ask the machine what works in a situation like yours, consider, and choose. Doing otherwise would be imprudent.
This is important and something more interviewers should do. The blind adherence to leetcode doesn't tell you much, especially if you're silent during the interview instead of having a short back-and-forth every 15 minutes or so. The problem solving process is more important than the problem solved.
You are also testing people's endurance. I once did an on-site interview with Google, and it was a solid 6 hours of leet-style puzzles, one after the other.
> I admit the style of interviewing I'm describing has its own problems
Also worth pointing out, the style you describe is the traditional engineering interview. Leetcode type problems were initially done this way. It is also easy to make an effective system worse by trying to improve it. This often happens by trying to apply hard metrics to noisy problems. You don't improve your accuracy, you are just fitting a certain type of noise better (and encouraging Goodhart's Law).
another way to say this: focus on aptitude. in my hiring funnel, this is a core tenet. you need to be able to capture polyglots and systems thinkers. its still pretty hard to design a process that balances this all very well. combine that with an absolute glut of applicants and you have a very challenging problem.
Before the interview, you clone the repo and get the app running on your machine.
For the first half of the interview, you review a pull request in real time. There's a mix of obvious and non-obvious callouts. And the second half, you actually implement your suggestions.
Honestly the code review portion alone is a great indicator of a dev's experience and soft skills.
There's a trade-off: if a company spends more time / requires more effort on an interview process, they can get a better signal on the candidate's abilities, but then they'll lose out on candidates who are unwilling / unable to commit this time. This might just be a hard trade-off in recruiting.
Internet applications have made it so easy to apply to a position, companies have to find (usually arbitrary) ways of filtering the pipeline.
It’s a very difficult problem to solve - Coinbase had 500k applications for 500 positions.
Edit: I’m very concerned about AI tools flooding the pipelines even more by sending out tons of automated applications. This is going to cause an arms race where the companies have to use more arbitrary methods to sort through candidates, and it will only make it harder to find good ones.
But, yeah, it's not that, back in the day, I didn't post a ton of application resumes and form cover letters to HR departments out of school--and even got non-form responses from a number (and an offer from one sight unseen though I ended up going with someone else even after insisting on an in-person visit). But my sense is that, as you say, there's more of an arms race as you put it going on today where--if you don't have some way of cutting trough the noise, such as through your network, it's a tough slog. Which is one reason the anecdotal evidence at least suggests it's tougher for people who have't developed a network yet.
I feel like the industry is far tougher to get into now than when I joined.
I sent out maybe 10 applications, got a few interviews, and 1 offer.
I hear of kids now sending out dozens to hundreds of applications with few bites.
Makes me sad for the stress they must feel.
But compared to maybe the decade plus prior to a couple years ago for (especially junior) software developers, it seems like a tough market based on a lot of conversations irrespective of overall unemployment rates.
In 2023, I was Amazoned after 3.5 years and found myself looking for a job. Even worse, by then I had moved to an area that was tourist heavy, but not really tech heavy and was looking for remote only jobs. The remote role at AWS just kind of fell into my lap.
Plan A: Leveraging my network. This led to two offers both architect level positions - one over the architecture and migration to AWS at f500 company and the other over the architecture of PE owned company that was doing rollup acquisitions (been there done that).
Plan B: targeted outreach to companies looking for expertise in a niche of AWS where at the time, I was one of the industry experts and was a major contributor to a popular official “AWS Solution” in its niche.
This led to two interviews and one offer.
I basically had three offers and a side contract within ten days of looking.
I’m not bragging, I’m old. I should have a network to lean on and a reputation. The point is that even with my experience, if that well above had run dry, I might have been screwed.
I also applied for hundreds of jobs during those two weeks while going through the interview process with my first hits. I heard crickets and for every job I applied to, it had hundreds of applications and my application wasn’t even viewed by most and my resume was only downloaded once (LinkedIn Easy Apply shows both).
I was not some old guy (well I am) with outdated skills. At the time I had over ten years of software development experience (on my resume) and 7 years of AWS experience including 3.5 working at AWS (ProServe) leading relatively complex projects.
if I spend 6 hours and the company has 1000 employees does that mean they spend 6000 hours? If so I might consider it a reasonable line of argument, but I guess they don't spend anywhere near that.
Not enough to make it worth farming interviews for compensation, but enough to show that the company appreciates that you spent 2-4 hours working on their take home.
Most software people do web front end or web back end or CRUD. Most of the rest do apps, whether mobile or desktop. What's non-fungible about us?
This is so important, and most of the “fit” problems working I’ve experienced are because I didn’t weigh something heavily enough in the interview.
If you are even the slightest bit concerned with an employer, that is a red flag in your long-term prospects there.
For example:
- If your future boss seems even a little clueless about the job itself, you may be lucky to find adequate structure or information available to do your job well.
- If your future boss seems guarded, they may be hiding something; they may not be equipped for the job or could be a psychopath.
- If they have greater than average benefits or the recruiter calls you a rockstar, it may be some form of hell, and you won’t find that out until a few weeks in.
- If more than one person seemed like they were afraid to say something during the interview and were very quiet, either the environment there will be weird or it may be a serious hell and/or there is no chance to be able to fill the shoes of the person that left.
- If you sense that they overestimated your ability or you overstate something accidentally in the interview, you may not overcome that as much as you want to believe in yourself. No, you can’t make up for years of experience with hard work. Your LinkedIn profile description must be essentially you, with the burrs removed and buffed up a little; It’s not just to get past a machine or recruiter.
- If anyone you interview with is an arse, even if they work in a different team, that’s not a good sign.
- If you are ___, and no one else there is, that may be a serious problem. This is age, sex, religion, politics, number of kids and ages, pets, what they do/don’t do socially, emotion, humor, tech stack, clothing, what vehicles they drive, style of workplace, and everything else that either you won’t like or they won’t like about you. Diversity is a sham if you’re the only one different, though I know that some may not ever realistically find a place to fully fit in.
- If you join when they’re hiring others for your team at the same time, and the business itself isn’t growing significantly, that can be a bad sign.
- Claims that they don’t fire people are a lie or a hope.
None of these are absolute rules, but find your people, and if anything doesn’t seem right or seems too good to be true, it probably is. Weigh that extra salary against the impact of having to find another job if you quit or are let go later.
This is impossible to satisfy below a certain company size. And beyond the things that can't realistically be hidden, I would prefer not to know a lot of that about my coworkers, and would prefer them not to know those things about me.
Companies need to build systems where everyone is replaceable to de-risk the business and not because they don't get programmers.
As much as I don't like LLMs that much personally, do you think ChatGPT was produced with replaceable people?
> Companies need to build systems where everyone is replaceable...
No they don't. They need to build systems where everyone is happy with their job and don't need to constantly hop jobs for better salary, environment, etc.
The way to mitigate the bus factor is not to make everybody replaceable; it is to have a process to develop more irreplaceable people with overlapping expertise in their areas.
For all the talk about innovation, you don't get that by making everyone an interchangeable cog. You want at least some people, who are difficult to be replaced, because they are your competitive edge ( I am saying difficult, because I personally also do not believe anyone is truly irreplaceable ).
And again, the risk to a company, especially a tech company, is falling behind. Losing an employee is a fact of life type of risk; effectively unavoidable. Still, that kind of fake modularity is wrong, not because modularity is a bad idea ( it is not ), but because companies absolutely fucking suck at designing that kind of a system ( as evidenced by reality itself ).
All this is before we get to some of the more human aspect of all this ( up until now we were talking about companies as if they are a living thing with wills and what not and an amalgamation of humans, where one action is a function of thousands little decisions ) like: people messing with systems in a way that does the exact opposite of what the company 'wants'.
All in all, it is an interesting argument, and I even agree with it at some level, but I do not think it survives closer inspection.
Once we both had the correct answer, we started optimizing to try and eclipse each others' runtime. This was actually a fantastic test to display deeper knowledge beyond just regurgitating a solution, showing benefits and drawbacks of different languages and patterns, and seeing how we could work while agreeing or disagreeing on a technical subject.
I was really too junior for the role they wanted and I didn't get the job, but it was a fantastic experience.
Then I was trying to get someone to do my taxes. So I've been asking every applicant to do my taxes from last year so I can see if they really know what they are doing. I mean sure, they've done taxes for years, but these are my taxes. I've even tried giving them math puzzles around asset depreciation, but people just keep hanging up the phone.
And then, I wanted to add a wing added to my house and I've been trying to get these entitled contractors to come build a shed in my backyard so I can see if they really know how to use nail guns. I've heard people are just big'ol lairs lately, and I need to see how they work. I mean, sure these guys have built many houses in the past, but we have high standards here and only hire A players.
I've only been getting horrible candidates! No one is worth hiring! There is a huge shortage of qualified people.
If only there was a way to fix this.
It helped that it was 90 days contract to hire.
Part of what lead to it I think is we hired largely straight out of college and doing a 9-hour interview with someone with little experience is a waste of time.
It worked great. In my five years there we only had a couple people not make it past the probationary period.
Less true in hotbeds for a given industry. But I've had relocation paid twice in my career and it was just a given.
They’ll say they will help. Even have you fill out a form. Then when it comes time to cover the expense, they come up with excuses on why they won’t.
Have they not formed a verbal contract in saying they'll help with relocation expenses?
Let’s face the reality that most developers will never be able to write original software and just put text to screen using a tool or framework. Don’t call these people engineers. These people are the assembly line of software. Measure them according to desired patterns. They are copy/paste but smarter than data entry and understand some of the restrictions in place. Expectations are low and compatibility and replacement are the key business values.
Next are the people who test software, the QA. We expect more from these people and then work them harder for less money at a lower level of reputation.
Next are the people who evaluate software. These people are closer to engineers. These people include accessibility, security, and performance experts. These people are more like a combination of QA and senior developers. Evaluate these people on these criteria: written essay, technical knowledge, force them to measure things in real time and see how they perform.
Next are the people who actually write software applications. Let’s call these people solution delivery. These people are similar to junior architects and actually build things. These people should be evaluated only on the basis of organizational capabilities above that of the engineers that measure things.
Finally are the software owners. These people resemble a combination of project management and junior architects. They must have the experience to know how to build original software, like the junior architects, but also a planning vision to push though demands from competing stakeholders. There is busy savvy to this comes from a solid engineering planning vision plus superior communication skills most lesser software people never honed. Think of these people as senior principals with real authority. Evaluate these people on their delivery experience, using numbers, and reputation.
Why? People who actually write original software require many other skills in order to do so (just not, you know, marketing).
But a 9-hours interview process seems just too much... I think you will only ever know a candidates true fit once you start actually working together and 2-3 short sessions with someone is enough to get that go/no go feeling.
You can't hire without taking risks.
Where I live, you usually have a 3-months probation time in which both sides can quit within a 7 days period... so the risk is manageable.
Just feel a candidates fit and then go for it... and adjust when necessary. Don't overthink it.
I have a rage memory now of a "live coding" event that makes me want to leave this profession and never come back.
Here's my suggestion for the technical interview:
1. Applicant signs NDA and agrees to not use AI 2. A small bug or feature request is chosen from the backlog 3. The staff engineer pair programs with the applicant until it is fixed/implemented
This does a few things:
a) The interview is suddenly "productive" for the employer rather than a cost sink b) No one will apply that doesn't actually know the stack/framework/language c) The interviewer gets a real world example of what its like to work with the applicant d) Leet coding and puzzle solving is eliminated in favor of real world coding e) A secondary skill set that doesn't actually contribute to the work is eliminated (go pound sand autists)
I won't forget the in-person interview round where I coded a frontend visualization for a data graph (tracking global shipping), then fielded a post-work general interview round from the whole company (~10 ppl) about specifics and "choices" made during a rush to finish. I ended up not going due to comp, but they were acquired months later. Life is funny.
This can spark so many interesting discussions, from syntax, architecture, cs, product etc
It is literally the job that engineers do 99% of their time yet we don't interview on this.
Except it was wildly unpopular amount the other interviewers as t was seen as setting traps and watch if the poor guy falls into them.
And interviewees were sometimes dumbfounded looking at the code, and we didn't know if they were just crushing under the stress or had never looked at code in their life.
All in all, it wasn't that different from a straight leetcode interview.
Code reviews were basically the same, nice on paper but hard to judge in practice.
Regardless, there should be a hard rule that if you show code (either working code or example code) to a candidate then it needs to stay visible for at least five minutes. No skipping ahead to the next slide or switching windows after 2 seconds.
TBH I wouldn't do that face to face, it's so unnatural I'd prefer white boarding or straight handing them a computer.
That's also where using an online coding platform where the candidate can run the code works a lot better, less preparation on either side, less surprises.
For instance I personally use and abuse the online GitHub/gitlab interface a lot and am extremely familiar with both. But looking at my colleagues, many do code reviews locally, diffing in their IDE.
Some also don't navigate the code the same way and tend to work "bottom up" instead of "top down", which puts them at a disadvantage in time limited settings when they might be better reviewers in general.
Referring to the other comment wishing to get full A3 printout to look at the code, we also had a guy who used his personal laptop to interview and felt lost as he usually reviews code on his giant work screen.
Having the candidate choose could be the best of both worlds, but that' a lot more work on the interviewing side.
Eventually, enough time passed that the talent pool grew considerably and most people are baseline competent.
Consequently, I now find that respect and time efficiency matter a lot more.
No system is perfect, but I have a 100% success rate with the engineers that have been hired using this model, and several years of data to back it up.
[1] It actually has a few subtle bugs in it that I'm always curious to see if they'll catch.
[2] The job in question requires working on a Python web app, and so I assume some basic Python knowledge.
A lot of the time, technical interviews and take-home exercises turn into 100 iterations of "Do you prefer vanilla ice cream or chocolate?" or "Do you prefer vi or emacs?"
A good employee will figure out the subjective tastes, biases, and cultural quirks of a workplace, and fit in. A senior engineer will have done it perhaps half a dozen times in their career. -- And yet, companies insist on putting interviewees in a situation of having to basically mind-read those subjective tastes and biases to try to tell interviewers what they want to hear, because they'll reject a candidate on the false premise that a vi guy will never fit into an emacs shop.
"How do you feel about unit tests?" I really don't have any feelings about them whatsoever. Just tell me, if you want me to write them or not. Instead you're asking me to mind-read and trigger some hidden trauma in you. I just don't know whether the trauma is that codebase that required breaking production every single day, because there was no way to test it. Or whether the trauma is that one guy that you hired who never got any work done because he obsessed over refactoring the codebase for optimal testability instead.
What has worked for me, honestly, is being directly involved with my hiring pipeline and having conversations.
It seems like common sense, but there's a lot of reasons not to do this and people will make good arguments to prevent it. "What about bias", "your time is more important" etc;
However, bias is an unfortunate consequence of selecting for value fit anyway and I can't think of a more important task than selecting the members that will be the future of the company.
I've had some positions that were open for a weekend where I got 400 applicants, and yes, it was daunting to go through and give each of them an honest shot, but you know: I had to do it. What's the alternative? I might miss a fantastic candidate because someone didn't understand what I actually need.
Evaluating programmers and "devops" people is just insanely hard, technologies are mostly fungible. If you can write one C-like language you can learn the others in about a month, but what can't be taught is what your values are, if you think in a systemic way, if you're easy to work with and respect others.
So, my solution is to have a conversation, challenge what they know, see how they react when challenged, see how they react when they reach the end of their knowledge and see what they're most proud of and if they get excited by it.
No gotchas, no esoteric internal handshake, just: are you defensive? Are you curious? Are you passionate? Can you communicate effectively and are you intelligent.
If you hit those, you can do anything.
"How do you even know who to interview?"
This is a hard question, for me there's not a lot of candidates that are physically located in my region, so those go through as long as they have something on the CV that looks relevant. For others it's a combination of: would it be easy for them to move, have they worked remote (and can do it in a region where I have a tax entity) and how strong of a fit to the role is the CV, lots of experience in games would be what I expect since I work in video games - but if you're going for a backend programming role then: what have you built and what do you list as your responsibility to achieve it?
With this mindset I managed to build a high performing, high trust team that executed very well on (literally) impossible demands. If the ownership of the company was better that team would have easily been world class.
We also exceeded dunbars second (clan) number with the size of the team, so it wasn't intrinsic to small teams (80+).
now they just use the interview gauntlet to test your will
its like those japanese game shows where they have 10 rounds of humiliation to see how far you can make it
The worst ones were the leetcode interviews I couldn’t pass
Why would you do this given the expected average tenure is probably like 18 months to 2 years?
The issue I see is lots of companies put strategy into hiring from colleges and then are left with the low performers after 3-5 years. A good company will mix college recruiting with job fairs and LinkedIn/indeed ads to get good candidates and won’t pretend to be “a family” or enter cult phrase to try to attract talent.
I’m agreeing with you and stating that corporate leadership is out of touch.
If I had a dollar for every time I heard this (flawed) argument, I’d be rich and would no longer have to sell ads on my Hacker News comments. I’m going to get hate for this unpopular opinion but here we go.
So often, “But Leetcode isn’t like REAL programming” is the siren song of the programmer who probably overestimates their coding skills and experience.
Yes, I hate to say it - live coding is actually one of the best signals you can get on a candidate’s seniority and ability to program a computer (and more importantly, their core computer science skills). A good interviewer is trained to know how to probe your CS knowledge during this, and will watch how you structure code, break down problems, debug, and think about testing. They will even ask you to make changes to see how coachable you are and what you might be like to work with. It’s not about inverting a binary tree while sharing your screen, it’s about showing me how you solve a problem, then translate what’s in your head to code.
Take home exercises provide little to no signal, and screen out people who have families (who wouldn’t bother with a 4 hour take home exercise after work). I don’t want to see how you Google, I want to see how you think.
These candidates always want some version of, “But trust me, bro! Hire me: I’m a senior engineer, I don’t remember how to Leetcode! I’m good, I promise!” But what they won’t admit to themselves is that a good senior engineer is able to do all the things a junior can do PLUS all the things a senior can do.
It’s not perfect, but I won’t hire anyone that can’t pass a live coding round.
This comment brought to you by Poppi. Poppi: it’s soda for people who are silly enough to believe soda can be healthy.
I tend to think that's very possibly true of developers (especially if they haven't worked in open source) but I wouldn't generalize that some combination of pointing to samples of past work and/or a take home isn't valid for a late-stage interview/demo in general. Jobs that involve a lot of writing or presenting, for example, probably require some demonstration of ability whether pre-existing or created for the purpose.
I'd also say that one mistake along this line was taking one such sample and assuming that it was close enough and could be upleveled with a bit of work.
If you let people cheat they will cheat.
The coding equivalent would be asking them why they took some specific approach or used a particular algorithm. I'm not sure about my feelings with respect to coding takehomes but there are circumstances where someone doesn't have an openly viewable body of work where takehomes can make sense.
2) if you have thousands of applicants for a position, and probably a dozen stand out by passing a really tough bar, wouldn’t you want to find those dozen?
It's a reasonable assumption, but you might not. If the role doesn't actually require those skills you might hire someone who's going to get fed up and leave in 3 months or (worse) who invests time in making their job more interesting instead of solving your actual business problems.
So, yeah, you are right. Live coding is very good, which is what I do, but too many people confuse live coding with just leet coding.
I have no idea what could be a better option (well, maybe preparing some small feature to work on together), but it often turns out that good problem solvers are not really great at doing the job, for reasons that have nothing to do with the hard skills.
Hiring is really hard. You only get a few hours to decide whether someone will be a good engineer and colleague for several years.
By the nature of the constraints alone, anything you do will be extrapolation, and a guesstimate at best.
I'd like to add two points to this:
First, I like that you said "live coding" rather than leet code. The floor for live coding should be super low, with a high ceiling and lots of flexibility. That allows you to say, nope, they didn't pass the floor level, easy binary decision, no hire. Pick a fun toy to build in 90 minutes and the high ceiling + flexibility will yield tons of signal from applicants.
Second, I see live coding sessions like this as a positive sign from potential employers. It lets me know that my future colleagues will have some baseline level of competence. If you've worked on a team that didn't do live coding, and you've had to carry water for someone who can't actually do the day-to-day technical "hard skill" work of software engineering, you probably feel the same way. Never again.
Excellent - please be sure to mention this in the job description so I can know to never apply to where you work.
This idea that “I’m special - I’m too good for a live coding round” is definitely not an attitude I want on my team. It’s highly entitled.
The irony.
I was curious about the pay.
https://www.glassdoor.com/Salary/Oxide-Computer-Salaries-E54...
For their “senior” engineers it’s in the range of offers for I’ve seen for new grads at most of the tech companies and around the range of generic enterprise CRUD developers.
No offense to “enterprise developers”. I spent 25 years as one. But why would I jump through hoops for a job that pays about the same as I could hypothetically get based on interviewing for a few hours and asking generic behavioral questions and maybe some techno trivia about whatever language the company uses.
I find it fascinating that companies want rockstar ninja developers but then offer meh compensation for the positions.
[0] https://oxide.computer/blog/oxides-compensation-model-how-is...
First I’m going to make an argument and then immediately refute it before someone else makes the argument. That $235K is still lower than what mid level developers make at any of the BigTech companies.
Yes, that’s true. But they are all toxic hellholes where everyone is jockeying for position, making sure they show “impact” that looks good on promo docs and they all have RTO mandates even for positions that were formally “field by design”.
$235K and the ability to work remotely is something I would definitely think is fair (and a little more than I make now that I’m outside of Bigtech working remotely) as long as you give cost of living increases and is more than most developers will ever make inflation adjusted.
The other point you make is that performance is just a form of stack ranking and even hard work is usually just awarded with a 1-2% raise more than someone else gets. Why not separate it from comp?
I also like sales having variable compensation that is based on performance. I work somewhat as a post sales architect and I have an appreciation for the sales side more than most engineers.
Being a prominent face at a startup can also set you up for greater success in your career than being one of a hundred thousand at a bigco.
And as you touched on already, the environment at Oxide is a million times better than the toxicity and empire building that happens at bigcos.