Hacker News Reader

Comment by majormajor | Hacker News Reader

So what do you propose as a replacement?

In your case, they should've certainly dug into your open source, at least if it was directly in their line of business.

I certainly love it when I ask a candidate "tell me about a project you found interesting" and they can go into details, talk about tradeoffs, etc. Sadly, most candidates can't. They can't come up with anything better than "well I rewrote the thing, and it was challenging since I hadn't used Kotlin before, learning Kotlin was interesting." So at that point I'm unimpressed, but I'll give them a chance to code still because (a) not everybody has had opportunities to work on interesting stuff and (b) I wouldn't have enough people to hire otherwise.

But if "has open source software we use" is the bar, you're gonna fail a lot more good engineers than you would using algo questions.

View on HN

I ask the same thing you do: "Tell me about a project you've worked on." There is tons of ground we can cover with that:

* implementation choices with pros and cons

* details about how the underlying system works

* domain knowledge, where applicable

* sample code where the candidate writes to mimic something from the system

My interview style has always been: "Tell me what you know, and we'll see if that's true or not." Surprisingly, most candidates fail even that since they don't seem to understand their own projects. But I find this approach the fairest of all since it allows the candidate to lead the interview and it doesn't assume anything about the candidate's knowledge or prior experience.

I work in the same industry as you and I agree. Your problems are never how to reverse a linked list, or finding the missing number. It's always tradeoffs: why does the business benefit from this technical decision over that one? What's the point of this language? What do you need in terms of hardware? How do you organise the code to suit the needs?

The interview that's always worked for me in hiring is where we talk about the issue and we see if the person understands the problem. There's an infinite number of things we can get into, and if the person is experienced they'll never run out of things to say. I've never hired someone who turned out not to know the basic things like some particular algorithm.

I suppose if we're talking the leetcode style interview loops, they normally have a system design part. That might be the closest to what I do.

I once would've completely agreed with your point idea. But since then, I've had multiple experiences of talking with someone who made a great impression, super knowledgeable, but couldn't actually write any code in a real-world setting.

This approach simply doesn't always work. Some people are amazing-sounding but terrible in practice. The reverse is also true - some people are terrible at talking about their work, but produce amazing code. (Their lack of communication skills might or might not hamper their actual job performance, depending on multiple factors.)

I agree that the interview can't be just war stories. There has to be code in there somewhere, like whiteboard sketches of an algorithm the candidate has implemented.

On the other hand, leet code questions definitely don't show that the candidate can actually write maintainable, well-documented code with test suites and easy-to-use APIs.

Yes, luckily those aren't the only two options :)

Though I will say that having some kind of fizz-buzz style phone screen is still, in my mind, a good idea. It saves a lot of time if it turns out that your candidate can't even write a simple for loop (and so many can't, to my great dismay).

"We need to serve 1TB of data. How would you do it?"

Start there. Let the candidate walk through the problem. Ask questions, and introduce hypothetical limitations. "We need to display the data in a table on a webpage." (frontend) ... "We need an API that can query the data." (backend) ... "We need to sort the data." (discuss algos) It's not that hard to find people's strengths, and make sure you're hiring qualified folks.

And, maybe, c) not many people have both strong verbal skills and strong technical skills?

Reply on news.ycombinator.com