interview-tips.md

general job interview tips

small talk

• 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.

communication

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?'
  • 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?'

• 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.'

get your thoughts down

• 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.

clean up

• 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?'

practice

• 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.