Ask HN: How to Improve Dev Interviews? | Hacker News Reader

Ask HN: How to Improve Dev Interviews?

3 pointsidlefeature3 comments

I'm a software engineer with 3 years of experience, about help a fellow SE with 7 YOE do some technical interviews to find an SE with ~3-5 YOE.

Neither of us enjoy interviewing and, like most other SEs, we think that the "standard" tech/dev interview process–with its focus on whiteboard-style coding challenges–is a poor predictor of who will make a good SE on the job.

We'd like to find a colleague who's a good cultural fit (not an asshole, takes initiative, admits mistakes, attention to detail, etc.), and who's a competent problem-solver when it comes to backend software development in Java.

So, I'm looking for input, recommendations, etc. on how to make SE interviews better. Questions to ask/avoid? Helpful blogs, books, or podcasts on the topic?

(Yes, I know there's plenty out there on this topic. I'm doing my own research, but also figured I could crowdsource this one to HN and benefit from your collective wisdom!)

An approach that I've seen work reasonably well:

Spend a bit of time just talking to them. Work background, but also just finding out who they are as a person.

Give them some code to read - one page. It should compile - don't ask them to be a compiler. It shouldn't depend on obscure library calls, though it can use well-known ones. The question you're asking them is, what does it do?

Then, give them some code to write. Not a leetcode problem, but something one level above FizzBuzz. Yeah, this is probably at a whiteboard, but it could be at a keyboard in an IDE if they want. They can use any language they want. You want them to think out loud while they're doing it. Can they figure out the steps to implement a solution? Can they write code that isn't too badly broken? Again, you aren't asking them to be a compiler - if they miss a semicolon, that's not a failure.

Then, you ask them to do a bit of design. Just draw some boxes for how they would break up some problem. You're not looking for perfect UML here. Can they design a subsystem, or not?

Then, you ask them if they have any questions for you.

That's it. Two hours max. You might give them a half-hour phone screen before you schedule them for the interview.

Have a calm discussion with them, make it in-depth technical but also talk to them in a friendly manner. No need for take-home tests or leetcodes, and no need to be a robot also. Why can't it be as simple as that?

I think that JUST looking at how well someone solves a whiteboard question is a poor predictor of a success in a job. However, if a person can not solve a reasonably sophisticated problem, it is a good predictor of failure. You can look for signs of initiative, admitting mistakes, bluffing, attention to detail by looking how the person goes through the written screen and interview.

What is a reasonably sophisticated problem varies. It should be something that does not involve "trivia knowledge" of a particular algorithm. Ideally, it should be something that can be solved multiple ways.

It all starts with a written screen. In it I have a small programming exercise. A candidate needs to demonstrate that they know the diff. between the performance characteristics of a LinkedList vs. ArrayList. Both provide a working solution, but only one of these two provides a performant solution. The problems stresses performance. Also, ChatGPT provides the WRONG solution (it works, but not performant) and I can find some tell-tale signs that they used AI to solve it. There is also potential for an off-by-one error.

Im the interview, I start by going through a small gauntlet of super simple exercises (reverse a list, count items, show uniques, print while maintaining insertion order). They are framed as word problems. This show that the person knows the basic data structures available in Java. List, Set, HashSet, LinkedHashSet, TreeSet, HashMap, LinkedHashMap, TreeMap. There's room to show off with trees, dequeues, and stacks for more ambitious folks but the basics suffice.

I have a algo design problem that I use. It scales well from juniors to seniors. It's not exactly a whiteboard problem. I ask the candidate to talk through a solution in pseudocode. My wife was able to solve it when I reframed it in Excel terms even though she is not a programmer. It shows that a person can understand instructions, keep several requirements in their mind at the same time, communicate their thoughts clearly, and ask clarifying questions.

When they come up with a solution, we start talking about how well it performs. I ask questions about how it could be implemented differently to use less memory. We talk about how it could be implemented using SQL, or Java Streams.

Regularly I see people coming up with strangely awkward programming constructs to implement basic parts of the solution. People routinely forget one of the two requirements of the problem. I run into senior programmers who don't think to use a Set to ensure uniqueness. People who don't know that a TreeSet can sort entries. People who know the definitions, but when it comes to applying that knowledge to a word problem, stumble completely.

My interviews are conversations. I start shallow and go deep. I try to see where people's knowledge ends. When they don't know how something works, I ask them how they would implement something themselves.

I turn away people who seem to have the knowledge but can't communicate well. Software development is a team sport. If you can't explain what's in your head clearly in a reasonable amount of time, we will waste a lot of time. If you can't follow a clear explanation of a concept and keep losing important bits along the way, work will be difficult.

If you want to talk I can hop on a call. I am passionate about this. Also, I am currently interviewing mid-level Java Backend Devs, so my thinking is current. Email me - contact info in profile.

Reply on news.ycombinator.com