My group is looking for a person who would be a good lead developer for the GUI portion of one of the Calibre tools. So, obviously a NUB probably wouldn't qualify. But to be honest, the recent grads probably know more than the two ... um ... candidates (biting my tongue here) I've had the ... joy of interviewing.
The first was someone already working for Mentor. He'd been there for 7 years. Turns out he had a masters - of mechanical engineering (I didn't notice the area of study until after the interview). I lined up my standard line of questions, the first couple of which I'm embarrassed to even ask. Because the the first set of questions are embarrassing, I begin by saying something to the effect that I always ask these questions and if they seem too simple, we'll blow right through them, it's not to be taken as an indication of my first impression of the candidate.
Here's essentially what I ask:
- Name some basic data structures. What are the trade-offs of using one over the other?
- Define the following C++ terms:
- inheritance
- virtual functions
- static functions/data
- abstract base class
- pure virtual function
- operator overloading
- templates
- polymorphism
- inheritance
- When do you use templates and when should you use inheritance?
- First programming question, complete the following:
int string_to_int(char *str) {
/* convert string representing a number into an integer */
}
Restrictions come in as appropriate: (can't use atoi, strlen, exp, use only O(n) multiplications. - You are given a long line and are told to cut it up into pieces.
The restrictions are:
.) No piece can be shorter than some MIN length
.) No piece can be longer than MAX length
.) Every cut must be on a unit boundary
.) There are locations that cannot be cut, presume the function can_cut(x) tells you whether or not you can cut at a location x
Describe how you would do this.
Can it be done in linear time/space? - A design question from my brother: design a messaging system to handle arbitrary messages of a variety of types, with listeners and senders who may be geographically diverse.
- And lastly, because we had a little time:
Write a function `samepattern' that takes two string arguments,
and returns true iff the strings have the same pattern. Two strings
have the same pattern if when elements are equal in the first string,
the corresponding elements in the second string are equal, and vice
versa.
Well, the first guy barely answered the data structures questions - which is a bad sign. He did marginally better with the C++ questions, and then we hit the first programming question. He had a horribly difficult time realizing that 123 is 1*10^2 + 2*10^1 + 3*10^0, and finally, after I provided that information he had a tough time figuring out the solution (we never went through refinements, I needed a break). The rail-cutter problem simply baffled him - he had no idea where to start when his algorithm reached a point where he couldn't make a cut. The design question was abysmal, I got a couple of class names out of him, but I had to hold his hand to get each one. I forget how I ended things, but I tried to keep a smile on my face.
The second guy I interviewed did better. He got a little flustered with an impromptu virtual function question I wrote, but it was obscure. He had written string_to_int sometime in his long history (he'd graduated college before I was born), so he nailed that. At that point I noticed he didn't write anything down - no big deal as he nailed the question. We moved on to the rail cutter question and he had some trouble. His code (once I got him to write things down) was horribly ugly and showed he had no idea how to actually return the results. Furthermore, he had NO confidence his program would work, and simply guessed at the runtime. The design question was like pulling teeth, he didn't seem to like talking about design, nor did he seem to think about the scaling implications of a large system. Then, with the few remaining minutes I thought I'd throw him a softball, the 'samepattern' function, so we could end on a high note. He stared at the problem (only responding by saying he understood it) for 8 minutes before giving up.
The first guy just bombed, the only feedback for him would be to go back and study your CS101 and other introductory courses. He, at least, was eager and energetic and put forth a great effort.
The second guy, well, he's been around long enough to know better.
First, be confident about what you're doing, and if you're not, have an idea where the problems might be. He literally told me he didn't think his solution would find all the test cases. Ok, that's honest, but it tells me he really didn't understand the problem he told me he did, nor can he recognize the exhaustive search he just wrote (which did cover all cases).
He then said it'd run in polynomial time, which covers most everything. I asked him to refine that, b/c that covers everything from linear to N^100000 and beyond. He had no idea, letting me know he'd just guessed. His solution ran in exponential time, much worse than polynomial.
Third, write stuff down. It's fine to talk, I encourage people to talk, talking is good because it lets me know your thought process. But if the interviewer passes you a piece of paper and a pen and asks you to "write a solution" then you'd better do that. Hand-waving only gets you so far and I, as an interviewer, am going to ask specific questions to get through your hand-waving.
Lastly, never simply give up on a problem. Try talking through it, brainstorm, do something. Staring at a problem for 8 minutes w/out saying anything is a sure way to lose the interview. Especially when the problem was literally taken out of an introductory CS course.
Lastly, at the beginning of the interviews I ask candidates how they think they rate on a scale of 1 to 10 (clueless to expert) for each of their programming languages. People seem to respond 7 or 8, regardless of their actual background. For C++, I find it very interesting that someone would answer that high of a number when they either don't use STL, or have only used STL. Now a scale is rather arbitrary (and the geeks who're reading this far are thinking, "well, is is the scale linear, logarithmic, what?"), but still. If you've never done template programming, nor can you explain *why* you'd want to do template programming, you're likely not an 7, surely not an 8. And if you stumble horribly on a virtual function question, you don't rate above a 6.
Ironically I think I'm a 7 or 8. At least I can answer all my questions.
