If you're looking to grow through the ranks in your career as a software engineer, you're only going to take on more responsibility over time. One consistent thing that happens for everyone is that you start to interview other software engineers.

This can be daunting at first, and then easier over time as you gain skills in the area. You might even find yourself in the position where you are helping other new interviewers learn how to interview people.

Over time you will look for tips and tricks on how you can give people a great interview experience. That's why I've put a few tips together and am sharing a challenge that I have been using in my interviews lately.

Interviewer Tips

I've run a fair few interviews now and these are my general interviewer principles.

• Don't Be a Dick - Treat people with compassion and kindness, it's hard to put yourself out there.
• Listen to the interviewee - Don't judge on buzzwords, hear what they have to say, even if it's not what you're expecting.
• Be Ready to Pivot - Following the same interview structure for everyone doesn't work because no two people are the same.

The Challenge

One way I've tried to be creative with the interview process lately is by developing an exercise that I can run with any Software Engineer on any level. It's a simple structure but it's open to creativity and change, it's helped me feel like I understand the person on the other side of the table/camera better than when using just direct questions.

It starts with a simple premise and then I ask a progressive set of questions. At the end of the interview, I will have discussed a different set of technologies and approaches with each person. I ask the same six questions each time but dive in different directions for a few deeper questions based on their answers.

Two notes about this process

1. I'm not expecting the same thing from a junior as I am from a senior. When I use this approach, I attempt to draw what knowledge the person being interviewed has in each area, but I'm looking to understand what they have learned through their experience.
2. Let the person being interviewed know that you might take some notes for follow-up questions. It can be off-putting if the interviewer is always looking away and you aren't sure what they're doing.

Getting Started

It starts with a greenfield project. Make it a website, an app, whatever you choose. Make it a store, make it a service, and keep it open to keep the interviews different, but keep it simple and similar to keep your interviews fair. All I say is we want data storage, a backend and a frontend involved. That's where the fun begins.

What's your dream stack for this system?

Start with what technology they know or desire to learn. Let them know that they can choose anything, no wrong answer. Some people choose tech because it solves a specific problem, others because of what they know, and some because they want to learn it. Some people want to talk about infrastructure too, let them. There's more room for that later but no harm bringing it up early. All I'm looking for here is reasoning, why are you choosing that stack? Tells you a lot about how people think.

Now that you have some features, how do you validate that it works?

This question is all about testing. There's a fair amount you can learn about an engineer and team fit in knowing their attitude and approach to testing their code. Automated or manual, and why? What layers of testing might you include, unit, integration and/or E2E? Dig deeper and ask about code coverage, see how they value that metric.

You have more people join your team, how do you all work together on the same codebase?

How does this person work in a team? Do they like Pull Requests? How about Code Reviews? Pair Programming? How are they used to working with others....and source control? You can dig into Agile experience and maturity here too, Stand-ups, Sprint Reviews and more. This is a moment to understand how people value teamwork, and learning from others, and whether they are willing to serve others.

It's time to show your work to project stakeholders and your customers, how do you make your system available?

Now we're onto (insert buzzword here) DevOps and Infrastructure. Experience with and approach to building and releasing software. Do you have build pipelines, when do you run them? What environments make sense to serve all people involved in a project. How do you release the software? What do you host it on or in? AWS, Azure, GCP or something else? These aspects of projects people work on can quite often bring a great deal of frustration. How does this person handle that? How do they express it when telling you about it?

Something is wrong, how can you get more information about what is happening?

Oh boy it's time to problem solve. How does this person approach solving a bug? Who do they talk to? What systems do they use in partnership with their software to help them? Do they use application logging? Where do they store their logs? How do they track their progress on a bug? What proactive steps would they take to stay ahead of future bugs?

There are a lot of questions and avenues to go down here, don't dwell forever but depending on the role, this time could really help you know if you would want to work with this person.

Customer demand is growing, how can you make sure your software is up to the challenge?

Finally, how would this person handle the need to scale their system. How would they approach making sure their system was resilient? Would they rely on cloud native features? Would they configure automated, timed, or manual scaling? Would this consideration change their infrastructure choices? This section is tough because it's hard to do hypothetically. Again, how does this person respond when given a problem?

More Questions

These questions allow you to dig deeper and find more things to talk about. I have no intention of leaving it there at the end of these six. Now I have notes and things I have learned about them to dig a little deeper on and help me make my decision.

What I'm listening and looking for?

I use this process to get a better sense of a person, than asking directly about their experience with a specific technology.

• What they know and have experienced
• How they explain what these to me
• The details they include and leave out
• When I don't understand, how they teach me

Interviewing can be tough, but I've found this challenge and the tips above have allowed me to get people to open up a little and help me understand them. As a person and as a software engineer. I hope it helps you too.

Support

If you like this, checkout my other examples on GitHub and consider supporting me at Buy Me a Coffee.