Criteria used to filter out top candidates for large companies is terrible, and only perpetuates mediocrity. Here’s a list of things to do and, more importantly, to avoid to fix that.
Over the past year, I took part in two technical interviews for a large corporation. The first was of genuine interest, the latter was to humor them. I suppose its uncouth to point a finger, but let’s say, this corporation sells everything from A to Z.
Do spend the first ten minutes explaining what your team does
Do not rest on your laurels because you are a large corporation. I refuse to work for anyone who doesn’t have interesting problems to solve. I would be incredibly bored. I cannot spend my days working on word processing software where there are teams out there pushing the limits of Artificial Intelligence, Computational Semiotics, and squeezing every bit of performance imaginable.
Explaining your mission and problem domain gives me a chance to evaluate, and gives you the opportunity to share your passion with me (and hope its contagious). Not to mention its a fabulous way to break the ice of an interview. We could jump straight to the pop quiz or we can discuss things that matter.
Do not give me programming competition problems to solve
For the uninitiated, programming competitions feature teams of college students who are given 7 or 8 problems to solve. These teams have 5 to 7 hours to answer as many as they can without outside help. Luckily, they can prioritize which problems to solve first. World champion teams usually solve 5 of the 8 problems in that time frame.
These problems are often stereotyped and dull. For example, an ‘easy’ problem might be to convert a string of Roman Numerals into an integer. The average team might solve this somewhere between 10 minutes to a half hour.
The problem using these questions is that they don't correlate to what your company is doing. By answering these problems, I have only demonstrated that I understand the trick. This is why the best interviewees aren’t the best engineers. They are the best at spewing verbatim answers.
Do not ignore the realities of how engineers solve problems
Quick: What’s the time complexity of radix sort? Is it stable? If you’re able to answer these, fantastic; if not, you’d be a reasonable person and click on the Wikipedia page.
The ability to know that others have had the same problem as you is crucial. If you asked me to create a function which counts with letters (A, B, C..AA, AB…ZZ), my first thought would be: this is not a unique problem.
First stop, Stack Overflow. First Result: Incrementing characters past ‘Z’ in Java like a Spreadsheet.
Not only is it the correct answer, it’s more efficient than I would have come up with naively. Great engineers are lazy. They will focus their talents and time on difficult and interesting problems.
Interviewers must know the difference between interesting and clever. Interesting problems require copious explanation and diagrams. They involve custom data structures with odd behavior. A good interview question might explain that a database is being accessed too often and ask for potential remedies. You know, questions with real thought.
Do restrict interviews to at most one phone and one in-person interview
I’ve talked about how phone interviews are evil, but I recognize they are a reality. However, if your interview process involves more than one in-person interviewer, take a serious look at your process. Both your time and my time are valuable. If your process involves multiple team members signing off, ask yourself, why have an lead interviewer at all? If I have to knock door to door to get everyone’s approval, I’m not interested.
As a rule of thumb, for every person on your staff for which I have an interview, there’s an equal number of pending offers on the table. Five interviewers? You’ll have to present an offer that bests five others.
Do not interview in groups
What sadist thought of this? Again, if I’m not valued enough to have your undivided attention, I’d rather not bother. Despite what XP methodologies preach, programming is solitary and esoteric. Your team might happen to be in a group, but rest assured, they’re programming in a group alone.
The stereotypical engineer is not an extrovert. The handful that could thrive in that situation will only go on to perpetuate that group interviews are normal. And for Pete’s sake, we know that engineering firms want to avoid echo chambers. The diversity of backgrounds is what keeps your firm moving.
And finally…
Do treat engineers as the precious commodity they are
The demand for engineers climbs forth and there simply are not enough to fill the slots. You’re in fierce competition with hundreds of other corporations and start-ups. If this were real estate, its a seller’s market. You want my talent, I know you’ll find ways to ensure you have the best process around. If not, you’ll either be stuck with nontraditional fixer-uppers or the mediocre.
You need the best talent to thrive, to appease your customers, and to pounce on your competition. Take some of these recommendations to heart, and you’ll be on your way
(As an aside before my coworkers read this, the entire process this past year has made me so glad I work where I do)
