Software developer job interview questions to ask

I recently got the opportunity to interview some new candidates for a few different development positions, with the freedom to shape the technical part of the interview as I saw fit. I figured that I'd share my experience of what worked, as well as my own thoughts on some of the other approaches, since I'm still a developer that has to experience the other part of the hiring process as well.

Here's a summary, in case you don't feel like reading the whole thing...

LeetCode, code tests and whiteboarding, the flawed standard: I find that being asked to write code that works without an IDE or a compiler and solve problems without being able to look them up is quite unlike my day to day job. Larger companies may still use this approach because they don't necessarily experience a shortage of applicants even if a certain percentage are turned away by this, but that might not be viable for smaller companies. Furthermore, you might end up hiring people who are good at competitive programming, which may or may not be what you should optimize for.

Take home exercises, high risk but high reward: I'd say that one of the better approaches is giving the candidate a problem to solve and letting them do that with their own tooling and approaches to development, which can later be a great basis for discussion or reviewing the code together. The problem here is that not many have time for that sort of thing and it's not always trivial to figure out whether it's actually their project or a friend helped them out bunches with it (albeit the discussion should help). That said, allowing the candidate to offer up one of their public past codebases (if such exist) might be worth looking into, as an idea.

Just having a conversation instead: I've found that just conversing with the candidate is also good enough in many respects. Asking them a few technical questions, but also letting them express themselves, and learning more about them in the process. You might suggest that there are some people who are good at explaining things without quite having a grasp at them, but typically if you ask them to elaborate that becomes pretty clear. Not only that, but this is helpful in figuring out which are their stronger areas and which might need a bit more help from mentors, as well as what they're interested in themselves, you can even recommend some technologies for them to look into!

Doing some design work together: if you'd have even more time on your hands, something like a system design interview might also be nice. Actually, any kind of design work, be it creating an ER diagram of a DB schema for some domain, or a few UI wireframes and talking about the UX, or just drawing up an example architecture for some made up system. Regardless, seeing how people reason in detail is good, especially if the process is collaborative in nature, even with the occasional disagreement to explore conflict resolution.

Writing and/or reviewing some code together: while writing code without tools might be troublesome, sitting down to write or review some code with actual IDEs and other tooling is a far better experience. Actually, if there was a take-home task, in those circumstances refactoring some code or adding a new feature might be quite good, because the candidate will already be familiar with the codebase in question!

I'd say that you don't need to do all of these steps, or ask all of these questions, but when the volume of applicants is relatively low and manageable, having a humane approach to each individual feels like an okay way to go. It's actually good to be at a point where I don't have to scale this up to a 25-100 interviews a week and throw much of this out the window. Then again, other approaches are also good, whatever works for each set of circumstances!