Developer Job Interview Tips
simpleprogrammer.com
simpleprogrammer.com
1.Why? You're resume will be glanced at, not much more. We just care about how much experience you've had, so we can aim the right kind of questions at you. (You like Haskell? Try this) As long as you don't claim to be a master in ten languages after 2 years real world experience, it really wont matter. Just list your alma mater, your previous companies, and what you like working on or with, and you'll do fine.
2. I'd recommend against it, you'll come off as creepy if you mention or slip up any of the details. And whilst you're at it, avoid looking up common interview questions for the company, everyone uses different ones and it's extremely obvious if you already know the optimal solution. And if you do get asked a question you know the answer, or someone else from the company has already asked you, tell the interviewer and they'll ask you something else. It's worth it, anything sneaky or underhand comes off extremely badly and is usually enough to get you rejected.
3. I've rejected many candidates from internal referrals, and usually people are pretty honest with their referrals, they'll say if they don't know enough about you. It's not in anyone's interest to hire someone who isn't a 100% fit, so if you ask me for a referral, I'll only fight for you if I know you're good for the job and my colleagues will do likewise. There's a difference between asking for a referral and being asked to apply. If you really want an 'in', find the companies GitHub and start sending pull requests, if your code is good, you take the reviewers advice and get your patches merged, someone will get in contact.
4. Finally, one I agree with! You'll be asked a range of algorithm based questions, coding based questions and more, so get comfortable with these kinds of questions.
5. Again, I agree. But it's usually obvious if you're feigning passion, so be passionate and let it show. Push for the optimal solutions, if you don't get there, ask what the best solution was. When they ask if you have any questions, ask what they do, what their role is and what you could end up doing. Figure out if it is for you, and if so, say so!
6. Maybe this applies to other companies, but we wont ask 'trap' questions. They aren't useful to us, they're too easy to avoid. However, avoiding a question is never a good idea. Also, questions like "What was the result the last time you and a coworker disagreed on a technical issue?" aren't trap questions, they are real life situations. These things happen, and as long as you can demonstrate that you are reasonable and mature, you'll do fine. Even if you say, "I tested both hypothesis, and he was correct, so we went with his way, I apologized and learnt from the situation", that okay! We're engineers interviewing you, we realise people can be wrong, showing an ability to learn is great.
7. I agree! Don't lie. That should go without saying.
8. Again, that should go without saying.
9. Again, as with the algorithms one above, if you don't know what a linked list is, you're applying to the wrong job.
10. This probably the only non-trivial point of the article. Building things is a great add a bit to your CV. I can't speak for my colleagues, but of I have a candidate that has build something I can take a look at, I'll spare 5 minutes before the interview to take a look, especially if it sounds interesting or complex. From me, expect a question about how you got round a certain problem or how you built it. It gives you a great chance to show your enthusiasm and show that you want to build and ship code.
These are just my impressions, not definitive by any means, I'd be interested to other experiences interviewing(or indeed being interviewed).
When I am screening resumes, the only things I care about, in order of importance, are: github repos, well-answered stackoverflow questions, a technical blog. I barely even read over the education and experience sections. If a candidate doesn't have documented, public proof of quality, I have no way of assessing their quality and always say no hire in this case.
and the next sentence...
> When I am screening resumes...
Ok.
> If a candidate doesn't have documented, public proof of quality, I have no way of assessing their quality and always say no hire in this case.
You could do it the good old fashioned way and talk to them but if you want to let Google do the interview for you then that's your choice.
There is not enough time to talk to the hundreds that apply - this is impractical.
I've only been an interviewer a couple of times for dev positions, but I tend to look at attitude, passion for the job/industry (incl. self improvement regarding practice and learning via books/training courses), participation in communities/projects and freelancing experience aspects. If someone can get regular freelancing gigs that pay money, then it's a good bet that the developer is able to earn his keep and is pretty self-sufficient.
I agree with you about the things to look for in a developer. Especially self improvement. I often ask developers how they keep themselves current and I either get really good answers or confounded looks.