Just thought I would give my impressions of how this might go down if you interviewed for the large start-up I work for. (I'm speaking from my own experience, n

Just thought I would give my impressions of how this might go down if you interviewed for the large start-up I work for. (I'm speaking from my own experience, not on behalf of the company in any way.) 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).