How to Improve Software Engineer Interviews (for non-juniors)

This is a follow up from my previous article: https://d-hanshew.medium.com/how-to-improve-software-engineer-interviews-for-juniors-8e3730dc99a9

I’ll cut more to the chase, but here’s how we as engineers can improve interviewing for our field without gimmicky LeetCode problems.

Reference: https://pixabay.com/illustrations/interview-job-icon-job-interview-1018333/

Homework Question

A small homework question will show a lot about a developer and how they approach the problem.

The simplest homework assignment that can show a lot about how a developer organizes and writes code. I prefer a simple homework assignment that relates to a small part of the role in a way.

For example, have a homework assignment take in a CSV file transform the data and output a CSV with the new data. The data should have a unique value attached to it and derive values from what is available as well.

Another example, is to build a simple API service with a in-memory database. The service could be simple as a laptop checkout service with simple CRUD operations.

This essentially gives a peek into how a developer approaches each of these services. The prompt is intentionally vague as to allow for creativity and see what is emphasized. You can look for the following:

• Does it have tests? Unit? Integration?
• Does the service handle errors?
• How much did they automate when running items in this project?
• Did they add a Dockerfile to run outside of a local environment?
• Did they add documentation?

All this can be simply found in a short homework assignment. The only downside is that this type of problem could sway off candidates that don’t want to spend extra time on a assignment. Unfortunately, these are time consuming as well to grade and review, but it shits on the idea of asking dumb LeetCode questions.

Final point, during the interview several questions can come up about turning the service into a production grade system. This will allow the interviewee to explain themselves and where they think the project should head in the future.

Design Question

Instead of doing a general design question about classes, inheritance, and relationships, give the interviewee a bad design and see if they can recognize it’s a bad design and how to improve it.

For example a simple kitchen, but the toaster class inherits sink and overrides method for implementation.

You could see what a mess you could make, but this is good to see if they can see recognize bad designs and prompt solutions.

Conclusion

Overall I doubt the classic FAANG type companies can do this, but smaller companies should strongly consider interviewing practices that make sense, not hoops to jump through.