Just talk to people. Seriously. If you're "an expert", then >80% of the time you can figure out if someone is an expert in the same topic just by talking to them. See how they think and problem solve. That's the skills they'll be using on the job anyways.
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.
I’ve interviewed enough people to staff a company and I disagree.
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).
> when confronted with with a 50 line class full of glaring issues
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.
It’s a self contained class that is littered with basic errors and doesn’t actually do what it’s supposed to do. There’s about 15 things wrong - missing pointer checks, uninitialised variables, public variables with private get/set functions, a memory leak, logic bugs that don’t do what the prompt says it’s supposed to do, subtle behavioural issues that come up in edge cases. We’re not looking for every single one, but there is an alarming number of people who cannot identify even the most glaring issues of “there’s a new in the constructor and not a delete in the destructor”.
> 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.
Thanks for the additional detail. It sounds like a great interview question; it's both easier, and yet more real-life, than something like "write fizz-buzz".
I agree. I've interviewed loads of people, without ever giving a job to someone who couldn't do the work.
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.
individual manager discretion produces widely variable outcomes at scale, a lot of (most?) managers are promoted “by default” because the company is growing quickly, or lost a key person, and there is no better choice available, and it would be hard work to go find and recruit a better choice and nobody wants to do that work. So we add process and structure to help underqualified personnel not totally screw it up, which produces fine results for a while until hierarchy and process gets too heavy and marginal returns start to decay, and viola. Leetcode and AI screening.
No my passion isn’t my job. I have a long list of things I do for fun. Sitting at a computer is not one of them. My job is transactional - an exchange of labor for money.
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.
Everyone calls them Interviews but they are not really interviews. They are exams.
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.
> 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.
The field of programming emerged from mathematics, not engineering unfortunately. So we lack any useful certification processes.
The only issue is that Software Engineering (is that the term we use?) does have more churn and change than other types that have PEs like Civil.
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.
And on the plus side that liability also provides people a lever with which they can push back against stupid managerial decisions. My father was an aeronautical engineer, and his favorite word to say to management was "No". Yes, the engine inspection takes a long time. No, I cannot cut corners in any way just to save you some money (No idea if this is just one of his stories or a real situation, but you get the idea :p ).
I don't know why people are so against it in this field
In general, licensing is for regulatory reasons (e.g. signing off on drawings). Engineers don't generally do it unless there is some industry requirement to do so (especially in civil engineering). And there mostly isn't in software.
I started the engineer-in-training track when I was in the offshore drilling industry but then I left and never went back.
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.
I won't do an at home coding challenge, that is, unless you pay me. It's not about time investment, it is that we need to respect one another. You also have to realize a lot of places will use these "challenges" to get free work done. I'm sure this isn't what you're doing, but how is the person interviewing supposed to know? It is definitely a red flag. Built from good intentions, but a red flag nonetheless.
(I do the interviews at our company, but I'm just a regular dev and not in management or HR or anything like that)
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.
Surely a 15 minute phone screen at the beginning with an HR rep would help thin the field, no? Just something quick for them to show that they know how to act appropriately, dress professionally, show up on time, and speak the language. Plus it provides an opportunity for the HR rep to show a roadmap of the process and the candidate an opportunity to ask broad details in case they need to back out.
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.
Dressing professionally is not important for software development jobs. People at my company wear a wide range of clothing, and I haven't seen anyone making an issue of it.
2. "...but in this case you have to show os some of your work from the past, so we can discuss this."
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 )?
Maybe that attitude works in a big company, but it won't fly in a smaller one. I'm a software engineer and I write plenty of code, but I also help out with interviews, packing, sales demos and proposals, customer support, general IT support, etc. Hell, I've fixed the coffee machine! I'd absolutely hate it if writing code was my only task.
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.
2. Then they do the take home challenge, or you hire another candidate.
3. No, normal wage and is expected of them.
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
2. Then they do the take home challenge, or you hire another candidate.
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.
> 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?
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?
I get paid to bring my knowledge and skills about computers and systems to bring business value to the company - to make them money or to save them money.
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.
> companies often over-index on crystallized knowledge over fluid intelligence.
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.
i am a data engineer (2 yoe) who speaks multiple languages and thinks in systems. i am looking to switch jobs as the problems i work on at my job are not as interesting as i would hope. also i am underpaid. can you point me to your hiring funnel?
> interviews should: be applicable. reflect the actual job duties
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.)
The problem with leetcode is time. If you know a good solution to a puzzle, or can instantly come up with it, you have the time to write it down, make it work, discuss, improve, etc. If you spend extra 10 minutes on a wrong approach, you're very strained, and if you spend 15 minutes, you're toast.
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.
> 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?"
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.
> I admit the style of interviewing I'm describing has its own problems
We need to be clear, ALL styles of interviewing has problems. There's no global optima for problems like this. It's important to say this because people will point out problems as reasons not to switch while ignoring the existing ones. The answer entirely depends on "what are you optimizing for?" Be precise
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).
>you're partly testing people's ability to (appear to) perform under acute pressure
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.
As much as I dislike leetcode style interviews, if I fail one of those, I learn what I can and move on.
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.
I've had the complete opposite experience, and feel the complete opposite way. What is there to learn from failing a leetcode? It feels like luck of the draw - I didn't study that specific problem type and so failed. Also, there is an up front cost of several months to cover and study a wide array of leetcode problems.
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.
I feel the complete and total opposite. With leetcode-esque ones it's just a luck of the draw that you can conjure up the memory for whatever it is they're asking you to do. The decent ones are the ones that at least are somewhat realistic, but the truly terrible ones are those where you have to remember how to do an algo of some sort but you have no access to outside tools of any kind. I've never come out of a leetcode and felt like I learned anything or could've done something better, not to mention the artificially crafted high stress environment. I feel like they also literally never reflect anything even approaching the actual work, either, and basically test your memory more than anything else. There's a reason there's a billion books out there about how to "crack" the leetcode style interviews.
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.
I don't get it, every job I have interviewed for since 2013 has had a take home. A couple of them waived it in my case but otherwise they all had take homes. Where are these jobs where people don't get given take homes?
When you are rapidly hiring, giving a candidate 2 weeks to complete a take home is a huge drag on the process. Instead, sandwiching 3 interviews (resume walk, leetcode, system design) into a 3 hour time period lets candidates move through the process faster.
hmm most of the take homes I ever got had a 1 week to complete but I guess I see it, I don't think I've ever been trying to get on a company that is hiring more than a small time at any time.
GitHub (pre-microsoft at least) and Crowdstrike both did. Amazon didn't have a take home so much as a "prove you can write code with this simple problem" though that was also pre-AI days as well.
In Australia, AWS dev position in 2021 had a take home. Microsoft contract position before that didn’t but they were desperate to fill seats on a poorly executed gov contract.
I can't speak to developer roles specifically. But the last job I had (for a long time), I just dropped an email to someone who was a client. I think a fair number of the developers at the company came through internships or referrals and AFAIK takehomes weren't a thing.
With all those leetcode acers, why is software slow as molasses? You would think they pattern match for the most efficient algo with all this training.
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.
> In my experience the more impressive somebody is at leet code, the worse their production code.
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.
Interviews need to give signal to the employer. Having a couple decades experience now, working high scale, highly available services, and having designed interviews for thousands of candidates and given hundreds of interviews across half a dozen software engineering orgs, leetcode is poor signal.
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.
After getting good at it, there is no "additional" prep time, unlike take homes, where you would need to spend hours for every individual assignment. Is that so hard to understand?
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.
I don't mean to be harsh, but as an engineer you owe it to yourself to try and get better at interviewing. Does it suck? Yeah absolutely. Is it an annoying process? Definitely. But even if you have an easy and stable job things can change quickly at any company. You're only closing doors on yourself.
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.
Not a huge AI guy but this is something LLMs can do quite well (less so before gpt-5 because that model was a sycophant) but I learned a lot about personality interviews by simply having the AI throw questions at me and then taking my answers apart.
I'm happy to provide feedback for anyone reading this - Mock interviews or code challenge reviews. No guarantee it's helpful but I'm not a black hole at least!
Not sure if they're still doing it, but GitLab does the code review interview, and I too really liked it.
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.
The OP thinks that candidates spending a lot of time on applications is OK, as long as the company shows respect by spending a lot of time themselves. I think this is mistaken - I care about how much time I have to spend, and am a lot less concerned about how much time the company takes.
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.
Excellent point. And for anyone who’s been a hiring manager / recruiter, you know how many candidates you will have to sort through. And you want to waste as little of your engineers’ time making them do interviews if possible.
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.
Last time I was looking, a year or so ago, I sent out dozens of applications and got zero interviews. Last time I switched jobs, in 2022, I sent out the same amount of applications and >50% led to one or more interviews (and eventually two offers).
Historically, I'm not sure that isn't fairly normal.
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.
I think it's reasonable to make a donation on behalf or provide an honorarium if someone makes it far enough into the process. Something like a $250 gift card or equivalent.
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.
>The OP thinks that candidates spending a lot of time on applications is OK, as long as the company shows respect by spending a lot of time themselves
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.
The situation is not going to improve as long as business stakeholders and engineering managers (some closer to MBAs than actual engineers) think of software engineers as construction workers. They think we are fungible, they don't understand the craft of programming etc, and have very short term mindsets. Took me a while but then I realised that I needed to interview my prospective employers as much as they were interviewing me, and to just ignore those not worth working for.
We are fungible. Most software development is not rocket science. If any of us got hit by a bus tomorrow HR would send our next of kin “thoughts and prayers”, a flower and tell them how to collect our life insurance and then immediately open a req and get flooded with hundreds of probably good enough replacements.
> I realised that I needed to interview my prospective employers as much as they were interviewing me
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.
> 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.
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.
It sounds like what you're arguing for is that companies ought to have employees that are irreplaceable. Wouldn't that impose a huge risk to the company? If said employee gets hit by the proverbial bus or leaves, the company should just fold?
Companies need to build systems where everyone is replaceable to de-risk the business and not because they don't get programmers.
If a company doesn't have irreplaceable people, then that company is not doing anything interesting. Conversely, if replaceable people can produce your (software) product, then any other company can also do it.
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.
But they ( companies ) don't. Looking back at my career, what you do get is, various ranges of alignment to an idea ( whatever it may be ). Some companies do it better than others. Usually, the smaller the company, the easier it is for the owner/founder/main guy to make sure his vision is appropriately enforced, but that gets so much harder in bigger ones so the systems they generate get progressively less sensible. And yes, I don't think search for absolutely replaceable employees shows any kind of faith in one's company. It does, however, show an interesting frame of mind that I personally like to avoid.
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.
It's crazy, I've been trying to hire an architect to build a house for me, but I don't trust them (they're all liars) so I asked them to draw up blueprints in front of me and describe everything they are doing in great detail. I need to understand what they are doing. This building is important and I don't want a bad hire. They should be able to do this in 10-15 minutes. If they knew what they were doing, this request wouldn't be an issue.
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.
Debugging exercises reveal not just technical knowledge but also communication patterns - how candidates ask clarifying questions and explain their reasoning reveals more about their daily work habits than most algorithm puzzles.
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.
If I was asked to review code in an interview, I'd prefer it be printed out on a sheet of A2 or A3 paper that I could look over and write on.
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.
For live debugging/fixing we were sharing a dedicated GitHub repo, and the candidate would share his screen while doing it. It was kinda of a mess, so I switched to a more static approach of sharing a MR and have the candidate explain what it does, and potentially comment on it.
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.
If I can get a person talking about tradeoffs - be it speaking to a past project, or a hypothetical I give them - then I think I can tell who the serious developers are fairly quickly.
I agree with the article. Discussing previously created code and do code reviews live covers a lot of ground. Whereas live coding is just meaningless for the stated reasons.
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.
As long as someone isn't relocating, it's possibly reasonable. As long as someone is moving, there's a lot bigger barrier to taking a job. Mind you, there's is a barrier in any case if someone has a decent-paying job but just isn't loving it.
The primary problem with hiring is that developers are a single status with not performance benchmark. The solution is to segment need by capability.
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.
Now the issue is to identify them. All those types of workers will present themselves as Software Developers (or Software Engineers), so the interview process is not only an entry filter, but a classification filter too. You (as a company, or as an interviewer) need to discern which are the strengths of a candidate, and also the skill level within each of those categories.
> 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.
Why? People who actually write original software require many other skills in order to do so (just not, you know, marketing).
Writing software is no different than writing a novel or a music album. Its creating a product. All of these require the ability to write, but its more than just writing an essay. There are functional aspects that require different stages of planning and composition that must be put together in a way that can be maintained, described, and decomposed. Its that vision for composition and extension which requires organizational capacity drawn from lots of experience.
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.
At my first employer circa 2005 we had a simple 1-2 hour interview and a 90 day probationary period. Respected people's time, gave everyone a fair chance to prove themselves. I don't know why it's not more common in the industry.
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.
Well, historically, taking a new job often meant relocating which is a big expense for the employer (who typically paid relo for engineering jobs) and is hugely disruptive for the employee. Definitely not just a shrug for everyone concerned if things don't work out after a bit.
Less true in hotbeds for a given industry. But I've had relocation paid twice in my career and it was just a given.
It's been a long while but, especially as a young employee (presumably) expecting to have relocation handled, I'd be WTF; the relocation would probably have been a huge chunk of my salary at the time. Of course, at that point, you're probably just screwed and you're probably not going to get a lawyer over it.
I'm talking about somewhat longer ago but it used to just be part of the deal along with living expenses for a month or so in my experience for professional jobs.
Having to relocate a long distance would have been a huge barrier for me both for cost and other reasons at the time. Obviously remote is a bigger option these days but far from universal. Glad it wasn't a problem both times I did even if the cost and other obstacles weren't as great at the time.
The one time I had an employer involved that closely they completely dropped the ball and I had to crash on a friend's couch. Again I don't think having corporate administration so closely involved in your life is a great idea just because of the dumb things they occasionally do.
I disagree on the "taste" aspect: I don't think it's valuable to take that into account in the slightest.
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.
I've been using a variation on the "Code Review" example for years, and really like it. I give the candidate some fairly straightforward sample code[1] that interacts with a Python library[2] along with a couple user stories that they are expected to implement. I tell them I'm both their product manager and pair programming buddy, and that they should ask me any questions they might have, use ChatGPT, consult Stack Overflow...whatever they do to solve the problem at hand because I'm just interested in seeing how they think.
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.
I don't want to give away my secrets, because this has actually worked really well for me and I'm afraid that I'll lose my edge as an employer - however I have a very small neck of the woods and HN seems very US-centric so I think I'll be ok.
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+).
They think everyone wants to work for ping pong. It’s delusional. All it takes is one bad decision to send everyone running. Leaders are so high on their own egos that they think no one would ever want to leave, but we do.
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.
> most interview questions have very little to do with day-to-day responsibilities. all good software engineers are generalist and live coding does not select for generalists
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.
>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.
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.
I helped my friend from university get a job by helping him do their take-home exercise. I didn't write the code for him but I walked him through pretty much every single step. I'm not proud of that but my friend needed a job and I was in a position to help him get it. My principles are not nearly as important as that job was to him.
Yes, people can cheat. In my example, you can mitigate by having them also do a live presentation and ask probing questions about what they've written if that's part of the job.
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.
There's a difference between live coding round and leetcode rounds where you need to perfectly write code for as medium or hard leetcode question in 20 minutes.
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?
> 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.
The question is, however, whether this is a good proxy for one's future colleague and employee.
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.
> It’s not perfect, but I won’t hire anyone that can’t pass a live coding round
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.
He mentioned that Oxide has an interview process that takes 20 hours realistically between coming up with work samples, answering 8 questions before hand and 9 hours of in person interviews.
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.
So glad I changed industries after my first s/w job out of uni wanted 2 hrs unpaid overtime per day and the boss ran the office like he was lord of the manner, swearing and blowing up whenever it suited him. If I had the skills these people want for the price they're willing to pay I'd just start my own business and reap the rewards myself. Most people aren't worth working for. Perhaps the pool of employers is far larger in the US which makes it easier to shop around for a good one.
Just talk to people. Seriously. If you're "an expert", then >80% of the time you can figure out if someone is an expert in the same topic just by talking to them. See how they think and problem solve. That's the skills they'll be using on the job anyways.
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.
I’ve interviewed enough people to staff a company and I disagree.
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).
> when confronted with with a 50 line class full of glaring issues
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.
It’s a self contained class that is littered with basic errors and doesn’t actually do what it’s supposed to do. There’s about 15 things wrong - missing pointer checks, uninitialised variables, public variables with private get/set functions, a memory leak, logic bugs that don’t do what the prompt says it’s supposed to do, subtle behavioural issues that come up in edge cases. We’re not looking for every single one, but there is an alarming number of people who cannot identify even the most glaring issues of “there’s a new in the constructor and not a delete in the destructor”.
> 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.
Thanks for the additional detail. It sounds like a great interview question; it's both easier, and yet more real-life, than something like "write fizz-buzz".
I agree. I've interviewed loads of people, without ever giving a job to someone who couldn't do the work.
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.
[dead]
individual manager discretion produces widely variable outcomes at scale, a lot of (most?) managers are promoted “by default” because the company is growing quickly, or lost a key person, and there is no better choice available, and it would be hard work to go find and recruit a better choice and nobody wants to do that work. So we add process and structure to help underqualified personnel not totally screw it up, which produces fine results for a while until hierarchy and process gets too heavy and marginal returns start to decay, and viola. Leetcode and AI screening.
No my passion isn’t my job. I have a long list of things I do for fun. Sitting at a computer is not one of them. My job is transactional - an exchange of labor for money.
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.
Everyone calls them Interviews but they are not really interviews. They are exams.
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 not engineers, and has not passed a licensing board or belong to any professional associations.
Most devs are doing work that more closely resembles pipe fitting or carpentry than any engineering discipline.
> 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.
The field of programming emerged from mathematics, not engineering unfortunately. So we lack any useful certification processes.
The only issue is that Software Engineering (is that the term we use?) does have more churn and change than other types that have PEs like Civil.
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.
Sounds like you’re arguing for a professional licensing regime to exist
There should be. Engineers are liable for their failure.
And on the plus side that liability also provides people a lever with which they can push back against stupid managerial decisions. My father was an aeronautical engineer, and his favorite word to say to management was "No". Yes, the engine inspection takes a long time. No, I cannot cut corners in any way just to save you some money (No idea if this is just one of his stories or a real situation, but you get the idea :p ).
I don't know why people are so against it in this field
We have this idea that gatekeeping in all its forms is bad; and like all absolutes it is not true.
In software at least, professional licensing exams basically petered out because no one required them so no one cared.
My guess is that it would impede outsourcing and end up costing companies too much money.
In general, licensing is for regulatory reasons (e.g. signing off on drawings). Engineers don't generally do it unless there is some industry requirement to do so (especially in civil engineering). And there mostly isn't in software.
I started the engineer-in-training track when I was in the offshore drilling industry but then I left and never went back.
Our process is fairly simple:
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.
Have you ever integrated code a candidate wrote into a code base? Have you ever met anyone that have?
Ask yourself why not
Maybe you should have read the whole sentence.
(I do the interviews at our company, but I'm just a regular dev and not in management or HR or anything like that)
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.
> veto right
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.
Francis Fukuyama calls this system (everyone gets a veto) a vetocracy, and it basically means that nothing ever gets done
Surely a 15 minute phone screen at the beginning with an HR rep would help thin the field, no? Just something quick for them to show that they know how to act appropriately, dress professionally, show up on time, and speak the language. Plus it provides an opportunity for the HR rep to show a roadmap of the process and the candidate an opportunity to ask broad details in case they need to back out.
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.
Dressing professionally is not important for software development jobs. People at my company wear a wide range of clothing, and I haven't seen anyone making an issue of it.
Everyone says that until they start sitting in on interviews and someone is wearing a confederate flag shirt or their areola is clearly showing.
2. "...but in this case you have to show os some of your work from the past, so we can discuss this."
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.
Maybe that attitude works in a big company, but it won't fly in a smaller one. I'm a software engineer and I write plenty of code, but I also help out with interviews, packing, sales demos and proposals, customer support, general IT support, etc. Hell, I've fixed the coffee machine! I'd absolutely hate it if writing code was my only task.
I understand you and did the same in the past.
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
2. Then they do the take home challenge, or you hire another candidate. 3. No, normal wage and is expected of them. 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
2. Then they do the take home challenge, or you hire another candidate.
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.
> 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?
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?
I get paid to bring my knowledge and skills about computers and systems to bring business value to the company - to make them money or to save them money.
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.
> companies often over-index on crystallized knowledge over fluid intelligence.
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.
i am a data engineer (2 yoe) who speaks multiple languages and thinks in systems. i am looking to switch jobs as the problems i work on at my job are not as interesting as i would hope. also i am underpaid. can you point me to your hiring funnel?
> interviews should: be applicable. reflect the actual job duties
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.)
The problem with leetcode is time. If you know a good solution to a puzzle, or can instantly come up with it, you have the time to write it down, make it work, discuss, improve, etc. If you spend extra 10 minutes on a wrong approach, you're very strained, and if you spend 15 minutes, you're toast.
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.
> 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?"
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.
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).
>you're partly testing people's ability to (appear to) perform under acute pressure
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.
As much as I dislike leetcode style interviews, if I fail one of those, I learn what I can and move on.
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.
I've had the complete opposite experience, and feel the complete opposite way. What is there to learn from failing a leetcode? It feels like luck of the draw - I didn't study that specific problem type and so failed. Also, there is an up front cost of several months to cover and study a wide array of leetcode problems.
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.
I feel the complete and total opposite. With leetcode-esque ones it's just a luck of the draw that you can conjure up the memory for whatever it is they're asking you to do. The decent ones are the ones that at least are somewhat realistic, but the truly terrible ones are those where you have to remember how to do an algo of some sort but you have no access to outside tools of any kind. I've never come out of a leetcode and felt like I learned anything or could've done something better, not to mention the artificially crafted high stress environment. I feel like they also literally never reflect anything even approaching the actual work, either, and basically test your memory more than anything else. There's a reason there's a billion books out there about how to "crack" the leetcode style interviews.
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.
I don't get it, every job I have interviewed for since 2013 has had a take home. A couple of them waived it in my case but otherwise they all had take homes. Where are these jobs where people don't get given take homes?
When you are rapidly hiring, giving a candidate 2 weeks to complete a take home is a huge drag on the process. Instead, sandwiching 3 interviews (resume walk, leetcode, system design) into a 3 hour time period lets candidates move through the process faster.
hmm most of the take homes I ever got had a 1 week to complete but I guess I see it, I don't think I've ever been trying to get on a company that is hiring more than a small time at any time.
meta, google, amazon don't have take home
Basically all big companies doing industrial scale hiring ( and firing) that don't have time or patience for take homes.
GitHub (pre-microsoft at least) and Crowdstrike both did. Amazon didn't have a take home so much as a "prove you can write code with this simple problem" though that was also pre-AI days as well.
In Australia, AWS dev position in 2021 had a take home. Microsoft contract position before that didn’t but they were desperate to fill seats on a poorly executed gov contract.
> Basically all big companies doing industrial scala hiring ( and firing)
Is Scala the right choice for hiring and firing, though? If they need to fire quickly, why not straight machine code?
I believe this is a typo for SCADA, which would control the industrial machinery used to fire employees in order to ensure distance and accuracy.
to pretend that they care about safety
I can't speak to developer roles specifically. But the last job I had (for a long time), I just dropped an email to someone who was a client. I think a fair number of the developers at the company came through internships or referrals and AFAIK takehomes weren't a thing.
What year?
2010.
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.
I love take home and don't like leetcode, so I was thinking: choose a company based on how they interview, might help with culture fit?
Agree. leetcode is the greatest thing that happened to tech interviews.
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.
With all those leetcode acers, why is software slow as molasses? You would think they pattern match for the most efficient algo with all this training.
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.
> In my experience the more impressive somebody is at leet code, the worse their production code.
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.
Leetcode is all local cpu. Production code is all waiting for network responses.
Interviews need to give signal to the employer. Having a couple decades experience now, working high scale, highly available services, and having designed interviews for thousands of candidates and given hundreds of interviews across half a dozen software engineering orgs, leetcode is poor signal.
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.
>Get good at it
>with no prep.
You contradicted yourself in the same sentence. You can't get good at leetcoding interviews with no prep
After getting good at it, there is no "additional" prep time, unlike take homes, where you would need to spend hours for every individual assignment. Is that so hard to understand?
>After getting good at it
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.
I don't mean to be harsh, but as an engineer you owe it to yourself to try and get better at interviewing. Does it suck? Yeah absolutely. Is it an annoying process? Definitely. But even if you have an easy and stable job things can change quickly at any company. You're only closing doors on yourself.
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.
It's hard to get better when you don't get feedback
Not a huge AI guy but this is something LLMs can do quite well (less so before gpt-5 because that model was a sycophant) but I learned a lot about personality interviews by simply having the AI throw questions at me and then taking my answers apart.
I'm happy to provide feedback for anyone reading this - Mock interviews or code challenge reviews. No guarantee it's helpful but I'm not a black hole at least!
Self reflection amend critique are skills too.
Not sure if they're still doing it, but GitLab does the code review interview, and I too really liked it.
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.
The OP thinks that candidates spending a lot of time on applications is OK, as long as the company shows respect by spending a lot of time themselves. I think this is mistaken - I care about how much time I have to spend, and am a lot less concerned about how much time the company takes.
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.
Excellent point. And for anyone who’s been a hiring manager / recruiter, you know how many candidates you will have to sort through. And you want to waste as little of your engineers’ time making them do interviews if possible.
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.
You made your edit before I posted.
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 meet a few college CS candidates, and I really empathize with what they’re facing now.
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.
Last time I was looking, a year or so ago, I sent out dozens of applications and got zero interviews. Last time I switched jobs, in 2022, I sent out the same amount of applications and >50% led to one or more interviews (and eventually two offers).
Historically, I'm not sure that isn't fairly normal.
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.
“Okay boomer” (said sarcastically - I’m 51).
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.
I think it's reasonable to make a donation on behalf or provide an honorarium if someone makes it far enough into the process. Something like a $250 gift card or equivalent.
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.
>The OP thinks that candidates spending a lot of time on applications is OK, as long as the company shows respect by spending a lot of time themselves
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.
The situation is not going to improve as long as business stakeholders and engineering managers (some closer to MBAs than actual engineers) think of software engineers as construction workers. They think we are fungible, they don't understand the craft of programming etc, and have very short term mindsets. Took me a while but then I realised that I needed to interview my prospective employers as much as they were interviewing me, and to just ignore those not worth working for.
> "They think we are fungible"
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?
At the very least understanding of the specific domain comes to mind.
We are fungible. Most software development is not rocket science. If any of us got hit by a bus tomorrow HR would send our next of kin “thoughts and prayers”, a flower and tell them how to collect our life insurance and then immediately open a req and get flooded with hundreds of probably good enough replacements.
> I realised that I needed to interview my prospective employers as much as they were interviewing me
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.
> 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.
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.
It sounds like what you're arguing for is that companies ought to have employees that are irreplaceable. Wouldn't that impose a huge risk to the company? If said employee gets hit by the proverbial bus or leaves, the company should just fold?
Companies need to build systems where everyone is replaceable to de-risk the business and not because they don't get programmers.
If a company doesn't have irreplaceable people, then that company is not doing anything interesting. Conversely, if replaceable people can produce your (software) product, then any other company can also do it.
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.
But they ( companies ) don't. Looking back at my career, what you do get is, various ranges of alignment to an idea ( whatever it may be ). Some companies do it better than others. Usually, the smaller the company, the easier it is for the owner/founder/main guy to make sure his vision is appropriately enforced, but that gets so much harder in bigger ones so the systems they generate get progressively less sensible. And yes, I don't think search for absolutely replaceable employees shows any kind of faith in one's company. It does, however, show an interesting frame of mind that I personally like to avoid.
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.
It's crazy, I've been trying to hire an architect to build a house for me, but I don't trust them (they're all liars) so I asked them to draw up blueprints in front of me and describe everything they are doing in great detail. I need to understand what they are doing. This building is important and I don't want a bad hire. They should be able to do this in 10-15 minutes. If they knew what they were doing, this request wouldn't be an issue.
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.
AI!
My best job (for the last decade) for a software engineering job was a 1 hour technical interview followed by a 1 hour interview with the director.
It helped that it was 90 days contract to hire.
Well structured temp to perm arrangements are usually win-win?
I really loved the uno reverse card interview the author recommended. "Let's debug this piece of broken code"
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.
Debugging exercises reveal not just technical knowledge but also communication patterns - how candidates ask clarifying questions and explain their reasoning reveals more about their daily work habits than most algorithm puzzles.
I also loved the idea.
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.
If I was asked to review code in an interview, I'd prefer it be printed out on a sheet of A2 or A3 paper that I could look over and write on.
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.
For live debugging/fixing we were sharing a dedicated GitHub repo, and the candidate would share his screen while doing it. It was kinda of a mess, so I switched to a more static approach of sharing a MR and have the candidate explain what it does, and potentially comment on it.
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.
If I can get a person talking about tradeoffs - be it speaking to a past project, or a hypothetical I give them - then I think I can tell who the serious developers are fairly quickly.
I agree with the article. Discussing previously created code and do code reviews live covers a lot of ground. Whereas live coding is just meaningless for the stated reasons.
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.
As long as someone isn't relocating, it's possibly reasonable. As long as someone is moving, there's a lot bigger barrier to taking a job. Mind you, there's is a barrier in any case if someone has a decent-paying job but just isn't loving it.
The primary problem with hiring is that developers are a single status with not performance benchmark. The solution is to segment need by capability.
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.
Now the issue is to identify them. All those types of workers will present themselves as Software Developers (or Software Engineers), so the interview process is not only an entry filter, but a classification filter too. You (as a company, or as an interviewer) need to discern which are the strengths of a candidate, and also the skill level within each of those categories.
> 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.
Why? People who actually write original software require many other skills in order to do so (just not, you know, marketing).
Writing software is no different than writing a novel or a music album. Its creating a product. All of these require the ability to write, but its more than just writing an essay. There are functional aspects that require different stages of planning and composition that must be put together in a way that can be maintained, described, and decomposed. Its that vision for composition and extension which requires organizational capacity drawn from lots of experience.
> this also loses you taste
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.
At my first employer circa 2005 we had a simple 1-2 hour interview and a 90 day probationary period. Respected people's time, gave everyone a fair chance to prove themselves. I don't know why it's not more common in the industry.
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.
Well, historically, taking a new job often meant relocating which is a big expense for the employer (who typically paid relo for engineering jobs) and is hugely disruptive for the employee. Definitely not just a shrug for everyone concerned if things don't work out after a bit.
Less true in hotbeds for a given industry. But I've had relocation paid twice in my career and it was just a given.
Never in my 25 years has an employer made good on their offer to help with relocating. Often they expect you to be there already.
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.
> They’ll say they will help. Even have you fill out a form.
Have they not formed a verbal contract in saying they'll help with relocation expenses?
It's been a long while but, especially as a young employee (presumably) expecting to have relocation handled, I'd be WTF; the relocation would probably have been a huge chunk of my salary at the time. Of course, at that point, you're probably just screwed and you're probably not going to get a lawyer over it.
I'm talking about somewhat longer ago but it used to just be part of the deal along with living expenses for a month or so in my experience for professional jobs.
Been working professionally since ‘97, still haven’t ever gotten a payment for moving expenses.
The way it's worked for me is I've been given a small relocation bonus and then I'm responsible for figuring the details out.
So assistance really just means punt
Having to relocate a long distance would have been a huge barrier for me both for cost and other reasons at the time. Obviously remote is a bigger option these days but far from universal. Glad it wasn't a problem both times I did even if the cost and other obstacles weren't as great at the time.
Would you really want anything else? I can't really imagine how you're expecting that to work.
In my experience the employer (2x) took care of arrangements for both the moving and the temporary hotel arrangements.
The one time I had an employer involved that closely they completely dropped the ball and I had to crash on a friend's couch. Again I don't think having corporate administration so closely involved in your life is a great idea just because of the dumb things they occasionally do.
Early in my career, most of the people I interviewed were not very good.
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.
I disagree on the "taste" aspect: I don't think it's valuable to take that into account in the slightest.
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.
I've been using a variation on the "Code Review" example for years, and really like it. I give the candidate some fairly straightforward sample code[1] that interacts with a Python library[2] along with a couple user stories that they are expected to implement. I tell them I'm both their product manager and pair programming buddy, and that they should ask me any questions they might have, use ChatGPT, consult Stack Overflow...whatever they do to solve the problem at hand because I'm just interested in seeing how they think.
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.
Duplicate: https://news.ycombinator.com/item?id=44843256
job ads used to say "thrives under pressure" as a kind of euphemism
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
I don't want to give away my secrets, because this has actually worked really well for me and I'm afraid that I'll lose my edge as an employer - however I have a very small neck of the woods and HN seems very US-centric so I think I'll be ok.
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+).
The best interview process I’ve ever done is sitting down with the team for 3 days, crashing on the founders couch for the weekend and shipping code
The worst ones were the leetcode interviews I couldn’t pass
> select for applicants who will be good employees for years to come
Why would you do this given the expected average tenure is probably like 18 months to 2 years?
They think everyone wants to work for ping pong. It’s delusional. All it takes is one bad decision to send everyone running. Leaders are so high on their own egos that they think no one would ever want to leave, but we do.
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 sorry. I don’t understand what your comment has to do with mine?
Tenure and young folks not staying longer than 2 years… read it again.
I’m agreeing with you and stating that corporate leadership is out of touch.
> most interview questions have very little to do with day-to-day responsibilities. all good software engineers are generalist and live coding does not select for generalists
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.
>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.
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.
I helped my friend from university get a job by helping him do their take-home exercise. I didn't write the code for him but I walked him through pretty much every single step. I'm not proud of that but my friend needed a job and I was in a position to help him get it. My principles are not nearly as important as that job was to him.
If you let people cheat they will cheat.
Yes, people can cheat. In my example, you can mitigate by having them also do a live presentation and ask probing questions about what they've written if that's part of the job.
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.
There's a difference between live coding round and leetcode rounds where you need to perfectly write code for as medium or hard leetcode question in 20 minutes.
1) that’s not what most companies do
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?
> 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.
Good points. Most FAANG/MANGO companies in India do leetcode. And I know Amazon still does leetcode in US/Europe.
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.
The question is, however, whether this is a good proxy for one's future colleague and employee.
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.
Totally valid critique.
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.
> It’s not perfect, but I won’t hire anyone that can’t pass a live coding round
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.
> I won’t hire anyone that can’t pass a live coding round.
Excellent - please be sure to mention this in the job description so I can know to never apply to where you work.
Don’t worry: it doesn’t sound like that will be something you’ll have to be concerned with.
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.
> 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.
[flagged]
He mentioned that Oxide has an interview process that takes 20 hours realistically between coming up with work samples, answering 8 questions before hand and 9 hours of in person interviews.
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.
So glad I changed industries after my first s/w job out of uni wanted 2 hrs unpaid overtime per day and the boss ran the office like he was lord of the manner, swearing and blowing up whenever it suited him. If I had the skills these people want for the price they're willing to pay I'd just start my own business and reap the rewards myself. Most people aren't worth working for. Perhaps the pool of employers is far larger in the US which makes it easier to shop around for a good one.
The expression is https://en.wikipedia.org/wiki/Lord_of_the_manor .
Thanks, always helps the message when you grammar right.