I've been on both sides of the interviewing table a number of times. Currently I'm on the less stressful side, that of trying to find a good candidate. So how do you find a good candidate?
Joel on Software has two criteria: Smart, and Gets Things Done. His Guerrilla Guide to Interviewing does a good job of explaining what he means, so I won't repeat it. The question is, how do you determine if someone is smart and/or gets things done?
The Google/Facebook style of interviewing where you have to solve problems on a whiteboard answers the "smart", at least for a certain type of smart, and assuming that you don't freeze up under the pressure of interviews. But what about "gets things done"? The ability to solve problems doesn't mean that you will work diligently. So the best way I know to determine that is to investigate your track record. An internship or trial hire period would be better, but since that isn't typically an option, it instead means trying to figure out from someone's resume and their answers to questions about it. This is very much, an inexact science.
What about smart? Different positions require different degrees of intelligence. As my boss reminded my, the work that we currently do doesn't require super genius intelligence. However, I maintain that no matter how mundane the job is, it is better to have higher caliber employees doing them. Do you really want to be maintaining the software of someone who is just barely qualified to do the job? Are you really going to go to that person for help when an issue arises? How are you going to learn and improve while working with someone who just wants to get by?
Therefore, while I am not looking for super-geniuses, I do want someone who is more than just barely competent. So how do I personally test for that?
Based on Joel's article we now make candidates write some programs on the whiteboard. We are hiring a programming position. If you want the job you should be capable of turning thoughts and ideas into code. I realize that between modern IDEs and the internet, modern day programmers have access to unprecedented levels of help. However, you shouldn't be dependent on that help. If you don't know the difference between AND and OR without looking it up, or you don't know any collection types other than an ArrayList, how can I be confident that you will write quality maintainable code?
How about theoretical knowledge from a CS program? How important is that? I realize how much importance you put on that will depend on your own skills and experiences. While it may not be important to actually know that the time complexity of a bubble sort in O(n2), at some point you will run into code that is running unacceptably slow. If you don't show any knowledge of time complexity, what evidence do I have that you will actually pick out the bottlenecks of a slow program and know how to fix them? (or even better, how to avoid them in the first place?)
Unfortunately for me, every example above came from recent interviews I've done. Am I wrong to think that a Java developer should be familiar with more than just ArrayList from the java.util Collection classes? Is it random trivia to remember the time complexity of bubble sort? I think these are examples of things people who care about the craft of software development should know, but maybe I am biased by my own experiences?
What do you think?
2 comments:
I had a similar problem when interviewing for the position that "Tiberious" eventually filled. After several interviews, I was done 15min in (if you can't hit the slow pitch questions out of the park, there is no point in going on to the interesting questions). I started second guessing my expectations.
In interviews, I try to open with the academic expression ("When would you use a correlated subquery?") and then if that doesn't float follow up a bit later with an opportunity to show practical understanding ("How would you Select the top 5 highest paid officers per organization?"). Ok, so someone may not know what a correlated subquery is by name, but may know perfectly well how to use one (or have an equally valid solution to the question posed later).
I'm just now coming back into the land of programming. Truth be told, I didn't have a complete image of bubble sort in my head (had most of it, it turns out), but a quick look at the code showed it to be O(n^2). I'm also not currently interviewing as a developer right now. Many things can be done with a hammer. Many of those things can be done better with more appropriate tools. Algorithmic complexity may seem academic, but understanding that different methods are appropriate at different scales and knowing how to recognize and plan for these cases is important. The short answer is that I think you are asking the right questions, but sometimes it takes a while for a good candidate to come along.
It is always disheartening to walk away from a bad interview. As you point out you do yourself, your company, and ultimately the applicant, a disservice if you hire someone unfit for the job. Eventually "Tiberious" came along; the "easy" questions were easily answered, the "moderately" hard questions were answered, and then we got down to a quality discussion of approaches to different problems and war stories that let me know that this was a guy I wanted on my team.
Sorry for the long post.
First off, don't apologize for the long comment. My primary goal in creating this blog was to get comments like these, so thank you.
I do think one challenge of interviewing is to not ask for specific facts (What is bubble sort? or What is a correlated subquery?) because people may not remember terminology. Instead find out if they can solve the problem or analyze the algorithm, as you said.
In my specific example, the candidate who was a recent grad mentioned that their favorite CS class was Algorithms and they mentioned Bubble Sort as something that was covered in it. I feel that if you bring something up in an interview, it is fair game to ask you about it.
I just hope we can find our Tiberious candidate. Do you know anyone?
Post a Comment