-
Before the technical bit, interviewers like to chitchat. This is what they want to know.
- Do you think about programming? Do you think about how to code well?
- Ownership/leadership. Do you see a project all the way through? Do you fix things that are't quite right, even if you don't have to?
- Communication. Would a conversation with you about a technical problem be useful, or painful?
-
You should have at least one of these:
- An example of an interesting technical problem you solved.
- An example of a personal/interpersonal conflict you overcame.
- An example of leadership or ownership, or what you should've done differently in a past project.
- A piece of trivia about your favourite language (and something you don't like about that language).
- A question about the company (their product or business).
- A question about the company's engineering strategy (testing, methodologies, etc.).
Be a nerd about things. Show that you take pride in what you've done, you're excited about that they're doing, and you have opinions about languages/frameworks/libraries/workflows.
Once you start with the technical questions, communication is vital. Candidates who need some prompting but communicate clearly are maybe better than candidates who fly right through.
-
Understand what type of problem it is. There are two types:
- Coding.
- The interviewer wants you to demonstrate clean, efficient code to solve a problem.
- Chitchat.
- The interviewer wants you to talk about something. These questions are often either:
- System design (a higher-level conversation).
- 'How would you build a clone of X?'
- Triva.
- 'What does this thing mean it that language?'
- Sometimes a lead-in for a 'real' question.
- 'How do you do such-and-such?'
- 'Okay, but what if we didn't have things-and-stuff?'
- System design (a higher-level conversation).
- The interviewer wants you to talk about something. These questions are often either:
- If you start writing and the interviewer intended just to talk about a problem, that'll be frustrating.
- It's worth just asking 'Should I write some code for this?'
- Coding.
-
Make it feel like teamwork. Use 'we.' Use the whiteboard if given the option (of paper or whiteboard).
-
Think out loud. Just say what's going on. Talk through what you're trying. Explain why something didn't work.
-
Admit when you don't know. Something like 'I'm not really sure, but I believe it's kind of like X, because....'
- Pull from other languages or problems to explain that 'because' if need be, or rule out other options if possible.
-
Slow down. Don't just blurt out the answers. You'll have to explain yourself anyway.
-
If you get stuck, get unstuck. It's not a big deal.
-
Try drawing things out, however that works for you. Pseudocode is always good.
-
Solve a simpler version of the problem first, if need be.
-
Write an inefficient, naive solution. Then go optimize it.
-
Keep thinking out loud. Say what you do know, what you don't know, and what you thought you knew.
- Maybe it will turn out things actually do work, or maybe will with just a little bit of modification.
-
Pause a moment for a hint. Don't just sit there wating, but take a moment to 'think,' because the interviewer may have decided to give you a hint, and is just waiting to see if you need it or will give them a moment.
-
Think about constraints. If you don't know that you can optimize, think it out, out loud.
- 'I have to at least look at all of the items, so I can't do better than X.'
- 'The brute force approach is to test all possibilities, which is X.'
- 'The answer will contain n^2 items, so I must at least spend that amount of time.'
- Focus on getting your thoughts down first. Don't worry about details until the end.
- If you can't immediately think of how to implement something, skip it for the moment. Write a call to some helper function, say 'This will do X,' and keep working. If the helper is trivial, it may be that you don't ever need to write it.
- Don't stress over syntax. Just push through it. Use pseudocode (or just English) if you must. Say that you'll get back to that part.
- Leave a lot of room. You'll probably need to add code, comments, or notes later. Start at the top, and leave enough room between lines that you could fit another line.
- Wait 'til the end to worry about small details (off-by-one, etc.). Make a mark so you don't forget to come back to it at the end.
- Use good naming. It might take a little more time, but it will help. You won't forget what bits of your code are doing. Imply the type in the name.
- Walk through the solution by hand, out loud, with an example input.
- Write down what values the vars hold while the program is running. Doing it in your head doesn't impress anyone.
- This will help you find any bugs more quickly.
- This will also help the interviewer be sure of what you're doing, so there's no confusion.
- Fix the little problems (off-by-one, etc.).
- Test edge cases.
- Don't be boring. Some interviewers won't care about this step. If you're not sure, ask:
- 'Usually here I'd check my code against some edge cases and do some tests. Should we do that now?'
- There's no substitute for actual practice.
- Write code with pen and paper.
- Be honest with yourself. This will be awkward. You need to get over that now so that you're not being awkward when it's time for the real thing.