An engineer's perspective on hiring
84 comments
·August 9, 2025joshuamoyers
jamboca
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?
tomquirk
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.
shahbaby
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.
bryanrasmussen
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?
qudat
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.
ghaff
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.
Henchman21
What year?
apwell23
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.
layoric
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.
filesfiles
> 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?
apwell23
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.
bombela
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.
derivagral
> 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.
pxeger1
> 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.)
simpaticoder
>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.
erehweb
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.
Esophagus4
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.
ghaff
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.
Esophagus4
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.
bryanrasmussen
>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.
roland35
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.
tayo42
It's hard to get better when you don't get feedback
charcircuit
Self reflection amend critique are skills too.
ozgung
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.
master_crab
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.
Henchman21
Sounds like you’re arguing for a professional licensing regime to exist
0x264
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.
nouveaux
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.
A4ET8a8uTh0_v2
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.
lsdforme
> 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.
zahlman
> 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.
liampulles
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.
null
billy99k
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.
> 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.