Good Technical Interviews Require Good Technical Interview Questions
We're hiring at Microsoft UDC and interviewing a lot of people. Which is why this recent article on Coding Horror stood out to me, on the surprising fact that many software engineers struggle when it comes to actually writing code.
I haven't actually interviewed any of the people coming in yet, so I'm not really talking about any candidates that we've looked at because I have no experience with them. It was a timely article, though, and I am familiar with the struggle of the interviewer, having done it a lot at Mozy.
It's clear from the article, if you aren't already convinced, that asking interviewees to code as a part of the selection process is an absolute must. I'd also say, as a sidenote, it's also an indication of a serious software company. If you are interviewing with a company who doesn't test your programming skills, wouldn't you wonder how many people are on your team who can't code?
Anyway, coming up with good questions can seem hard, though. Some things to avoid:
- Complex problems that require even good engineers a lot of time to solve. You probably only have about 20 minutes for this question, which probably really only leaves the candidate about five to figure out how to solve the problem, and another fifteen of implementation and discussion. "Implement an ORM framework" is probably too complex or big.
- However, slightly complex problems can be good questions, if you provide enough background to cut the question down to the time you have.
- Domain-specific problems aren't that good at figuring out if someone can generally code. An outstanding C programmer who doesn't know C++ won't know how to implement their own insertion operator, even though they might be awesome and could easily learn it if they needed to. Even a great developer who has spent his whole life optimizing 3D rendering engines for computer games may have never once connected to a database, so he might not know anything about how to write a SQL query.
- Know the problem well enough to determine if any proposed solution will work; don't shut down a candidate just because he solves the problem differently than how you would do it.
The great thing is, apparently even simple problems can be good enough to find out if someone knows how to code. I wouldn't recommend you rely solely on the simplest, but coming up with a decent set of problems isn't too tough if you give it some thought. Here's some suggestions:
- Consider the source of your technical question and how long it took you to solve it. If you dredged it up out of your past experience, it might be a pretty good question because it obviously has some practical application. If you were able to come up with a solution to the problem after thinking about it for just a few minutes, and additionally if one of your colleagues is able to do the same, the problem is not too difficult for an interview question.
- This doesn't mean your candidates will easily get it, however. Don't get discouraged. If people on your team can solve this problem but your candidate cannot, that means the candidate is not of the same caliber as people on your team. That's not a good fit.
- It IS true that some people don’t think as well under pressure as they do on their own, or that your problem might just be in an area that they aren’t familiar with. It’s good to have a set of simpler questions on hand to ask them in case they stumble on the harder one. If they don’t get one of your hard questions but they can solve a simple one, at least you know they can solve SOME coding questions.
- Practice your questions with your colleagues. This will help you with clarifying the context and purpose of your question, make sure you structure it so there's enough time to answer the question, and make sure the question isn't too hard, too easy, or unclear.
- Choose questions that help you evaluate core competencies: algorithm and class design, proper use and understanding of data structures, pointer math, modulus math, understanding of data types, string manipulation, threading and thread safety, etc. Be sure your questions are designed to help you select the kind of people you want.
- For this reason, I don't like to ask really deep language-specific questions anymore (although if a candidate claims to be an expert in a specific language, these are fair game) or API-specific questions. Even if I use C++ and WxWidgets this year, I may not next year. What I want is someone who knows how to program. It doesn't take long at all for a good programmer to learn a new language; probably much less time than it takes to manage a bad programmer out of your team.
What really surprised me when I started interviewing at Mozy was that I'd heard all this stuff before, but had a hard time believing it. That is, until I experienced it firsthand during interviews there. I remember interviewing a candidate who had several years of experience in game development. Game development! These guys are the super-elite of developers, right? So I wondered if asking him to reverse a string might be too easy for him.
It wasn't.
Not a complex string reverse. Not a unicode string. Not in some obscure language he wasn't strong in. Just a basic string reverse in C, with a null-terminated char* argument containing the string to reverse. I even gave him the flexibility to reverse it in-line or to make a copy. I was surprised when he really struggled with this.
He wasn't the only one. String reverse is not a hard function, but I was surprised how many people struggled with it. So don't be surprised if people struggle with questions you think they should be able to answer. The numbers seem incredulous, but apparently it is really hard to find a good developer. So don't give up, my son.
Guest Post: How to Neglect a Product to Death
By: Dan Reese
My friend and former co-worker Matt Ryan recently commented on the impending death of Novell Forge. A message on the Novell Forge site confirms that Novell will be shutting things down soon. I can corroborate some of Matt's story as I was on the Forge team for about a year during its heyday.
But what really interests me about the situation are the implied instructions on how to neglect a successful product into a slow death that can be blamed on the product itself.
- Avoid rewarding or recognizing any of the people involved. Even better, reward someone else.
- Do not feed its success. Withhold funding, staffing and career growth opportunities.
- Provide poor support. Delay fixing problems.
- Set unrealistic goals and expectations. Blame the product or team for failure.
- Find excuses to kill the project. Focus on the negative in all meetings with executives.
This was a particular worry at Mozy when it was acquired by EMC. They promised that EMC did not want to be the lumbering elephant that accidentally squashed its shiny new purchase. And it was true. But we worried about accidental squashing anyway.
It has been two years, and I have seen projects and executives come and go. Though I do not believe it was intentional, at times it felt like Mozy was being neglected. But the core of Mozy has remained strong and continues to grow.
Based on my experience, here is what to do to keep a successful product moving forward:
- Execute anyway. Deliver a quality product in the face of neglect.
There is precious little a neglected production team can do other than produce. I heard something once I have always remembered: nothing succeeds like success. It is much harder to produce in the face of neglect, but it is also nearly impossible to ignore or argue with.
Mozy is clearly not perfect, but despite occasional neglect it continues to provides a valuable, profitable service. Working with smart people helps. Working for smart people helps. Working with people you like helps. Working on something you care about helps. Working with cool technology helps. But over time, delivering a useful, profitable product is what matters.
(This guest post is originally authored by Dan Reese and reprinted by permission. It is subject to the copyright terms at the original location.)
