In my acting days, one of my favorite sayings was "fake it till you make it." The idea is, you're on stage, you're not connecting with the character, don't just become emotionally unresponsive, relax, go through the motions until you get into the groove.
Hiring is similar. There is an arms race with technical interviews -- as candidates become better prepared, the questions become more asinine. Why? Risk management. No one wants to hire a liability and it is hard to figure out how good a coder is based on a short (8 hours) interview.
There are two major approaches -- the CS approach (used by GS most of anyone) is to ask a bunch of questions that you would get as an undergrad -- brain teasers, reversing linked lists, sort algos, reverse a string, etc. The idea here is, if you are smart, you will be able to pick up any language. Coding language is a tool, the programmer is the artist, he can work with any tool, a la Pablo Picasso.
The other line of thought is, we need serious depth in understanding a language -- the Morgan Stanley/Bloomberg approach. Being smart is great, but if you are really smart, then you will understanding threading, the garbage collector, the stack, the heap, the vtable, etc. If you don't have the depth of knowledge, we're not here to train you.
I always supply my candidates with a 4 page list of questions to expect. I don't care if they've done much threading or know the garbage collector or have worked with 30 STL containers. I want to know if they can learn enough, fast enough, to pass the interview. Listen, if they are not smart, then they will never be able to pass. But if they are smart, they can learn something and be able to pass -- that's what I think clients are really looking for.
It's always funny when I speak to people -- they'll have done a couple of interviews, been embarrassed they didn't know something trivial. The smart people take it as a challenge, study my questions, and get to really know the language they have been working with. Firms hire more people, my people need less interviews, and they feel like they've learned something. Makes you wonder why nobody else is doing it.
Subscribe to:
Post Comments (Atom)
1 comment:
The two lines of thought definitely exist and they are cleary apparent to candidates when they interview. I like the first approach better since good developers are good in any language.
The second approach is fine also, as long as general computer science answers to the questions are accepted. I don't think I should be required to memorize the Java API when I can just look that up and have the answer in 15 secs.
Another style of interviewing is "what's a problem with this or that technology ?". This kind of question is difficult to answer. The interviewer will generally not let you go until they got exactly the answer they wanted. I have a hard time answering these kinds of questions although I feel like I have a good understanding of the technologies / systems that are being discussed.
Interviewing is exhausting, but sometimes you'll get a break because every interview will start with "can you explain what virtual means in C++". You can just use your best canned line there ;)
Post a Comment