I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.
You can do this too. Anyone can. I’m basically a moron and I managed to convince our talent team to radically change how we do things; if I can do it I feel like the bar is pretty damn low.
The only real requirement is that enough of us simply refuse to accept how things are today. Right now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers and are almost certainly willing to listen to suggestions on how to stand out.
> I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.
I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests.
If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure.
I will never judge someone based on that kind of problem. I believe the data that results is just bad.
Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.
> I think companies that break out of the leetcode habit are going to do well.
> There's a lot of great talent out there that's being passed over by these tests.
Agreed. And there's a lot of great talent that doesn't even want to try with some of these companies solely due to the hostile interview process.
I recently took a year off, and started interviewing in March. I spent a fair amount of time in fear of interviewing, doing LeetCode pushups and feeling miserable about my performance, and wondering if I could swing retirement rather than go through another fucking hazing ritual. Excuse my language.
I resolved up front not to submit to any kind of take-home test, proctoring software, or algorithmic nonsense unrelated to the actual job of shipping software. A polite "No thank you" was what I planned. But the plan was thwarted!
I was pleasantly surprised by the technical interviews I actually got. They were mostly nicely constrained problems that were real-world and not algorithmically nasty. One was a little unintended "collaboration" in the form of helping a senior dev debug their own "what is wrong with this code?" exercise (it probably went smoother for the next candidate they interviewed). In short, it was actually kind of fun.
I started a new dream job this week. At 61 this is no longer easy, but the company is enlightened enough to support me while I get up to speed, and it's fun to help mentor the folks just getting into the industry.
There are decent companies out there. Hopefully the terrible ones will start getting a clue.
Ideally, interview questions should be directly related to the domain of the position. Show the candidate what they will actually be doing if they accept an offer.
The whole process should be a two way conversation.
Agreed. As a hiring manager, I’ve also explicitly, purposely come up with coding questions that reflect normal work: call APIs & issues, sync data issues, model data for usable systems.
The hires, then, focus on the right customer problems and don’t spin on creating random, useless code.
Everyone from mgmt to ICs, technical and non-technical, are happier.
Yeah, I've worked in tech 6 years now and never had to do Leetcode to get by in interviews. That being said, I never interviewed at FAANG. But many teams set a bar easier to pass than leetcode that still ensures good engineering skills
> now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers
Unfortunately, this will likely change much sooner and more rapidly then most of us expect. The music is stopping and chairs are about to be removed. It was great while it lasted, but all good things come to an end.
I’m not sure I agree, but I’m positive this isn’t a barrier to adoption right now. Recruiters are really looking for an edge to provide differentiation, and “friendlier, faster process” is a big one.
What has changed in the past 20 years? Because this sounds like the same shit I’ve heard since entering the industry. And it isn’t like this topic is new at all.
The overview is that for each candidate we spend 20 minutes reading through code we provide to them to demonstrate comprehension, and then we give them 45 minutes to pair with us on reimplementing that same code from scratch.
What that code is doesn’t really matter, it’s more about getting a chance to work with them and start a conversation, and starting with trying to explain a provided example really smooths the way into the pair programming.
Do you require pairing on real work? How do you handle candidates who need quiet to think? Going by the continual complaints about open plan offices, there seem to be a lot of us.
We require that ICs are able to work with others effectively; we have a very large engineering team working on issues related to health care and collaboration is effectively mandatory.
We keep the pairing as short as we can and we provide breaks between the short sessions to be as friendly as we can without being unrealistic as to what the candidate should expect in the actual job.
We went from a process that took weeks to get through (multiple interviews, about an hour each, with a full code day at the end) to a two step process. Talent reaches out to the candidate and has a thirty or so minute chat to make sure the candidate meets basic hiring requirements, and then we have our MINASWAN process which is a single three hour interview, including two breaks for the candidate to get off camera and catch their breath.
The participants are:
- the candidate
- a hiring manager
- between two and four developers for pairing
- an open invitation to the hiring team’s devs for a closing panel interview.
The feedback we’ve received from candidates has been overwhelmingly positive, even for those who didn’t receive an offer.
FWIW, happy you're doing this! A better process would make so many peoples' lives better.
The ONLY people who should "get used to 'em" are new/recent grads looking for a junior-ish IC job. For them, it's just a fact of life: they had to learn history & biology to get their CS degree; they have to learn leetcode to get a job.
Interviewers should make a better process, as you're doing.
Honestly, I think I would encourage junior devs to shop around before just accepting the leet code life. Unless they’re in dire need of income—in which case, do what you need to do—the kind of company willing to treat you like a game show contestant may not provide the best culture for learning and growth.
If you can avoid the BS you should definitely do so.
I’m not sure if you’re just being snarky or you’re trying to make an actual point here, but I can tell you that this kind of commentary reinforces the egocentric interview process we currently suffer through.
Solving puzzles doesn’t prove that you’re smart, and not memorizing them ahead doesn’t prove you can’t do the job. Unless you’re really on the edge of the industry—designing rockets for NASA or surgery tech or something—most dev jobs aren’t really all that hard, and we should stop pretending they are.
> most dev jobs aren’t really all that hard, and we should stop pretending they are.
I agree with you about GP's commentary, but I don't know that I agree with this statement.
Getting something working is often relatively easy. Shipping v1.0 is often relatively easy. But it starts to get gnarly as you build out capabilities, add services, split concerns up, have to maintain compatibility with previous versions, dependencies multiply, the amount of data you're dealing with massively expands, and so on. Most problems have one or more inflection points, whether that's around performance, or scale, or volume of data, or whatever, that when you pass them make that problem substantially harder to solve.
Still, these are all issues that come with a certain amount of success. Not necessarily crazy success: I'm just talking about the kind of traction that companies that grow to earn millions to tens of millions of dollars or pounds per annum experience.
The really hard part of being a dev, of course, is knowing what the right thing is to build. Often, because users tend to struggle to articulate their needs, the only way to find out what to build is to start by building something that you know is probably going to be at least a bit wrong, if not massively wide of the mark, just to get some feedback. And then you have to iterate, sometimes quite painfully, towards an actually good solution from there. Of course, this isn't something you can assess with a leetcode interview.
I don't hate interviews where the candidate is asked to write some code. I think writing code is a valid form of assessment because I've encountered enough jokers over the years who couldn't program if their life depended upon it - yet still manage to carry a job title like "software developer" - that I need some way of weeding them out of our hiring process. One reason for this is that I simply don't have gobs of spare cash to pay large salaries to people who are fundamentally incapable of doing the job they're asked to do.
Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs).
Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room, and I think leetcode often falls into this category. I find this perverse and unhelpful but I guess these interviewers are just insecure, angry people.
I ask candidates to write code, but I tell my interviewers that the point is not completing the task but rather the conversation around it.
If they can’t write code at all, obviously it’s a hard pass because we’d just be setting them up for failure. But, if they’re maybe not the strongest dev ever but ask good questions and provide good observations I will be fairly likely to hire anyways. Honestly having people with room to grow just gives the rest of the team opportunities to teach… which in turn helps them to grow too.
I also tell my interviewers that we absolutely must start with the assumption that we will hire the candidate, and passing on them requires objective concerns. I really work hard to relate to my team that we are not so special that we should only hire the absolute best of all experts. What we do is not rocket science, and we don’t need rocket scientists. We need collaborative, intelligent team members to help /us/ grow.
All of this is to try to limit the impact of ego on the hiring process. It’s not about the candidate proving that they’re good enough to work with us, it’s about us being good enough to be worth working with. The candidate should meet the bar of helping us to make that statement true.
To be clear, dev roles can be difficult, demanding jobs. I’m not diminishing that, just reigning it back into the realm of reality. The industry treats hiring like people are going to die if we make mistakes, and unless that is actually true maybe it’s worth asking if what we’re doing is actually reflective of the job requirements.
> To be clear, dev roles can be difficult, demanding jobs. I’m not diminishing that, just reigning it back into the realm of reality. The industry treats hiring like people are going to die if we make mistakes, and unless that is actually true maybe it’s worth asking if what we’re doing is actually reflective of the job requirements.
This I agree with.
I'd also say that our worst mistakes have generally not been technical, though I don't want to go into the specifics here.
It matters more that you get the right person with the right skills for more senior hires, because they can have an outsized impact on business and delivery outcomes. I've seen the wrong person running a team lead to 6 months of rework when they left, as an example.
> Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs).
This is the best way I've found to assess if the interviewee can actually do the job. If you're trying out to be a violinist in an orchestra, they'll give you some sheet music and ask you to play your instrument. Leetcode would be like sitting the prospective violinist down at a piano, then asking them how to resolve exotic chord progressions and grilling them on obscure music theory. Yeah, any great violinist who studied at a decent music academy probably learned that stuff and still remembers it, but it's still a stupid test for the job you're asking them to do.
> Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room
I'm even more cynical. People who were hazed to get where they are tend to want the new people to get hazed too. To them, it's only fair. And make no mistake, leetcode is hazing: it's not a test of ability, it's a test of how hard you're willing to grind for the possibility of giving a company your labor.
I think it can make sense in only one instance: for entry-level positions, if the person is trying to break into the software industry and they don't have a relevant degree. These people simply won't be able to do the same stuff that someone who's had a relevant position (or even just an internship) would. Navigating an unfamiliar IDE alone might kill them. But if they've done a bootcamp and they can crush some hard puzzles, they're probably competent enough to train up quickly, and it they're eager and they seem like they'd be great to work with, it can absolutely make sense to bring them onboard.
For everyone else, I just want them to show me what they've done in the past, and I want to test them on a problemset similar to what they'd actually be doing on the job just to make sure they're not full of shit. This is usually much less stressful for everyone involved, and provides a much more accurate signal.
The reason Google doesn't do this is likely for HR reasons: for a given position, they have to try to give the exact same interview questions to each candidate, as steering individual interviews in different directions on a whim can open them up to discrimination lawsuits. For example: women applicants might have less technical backgrounds on average, be given leetcode problems, and then the company could rightfully be accused of giving a typical woman a harder set of questions than men.
But there's opportunity there. While companies of Google's size are forced to formalize and lock down their interviews pretty hard out of an abundance of caution, smaller companies have a lot more freedom to tailor interviews to the individual candidate to figure out if they're right for the job. Great hiring managers figured out years ago that you can build a stellar team by snatching up the really talented folks who either refuse to play the leetcode game or happen to have a life outside of work. They're easy to identify if you're looking for them.
> I think it can make sense in only one instance: for entry-level positions, if the person is trying to break into the software industry and they don't have a relevant degree.
I'm not even sure I think it's necessary here.
We have a guy working for us who's a former nurse, and was still a nurse when he interviewed with us. He'd started programming on the side as a hobby, and our job ads were pretty explicit that we didn't really care about your background as long as you could program and were a reasonable human being, so he applied.
We still have a very short (20 - 30 minute) pre-screener interview before our main interview (90 - 120 minutes). That pre-screener has three objectives:
1. Figure out if the candidate is really interested in the job. We're not expecting people to turn tricks to show their enthusiasm or anything ridiculous like that, but we've had enough candidates that give off a "totally can't be arsed" vibe that we're basically just looking to screen those out.
2. Quick read on what the candidate is like as a human being.
3. Answer the question: can they write any code at all?
For (3) we have a whole raft of simple problems that require the candidate to write half a dozen or so lines of code. We'll generally explain the problem, given them an empty method or function and ask them to fill it in.
One example is write a function to reverse a string: this one's interesting because, in C# as an example, there's a functional solution, and an imperative solution (of course, there are several variations). The functional solution is enough to understand whether they at least grasp the basics of functional programming. The imperative solution will tell you whether they know how to use basic control flow and iteration, understand arrays (a string is really a wrapped array of characters), know about mutability and immutability, etc. Most of our code is OO/imperative, with some use of a more functional style where appropriate, so we generally encourage in the direction of imperative.
All our pre-screener problems are kind of like this: basic numeric or string manipulations, because our systems contain a lot of numeric and string manipulation. Definitely not leetcode: most of these problems don't require any knowledge of data structures more advanced than an array. It is literally: can this person code in any language similar to what we use here at all?
Our former nurse nailed the pre-screener first try - didn't even get caught out by any off by one errors. Whereas I've seen plenty of "senior developers" completely fail at these very basic tasks.
Our full interview involves a more in-depth pair programming exercise. Again, our former nurse nailed it, where plenty of more experienced candidates have made a right hash of it.
We took on our former nurse with both him and us realising that he'd have loads to learn, but four years later he's still with us and doing incredibly well.
This is obviously anecdata, but it does show that you don't necessarily need leetcode to assess someone entirely new to software development.
Only on the internet, that someone working for a cost-center division, building an piece of internal software used by 20 users, gets to lecture how a $2 Trillion Dollar, building multiple Billion real-world user products, generating > $500,000 per engineer profit should run their hiring process
No.
I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.
You can do this too. Anyone can. I’m basically a moron and I managed to convince our talent team to radically change how we do things; if I can do it I feel like the bar is pretty damn low.
The only real requirement is that enough of us simply refuse to accept how things are today. Right now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers and are almost certainly willing to listen to suggestions on how to stand out.