Ask HN: Alternatives to algorithms/data structures for software interviews?

In general it's very difficult to interview in a way that would give insight into previous work experiences at a practical level. Every interviewee will have their own unique experiences and even though they may all have similar backgrounds, designing an interview question that would be general enough to gain insight into all of their experiences is nearly impossible. I've interviewed at places that attempt this and I've never felt that it worked out the way they were intending it too. They usually become too specific to the ideas/experiences of the person who designs the question.

I think algorithm and data structure problems can be useful if used correctly. I think the main issue is that most companies tend to use leetcode style problems which are a bit more on the brain-teaser side and are often usually harder to solve if you haven't spent a significant amount of time solving such problems. These questions might make sense for super competitive positions at places like Google where they can afford to reject good candidates, but at most companies it doesn't make sense. I think simple problems that involve working with the same data types required at the job would suffice. The purpose of the question should be to screen out candidates who can't solve them, not to judge how good they are.

The problem is scaling a process, the number of people who can catch bullshitters during an interview are not enough to scale up a conversational interview. Most tries to solve "How would I interview someone?", instead they should ask themselves "How would an engineer with mediocre social skills interview someone?", because that is what you'll get when you scale up.

So, conversational interviews are out, no way someone with mediocre social skills will catch a bullshitter.

Take-home problems work as a screening tool, but has the problem that you don't know if they wrote it or if they spent an extraordinary amount of time on it. You need to evaluate this on-site somehow. Many here say "Just have a conversational interview about it and we'll catch the bullshitters!", would you expect a mediocre interviewer to catch those? So no, doesn't work.

That leaves on-sites. We have 3 on-site interview styles which are known to work, each with their own problems:

1. Technical coding interviews where you solve an algorithm problem. Even the most junior interviewer can use this style and requires basically no training. Lots of experienced engineers feels this is unfair since it experience doesn't help candidates much.

2. Technical design interviews where you are given a high level problem and discuss how you would architect the solution. Note that this requires significant technical skills and experience from the interviewer so only senior engineers can administer it, so you can't be too liberal with them.

3. Structured behavioral interviews, ask a series of "Tell me about a time when you disagreed with a coworker, how did you resolve the issue?". This style is extremely popular in non-tech fields, so there is pressure that we get more of them in tech as well. Popular in Amazon, "Leadership principles".

Now, it is not like Google could substitute more coding interviews for design interviews, they don't have enough people who are qualified to administer design interviews. Also I am not sure if people would be happy if Google did mostly structured behavioral interviews. I know they recently changed 1 technical interview to a behavioral interview, but I am not sure this makes anyone happy since you still have 3-4 coding interviews.

Our process is, first, a phone conversation, maybe a half hour. Then the interview is two hours.

The first half hour is just talking to them about their background and stuff. Then we give them some code to read, to see if they can figure out what it does. Then we have them write a bit of code (nothing leetcode-style, just a simple function). Then we have them do a bit of design.

Since we do the same to everyone, we are by now fairly calibrated as to what a good candidate looks like.

This my problem...spend months working on these kinds of problems, finally get a job, get rusty because I'm doing totally different stuff at work. Find myself needing a job again...study and grind for months just to have a chance at passing interviews. It's all so tiresome.

I had a particularly interesting on site interview where part of it involved fixing a bug in a previous version of a well known open source framework. They gave us the relevant tests to run which showed us what was failing on which inputs. We were welcome to use our personal laptops/coding environment to debug and fix the bug. I personally thought it was a good way to demonstrate the ability to actually navigate a larger codebase, understand what tests were doing, and to follow program logic through a large project and ask pertinent questions. Granted this was for new grad interviews, but it did seem a lot more relevant to day to day work than leetcode problem #X.

Hire people with masters degrees