When discussing how to interview for software jobs, lively discussions ensue, with almost every answer being disliked by someone or other. Despite knowing that there are certainly critiques that can be thrown at anyone’s process, I wanted to share the types of questions I ask, and why – both when interviewing a candidate, as well as what I ask when I am the candidate.
When I Am Hiring
Philosophically, I agree that ‘leetcode’ questions aren’t ideal. I don’t feel they are useless, but I believe they should be a quick, easy proof that your candidate has the basics down, and then you should move on to more useful questions.
I try to devise new questions for each round of hiring. I ask all candidates the same question, so I have an accurate comparison of their answers. My questions have a few common traits:
The answer should be open-ended. I want to see how they solve problems, and how they approach their work. I don’t want them to have to reach the “right” answer, or prove to me that they memorized an algorithm that they could just look up if they ever need it.
The question should have enough flexibility to let the candidate choose their own approach, and focus on areas in which they are strong. It should be vague enough to let them make assumptions or ask questions to refine the problem. It should be complex enough to make them think through multiple approaches, but simple enough that you still can talk through it in 15 minutes.
In short, you want to give them enough rope to either let their talents shine, or to shoot themselves in the foot, all depending on their own skills.
I’ll give two examples that I remember:
SharePoint Admin Question (2009-ish)
In the late 00s, we were hiring a SharePoint Architect to lead the internal team supporting SharePoint for an Enterprise IT shop.
My question was: When an end user, external to the company, submits a search form on a sharepoint-driven public web site, tell me what happens.
The answers ranged from as simple as: “Sharepoint would do the search and return results”, to complex answers getting into the DNS lookups, TCP/IP routing, firewalls, and then down into the SharePoint internals.
The answer given by the guy who got the job showed that he already thought at the level we wanted for the position. He asked how our server farm was configured. He asked how load balancers were configured. And he asked if we should just dispense with the details of the external networking, instead starting with the front-end server, and explaining what each server in the farm did, in what order they would perform operations, and how the result would be sent back out over the external network.
His answer showed me that he knew his stuff, he knew which pieces could be put aside because it would be someone’s else’s responsibility, and he asked for more information to be sure to give an accurate answer instead of making up a simple solution.
Full Stack Dev Question (2017)
For the devs, I asked them to devise a way to display a bracket of game results, akin to the college basketball championships. I told them that they can design the data however they like, in whatever format and structure they believe would be most helpful, and to tell me what that data would be, and how they would write front-end code to render the bracket on-screen.
Answers varied greatly. I had some people who spent the whole time asking me what the data looked like. Others jumped right into the front-end, talking about how to place the results on-screen. Most people asked clarifying questions, with the most common being whether they were showing the end results, or if they had to show progress as the games were played. (My answer was to be able to show a snapshot of how it looked at any given timestamp.) Some people did not get very far. Most people would get 80% of a solution figured out in the 15 minutes we had. There was a large pack of people who did “OK.”, with 2-3 who gave answers good enough that I was in favor of hiring them.
The guy who got the job asked a few clarifying questions, then breezed through it like I was asking him to code FizzBuzz, with terrific answers. I kept pushing him to see how far he could take it, especially on the front-end. That was a failing of mine – I should have just said, “Yeah, great, lets move on.” I annoyed him. But he took the job, and is doing great there.
When I am the Candidate
When I am looking for a job, I’m trying to determine whether I’d be happy at the company, doing the work they want me to do, on a team I can work with, for a boss who is a solid leader.
To figure that out, I almost always ask the following questions:
What is your leadership style? There are a few wrong answers here: “What do you mean?”, “Authoritarian”, “I micro-manage”. But anything other than those 3 is often good enough. I want a boss who thinks enough about team leadership that the question isn’t new to him, who gives his people autonomy, and who respects his people.
How does the team resolve conflict? What I want to hear from this question is that they acknowledge that conflict does exist, and try to build consensus between team members.
What is the Long-term goal of the company? Are they trying to build a smaller, comfortable business where people stay for years? Or is this a high-growth company trying to build up to take over their market and/or get acquired? Or do they have something else in mind? I want to be sure I’m not walking into a place that is going to burn people out while seeking the mythical “exit”. Most other answers are fine for me, but “Join us and we’ll exit and all retire young” tells me we aren’t on the same page. Not that there is anything wrong with that goal if that is your desire, it just isn’t me.
What are the current struggles on the team, and where they are headed to correct the problems? I don’t necessarily care what the problems are, unless it throws me a red flag that the leadership isn’t skilled, but I want to know that they have a solid self-awareness of where they need to improve, and are planning actions to improve the team.
What is the team doing great on? I ask this question less to decide on whether or not I want to be there, but more to end on a positive note. This question does so, while also building a natural hand-off back to the interviewer to finish doing their job of selling me on the company, so we can wrap up the interview.