> 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.

Solving complex riddles may not prove you're Einstein, but it's a pretty good filter for morons.

Disagree. I’m very good at puzzles.

then you shouldn't have said you're a moron. You seem somewhat contrary, which leads to its own problems, at least for me.

Disagree. I’m highly agreeable.