Hacking the coding interview
restlessprogrammer.com
restlessprogrammer.com
- Decide what you want out of the interview. How do you decide to work for this company? An interview is a two-way street. Engage with the interviewer, connect with the culture. Push back (a little) on their ideas, see what happens.
- I hate puzzles. I think they're junk and have never found them to be good predictors (for either party). I usually (1) parlay it into some relevant experience "I encountered something like that when I..." or (2) describe how I'd solve a problem rather than dig into it [1].
- Demonstrate your common sense, flexibility, good social skills. Talk about how you work in a team. Talk about what you do when you encounter a problem you can't solve yourself. Talk about any self-lead learning you do. You need to fit in and you need the company to demonstrate they want you to help. Even if the interviewers aren't aware of it, more often these form the lasting impression from an interview.
[1] Long, long time ago I was asked to produce a "sort" implementation. So I drew a bubble-sort. When one of the interviewers was somewhat outraged by this, my reply was "I didn't have any constraints, so I optimized for maintainability." A bit cheeky perhaps, but worked in the context.
Hiring a developer shouldn't be as complicated as some companies make it out to be. Maybe for the likes of Google it has to be a lot more complex than others because they have an image and large workforce that depends on people being excellent self-managers and workers that require minimal management.
For smaller companies you are wasting your time and my time asking me questions that test my ability to remember things more-so than they do to search and find answers. Lets face it, most developers these days are hackers. I've never met a developer who knows the answer to everything, I've seen the best of the best using Stackoverflow to find an answer to their question.
The difference between a good developer and a great developer is knowing a little and for the stuff you don't know, knowing exactly what to Google when you encounter a problem you can't solve off of the top of your head. As Albert Einstein famously said, "Never Memorize What You Can Look Up in a Book" — that doesn't mean don't learn anything, but get the basics down and eventually you'll know what to Google when you don't know something.
The real test of any developer is if they're a good fit for your team, have good work ethic and can get the job done. You can find the smartest developer in the world but they might not be a good fit for your team. Culture matters as does a good work environment with compatible people.
The best way to test a developer anywhere in the world is to give them access to a computer, an IDE and their environment of choice. Then ask them to build you something. Don't ask them to write binary search code if they're being interviewed for a front-end position, ask them to build something.
Welcome to your interview; build us a blog, build us a todo app, write a simple Wordpress plugin, write a jQuery plugin or what my current employer did: they brought me in for a trial for a couple of days (paid) and asked me to get my hands dirty on a real project they were currently working on. Just threw me in the deep end and after two days they had a good idea how I worked and if I was a fit.
Thanks for the thoughtful response; I really love the way you worded this.
I agree with what you're saying; the best, most fun, challenging and fair interviews I've had have been at small companies coding side by side with somone. I wonder if it's possible to scale the "build-it" interview up to a google sized org.
Another idea I've been mulling around is hiring people for an N month contract position where you get to work with them. If at the end, both parties agree its a good fit, then proceed. I can see a lot of pit falls to this approach, but it might work really well for people with strong referrals.
When I worked for the ABC here in Australia for a short contract position there was a room of about 10 people from different teams (designers, journalists, developers, managers) and each of them had a copy of my resume. They asked questions based off of what I put on my C.V to see if my answers matched. I thought that was brilliant, ask questions to see if your answers matched and if you were the real deal.
I reckon a spoken interview where you get to know the person and ask them a bit about their experience (not ask them to solve problems) will get you 85% of the way and the other 15% is if they can handle the pressure of the workplace and work well with the team. A few trial hours (unpaid) where you bring in your candidates, sit them down with your team and see how they handle things would definitely go a long way and cost nothing.
Seems I have struck a chord with someone who down-voted me. Would that person care to elaborate?
That's ridiculous, and kind of offensive And it's a great way to scare away the best candidates who will have several offers lined up and skip working for free
Once again some people on HN take things to heart way too easily. You can't voice an opinion on something without someone taking it the wrong way or personally.
How does this work? Did you not have a job at the time? If you did, there are more often than not legal issues involved, depending on the terms of your current employment. This comes up a lot, but I don't understand how it works from a legal standpoint.
The other issue, of course, is that a good developer doesn't have to put up with that, so why would they? I did it once, looking for a job out of college, but never again. If the "interview" is going to cost me more than a couple of hours, then I will work somewhere that knows how to make a decision.
I'd modify that last to "and can get the job done well". Most of my co-workers have been fantastic, but there have been one or two who absolutely got the job done... in ways that eventually cost so much dev time (on maintenance / refactoring) that it would have been better to have someone else build the thing in the first place.
(Which is also presumably easier to discover from sample work than from a whiteboard interview. :)
Ha... I might have chosen the wrong cafeteria, but to me the food was a disappointment during my Google interview. The veggies were way too hard, I didn't like tacos, some of the meat looked indecipherable, and I was fumbling as I wondered whether there was a line, or whether I was looking stupid. I kinda wished there was NO free lunch.
The cafeteria near the gift shop wasn't too bad. I appreciated the hospitality :)
The same logic can be used when applying to college (a very similar process). You apply to a bunch of schools, some of which you don't want to go to. If you have your heart set on Stanford and you don't get in, you still need to go to college somewhere.
I guess the advantage of interviewing at companies that at first glance you wouldn't want to work at, means that sometimes you get convinced by talking to the great people there. I've joined at least one company that wasn't initially my first choice for this exact reason.
I've also cut an interview short once I realized it was a waste of time (H1b formality). If I'm not being taken seriously I won't take them seriously and I certainly won't waste my energy on fizzbuzz questions.
1) You might actually like the work/environment/personal growth opportunities/company health at the "B-list" company once you see it in person. Admit it: your initial classification involved a healthy amount of guesswork and is probably not fantastically accurate.
2) A stupid mistake in your A-list interview hurts both you and the A-list company, potentially dramatically so. You help both them and yourself by practicing.
3) Your increased bargaining power decreases the chance the A-list company lowballs your salary, shooting both you and themselves in the foot (hiring your replacement is expensive, lost productivity due to dissatisfaction is expensive, envy-poisoned work relationships are expensive).
Maybe not secrets, but lessons learned from the current state of the industry. Each one of the points I make is either from a mistake made in an interview I've personally given or received.
It states in no uncertain terms that "always be coding" is wrong. That you should instead spend your time practicing techniques you never use when creating actual software, and that you should also maximize your interview count for salary leverage.
"A lot of what I'm suggesting to do is pretty extreme. A lot of the skills here are not something you learn by doing a standard software engineering job (or get coming out of college). It's especially hard for more senior engineers to do technical interviews since most have limited time due to familial obligations and haven't taken CS 101 for quite some time."
- Know that an interview is a 2 way street. Have questions to ask the interviewers, if they ask you silly algorithm questions, have them explain to you how they use those algorithms in the workplace.
- Make sure the job your interviewing is a place you can fit into, not just the other way around.
- If you don't know something they are asking, just be upfront and say you don't know it, then ask them what it is and how its used at their company. Take note of this for future interviews.
- Don't let the interviewer lead the interview the entire time.
- For those of you haters that don't like the B-list idea, you could ask your peers that work at other places to interview you. (Interesting idea for a startup? Mock interview company? :)