Hiring Managers: Ask Better Interview Questions
We are in the tightest candidate market in recent memory and hiring managers continue to squander hiring opportunities by asking irrelevant and impracticable interview questions. Ultimately this allows the candidate with multiple opportunities, a reason to focus on more engaging interview processes. Don’t get me wrong, there is not a candidate in the market that misunderstands the purpose or thought behind the Google interview. In fact, most candidates agree for the type of company and culture Google promotes, this hiring method is quite effective. The consensus is that asking candidates why manhole covers are round, or how to fit a giraffe in a refrigerator, will result in a room filled with insanely smart researches that consistently find theories worth proving wrong and/or right. Many of these will fizzle out via extensive R&D, prototype and test. While fewer and far between, will actually make it to market. Furthermore, the flaw is that there is only one Google yet a majority of the companies hiring try this approach first before finding frustration and alternative interview methods.
Yes there is value to knowing Linked List by definition and off the top of your head, but at the end of the day implementations such as this are often times saved on a Safari bookshelf or one key stroke away from copy and paste.
Why is this important you ask? Because with an already depleted candidate market to begin with, it is ever more important to keep candidates engaged in the process and becoming a part of the solution. And if you are part of a business that has clearly defined goals and trajectory then hiring someone who can help stay on track and accomplish said goals is more important than patenting the world’s longest algorithm.
Keep things simple, get the candidate engaged:
- Here is a problem we’re trying to solve currently. How would you go about tackling this problem?
- Here is a problem we just solved. At first we tried it this way but it was a fail. Do you know why?
- We have an X-week release cycle. What is your current development release cycle and how would you adjust coding habits to our current cycle?
- In the near future we are thinking about this new feature. If you had a say in the choice of technology what would you choose and why?
- I know you are an engineer, but if I asked you to QA this application where would you start? What order would you proceed?
- If three senior managers approached you in the same day with problems called “urgent” how would you prioritize
This approach will allow you subjectively analyze the answer content while identifying whether or not this candidate will bring fresh and new perspective and experience to the team. In summary, the idea behind interviewing is getting a feel for how someone solves problems and uses the resources available. In this tight market, you may want the guy who nails the “google interview”, but guess what: Google wants that person to ;)




Erin Wilson
Reader Comments (2)
Merry Christmas 2011! still looking to buy Christmas presents? Shop Christmas gifts online at low prices here:
columbia sportswear
columbia jackets
columbia clothing
columbia sportswear
columbia jackets
columbia clothing
columbia sportswear
columbia jackets
columbia clohting
One of the problems I have with the Google way of interviewing using "oddball" questions is that it's completely disconnected from the type of work the role calls for. Sure, if you're hiring into a position that involves R&D and breaking new ground, then those questions are quite appropriate. However, even if you're Google, if you're hiring for a developer on a team that's doing the back-end system that manages ad inventory, you want someone who can write maintainable code. In that case, the oddball questions are not going to help you determine how good their coding skills are. Having them actually write code, on a computer, using a familiar IDE, is the closest you can get. Ideally, you would do this for a full day, but that can be exhausting. However, I've found (after interviewing many hundreds of candidates) that you can usually tell how good they are after 2-3 hours of pair programming with them.
You want creative problem solvers, but you want them to be able to solve problems in the domain that you're working in. That's why I think the questions you propose are right on target.
;ted