My tips reflect my attitude more than general advice, but here goes:
- 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.
"So you're interviewing at Google and lunch time comes around. Food is free so you eat way too much, especially carbs. Your post-lunch interview is a disaster since you have trouble focusing due to lethargy. True story."
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 idea of using "B-list" companies makes me a bit disgusted honestly. Have we put ourselves on such pedestals that we use other people's valuable time as unknowing practice runs? I would never interview somewhere I was not interested in working.
I can think of three reasons for interviewing at a "B-list" company that have nothing to do with putting oneself on a pedestal.
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).
Because it artificially reduces the talent pool they're drawing from. They might wind up hiring someone less competent who was better at signalling or making concessions to someone who wasn't as far ahead of the pack as they thought based on interview performance. Time and opportunity cost also factor in, of course.
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.
Maybe it's different elsewhere but every college I applied to I wanted to go to. Between the essays, interviews, application fees, and entry requirements I wouldn't waste my time applying to a place I didn't want to get in to.
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.
I don't think it's disgusting at all, I've known many people (not just developers) who do "trial" interviews before they apply to their A-list companies. Interviewing is a skill and if you don't practice it you won't be at your best when it's most important to you. That said, I recommend keeping your ears open and earnestly assessing whether the company may be a good fit even if it's on your "B-list".
Not for practice, but companies do interview people they have no intention of hiring in order to fulfil internal policies or improve diversity metrics.
There are some good tips and links here, but I don't understand the "hacking" metaphor. There are no big secrets. It all comes down to the "always be coding" idea that was presented a few months ago [1]. It just takes discipline and time-management. Succeed at that and many offers will come your way.
The article's thesis is basically the exact opposite of this.
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."
Exactly, the article offers no new insights and the title is mis-represented. It has just listed what we assume we need to do in order to practice for the technical interview. Nice refresher though and I like that every thing is listed out for you.
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.
I really appreciate this article! So many people go to interviews and are obviously unprepared. The simple fact that a person is unprepared for the given task is an obvious show on their personality. This goes for just about anything, not just interviewing. Would you just walk into a test without going to class first? Would you try to fly a plane full of people without first being taught how? So why would you go to an interview without knowing whats expected.
- 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? :)
I don't think this analogy makes sense. I HAVE flown professionally for 6 years and now I'm jumping through cargo-cult like hoops to show that to a new airline.
I am completely against written tests or questions that ask abstract questions and ask you to write algorithms. Unless you're going for a position that requires a PhD in computer science and your job will be writing algorithms and solving overly complex problems, the pen and whiteboard approach just doesn't work in 2013.
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.
> they brought me in for a trial for a couple of days (paid)
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 never had a job at the time when I took the trial. I had just finished a contract position with a media company and was looking for a permanent position with a smaller studio.
> Don't ask them to write binary search code if they're being interviewed for a front-end position, ask them to build something.
+1!
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.
Definitely. Seeing how someone handles a real project, a real challenge with real consequences and timelines is arguably the better way to do it. To find the good candidates you still need to weed out the bad ones, but it's not hard to see who is the real deal by just sitting down and having a chat with them.
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?
I bet you whoever downvoted you did so because you suggested candidates should work unpaid hours
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
I think it's more than fair to ask someone to come in for a couple of hours and see how they work. How is it any different from companies that sit you down and give you tests that can go on for hours unpaid anyway? Think of it as an interview, two hours is not unreasonable unless you're afraid you won't be good enough.
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.
> .... if they're a good fit for your team, have good work ethic and can get the job done.
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. :)
- 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.