Hacker News Reader

Comment by zelly | Hacker News Reader

I fear there's a movement to get rid of leetcode interviews and I'm against it. What's the alternative? We go back to "you have to look the part", nepotism, credentialism, and other such BS in other industries. A data structures and algorithms test is fair and objective. You can objectively get all the challenges correct and then there's little reason to not hire you. Compare that to interviewing for, say, an investment banking position where you're judged on stuff like what frat you were a member of and how charismatic you are.

View on HN

There are more alternatives than "look the part" and "leetcode". If I'm hiring a software engineer, I'm not hiring for how they look - the compiler doesn't care. And I'm (probably) not hiring for the ability to solve leetcode problems, either - of the work I would assign to someone I'm hiring, almost zero of it looks like leetcode problems.

What I need is a way that tells whether the person I'm interviewing can actually do the work that I'm hiring them to do. Maybe I should ask them about that. Maybe I should give them some problems similar to the actual work.

> What I need is a way that tells whether the person I'm interviewing can actually do the work that I'm hiring them to do. Maybe I should ask them about that. Maybe I should give them some problems similar to the actual work.

Would you mind sharing with us how to draw the rest of the owl?

Look, I don't even want to defend leetcode here, but it is a struggle to find questions that are:

1) Correlated with the actual work performance

2) Neat enough to be explained and solved in the course of an interview

3) Have objective enough answers so that it's possible to overcome likability bias in interviewers

4) Have objective enough answers to be able to meaningfully compare different candidates

5) Demonstrate that candidates can actually go from hearing a description of the problem to producing code that solves the problem

The best I've ever seen is the way my current boss does it. We do a two-hour interview (they've already passed a phone interview before we bring them in). We spend the first half hour just talking to them personally.

Then we give them a piece of code on paper. It's fairly simple - half a page. The function name is foo(). It's written in C#, but we don't expect them to actually know any C# details. The function takes an array of Strings as input, and returns an int. The questions are, what values does it expect for the Strings, what value does it return, what would they name the function, and what can go wrong (what exceptions can it throw - but we don't expect them to know the details of C# exceptions, so what might cause exception-like circumstances). This shouldn't take more than half an hour.

Also, it's the same code for every candidate, and we've seen a few dozen over the years, so we are fairly calibrated on how a quality candidate should do.

Then we ask them to write some code on the whiteboard. We give them a simple problem (again, same problem for every candidate). They can use any language they want. We don't expect them to be a compiler - we don't care if they get the parameters a bit wrong on a function call, as long as the code would be sound if the system accepted the syntax they expect. Again, this should take half an hour.

Then we give them a simple design problem. How would you design software to do this? It's a problem that is not rigidly specified, so they can have to flesh out the requirements (hey, welcome to the real world). It's got enough corner cases that we can ask them about one that they skipped, and watch them try to modify the design to handle it. We don't expect perfection - there is no perfect answer for this question. But we want to see them have some kind of reasonable taste or sanity in their design, and some ability to iterate the design as more requirements emerge. Once again, this takes half an hour. They're not done with the problem at the end of half an hour, but we've seen enough to know how they did.

Other than allowing them to ask any questions they want, that's it.

Thanks for the answer.

> Then we ask them to write some code on the whiteboard. We give them a simple problem

Can you share what kind of problem?

This actually sounds pretty close to what we did at my previous company, except that candidates were given a computer (nothing had to compile, it's just that we don't expect anyone to be able to write code on whiteboard) and two coding problems.

First one was pretty simple, such as printing a folder structure with nice indentation (given some predefined input data structure). The second one was harder, although we hired plenty who did not manage to completely solve that one, but if they did it was a plus.

Also had some design questions after that. Some people still complained that the interview was abstract algorithmic nonsense without relevance to real life.

It has some string splitting and manipulation, but nothing that couldn't be done in C. (It would be a lot more tedious, though...)

I don't want to give the exact problem, just in case we interview an HN reader.

> A data structures and algorithms test is fair and objective

The article makes clear that the issue isn't the content of a technical interview, but rather how it is administered. Specifically, from Chris Parnin, a co-author in the study:

> But the format may also serve as a barrier to entire classes of candidates. For example, in our study, all of the women who took the public interview failed, while all of the women who took the private interview passed. Our study was limited, and a larger sample size would be needed to draw firm conclusions, but the idea that the very design of the interview process may effectively exclude an entire class of job candidates is troubling.

So the "objective" in-person tech interview excludes a huge bunch of talented applicants because there is nothing objective about it at all.

> A data structures and algorithms test is fair and objective.

Anything but! For starters, in 2020 brute-force solutions are not acceptable anymore. Then, there are often several working approaches and substantial percentage of interviewers will fail you just because you use the approach they are unfamiliar with.

But even if you implemented the optimal approach, if the interviewer disliked you as a person then they find a way to fail you regardless. "Sloppy code", "bad communication" - no fairness and objectiveness in those assessments.

A juggling test would also be fair and objective. Just hit LeetJuggle for a few months before the interview and you’ll be golden

The study in the article suggests that the same whiteboard question done in private rather than with a judge in the room has all of the benefits with none of the disadvantages in terms of the candidates software skill.

One alternative is providing candidates with a problem to work on for a few hours on their own (have them bring their own laptop, allow them access to Google and their own development environment), then have them walk you through their solution.

Do this as part of the interview and not something they have to do in their "spare time" at home. It's not uncommon for large companies to do all-day interviews anyway, so a way to structure this can be to have the interviewee come in in the morning, provide them the problem and allow them to ask any questions they might have (as if it was a real work problem), then allow them the morning to work on it.

Then in the afternoon you can review the solution and ask them to talk through how they arrived at it and what their thoughts were during the process.

Reply on news.ycombinator.com