Redgate had a discussion recently among our developers about our interview process and questions. There has been a standard question asking candidates about 2D arrays, but as one developer pointed out, we don’t use these in our code base. So, why do we ask candidates about this topic?
The developers came up with a different question, actually a series of questions that ask about a class and then how to test parts of this class. We mostly work in C# in a DevOps culture, so this seemed like a good idea. They proposed a scenario with a few questions and then asked current developers to solve the questions and give feedback on the language, structure, and difficulty of the problem.
I followed the technical discussion lightly, as I am not concerned about how effective this particular question might be. I was more interested in why people felt this series of questions would give them insight into how a candidate thinks and devises solutions. This isn’t a test so much as a chance to decide if a person can fit into a team and accomplish work. We tend to work in teams, so while the ability to write code is important, it is more important to collaborate, share, and learn from others.
In the end, I hope that the interviewers don’t view this as a pass-fail, but rather as a spectrum that represents the opportunities a candidate would provide to build better products. Does the candidate ask questions, do they see the upsides and downsides of potential solutions. and do they view the challenge as a way to learn and get better? If they misread the problem or make a mistake, do they admit it? Do they realize that they went too fast or were too nervous here? I have seen plenty of candidates make syntactical errors in coding because they are nervous in an interview.
In school, mistakes often result in poor marks. An incorrect answer and lower grade are the results of simple mistakes. In the real world, we are not as often evaluated in black and white terms. We use peer review, unit tests, and code analysis to catch simple mistakes. We grow and learn from these errors and improve over time. At least, that’s what I would hope most developers, as well as Operations staff, should do. A logic error in a WHERE clause or an incorrect partition for an OVER() aggregate might cause some issues, but we don’t fire employees for making these mistakes. Why would we disqualify a candidate for doing so in a pressure-packed, short interview?
I used to give questions as a test, but over time I started to use them as a way to gain insight into how an individual fits in a team. I’ve added poorly phrased and incorrect questions to see if someone catches my error. I’ve asked about impossible situations or problems my team hasn’t been able to solve, just to see how people react. I’ve learned to appreciate the Kobayashi Maru-type scenarios that test someone’s ability to cope with difficulties.
I saw a question from Amazon’s interview process (allegedly) recently that asked about solving a hanging cable problem. I’ve seen some of the “How do you move Mt Fuji” questions that Microsoft used to ask. I can appreciate the challenge of asking highly technical people to think algorithmic-ally about how to accomplish a task. I just don’t know if those types of questions help us build better teams.
What types of questions do you think help decide if a developer, or a DBA, would be competent in your environment? Are there any crazy ones that you felt stressed you, were extremely difficult, or maybe didn’t help you pick a good candidate? Or maybe you have thoughts on what might better help you decide to choose one candidate over another. Let us know what you think today.
Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.
We used to do “tech” questions, but I’ve since become much more interested in seeing how people think and approach various problems. Knowing the tech details are great, but know how to _apply_ those details is more important. Sometimes knowing where to look for help or answers and then knowing what to do with those is key. But along the way, we do some digging. If you say you are an expert in perf tuning, I’ll ask about that. If you say you know Always On, that’s fair game. I’m more interested in what a candidate knows and doesn’t know than if they can recite specs. Knowing what to look for is important over the exact syntax for a rarely-used DBCC command. Asking what they did last time they brought down a production system is usually interesting. I’ve added in a question about mitigating a ransomware attack – partly because most DBAs just haven’t thought about that much and it’s a big deal if something gets through.
Pingback: Thoughts on Technical Interview Questions – Curated SQL