whiteboard_problems.md

Whiteboarding Questions / Technical Interview Questions

The Interview Process

The interview process - approx. 3-5 interviews, approx. 1hr each. Here is a rough outline of the process. It doesn't always occur in this order and sometimes there are multiple behavioral/technical rounds.

1. Resume screen (i.e. submitting the job application and getting past HR)

2. Coding Challenge on leetcode or something similar

3. Technical Interview One. It could be ... a. A technical conversation (talk about a project you've done, a technology you like, etc) b. A whiteboarding problem

4. Technical interview Two. It could be ... a. A technical conversation (talk about a project you've done, a technology you like, etc) b. A whiteboarding problem c. A take-home coding assignment (a weekend project) - They say "it should take 4hrs". It always takes twice as long. Aim to write production-quality code w/best practices, and treat it like a professional task - deliver on time, communicate delays, etc.

5. Behavioral Interview

6. Final, final interview (if you're here you're in the running). Sometimes just a nontechnical conversation

   • Have good questions to ask about the company and career growth.

The Whiteboarding Problem / Technical Interview

History

Historically, a whiteboarding problem was in-person. It meant writing code on a whiteboard to solve a technical challenge / or task, and, maybe doing some design (drawing database tables/schema, etc).

It comes from Computer Science courses. Traditionally the problems have been algorithm/data-structures focused.

Today

It has evolved over time ...

• Usually over zoom
• Usually writing code (but maybe not running it)
• Not always algorithm/data science problems, BUT, focused on thought process.

Purpose / function

The interviewer wants to see how you think. The interview is:

• 60% process, 40% solving the problem.
• A huge part of this is the process.

IF YOU DO WELL ... they will push you more in the interview. You can still get hired if you don't finish the whiteboarding problem..

Succeeding At Whiteboarding Problems

"The interviewer is not your enemy -- they are your ally" -- Sierra Platoon.

Treat the interview like an audition. Preparation and practice are essential.

2-5 Days Before Interview

ALWAYS 1-3 DAYS BEFORE THE INTERVIEW, CONFIRM:

• Language / task
  • Usually you can pick the language.
• Ask for name/role of who is interviewing me

Day of Interview

• Do nothing or light review 1-2 hours beforehand.

Tackling the Problem

Time management is important - you want to be writing code about 20min in, 30min max, aim to have a solution working 10min before interview is over.

• Checking in / asking the interviewer about time is never a bad idea.
• Saying out loud if you are stuck is never a bad idea.
  • This demonstrates awareness of the importance of time/project management in software.

1. Repeat the question

   • Shows we are listening
   • MAKING SURE WE UNDERSTAND THE QUESTION
     • That the interviewer KNOWS we understand the question
     • Clear up confusion
     • Clarify if there is a misunderstanding
       • Sometimes the interviewer made a mistake / the question has a problem
   • Double-check assumptions -- confirm/say out loud
   • Buys us time
   • Establishes a dialogue

2. Fully understand what the algorithm/function expects on the way in and out. WRITE ALL THIS DOWN ON THE SCREEN AS YOU TALK THROUGH IT.

   A. What are the inputs?

   • type and shape (int/string/dict etc)
   • can there be different types?
   • think out loud about EDGE CASES
     • Special characters for strings, zero or negative numbers for ints, etc.
     • When in doubt, just say you'll handle an edge case later. B. Input size / bounds?
   • Asking shows that you understand that input size affects performance
   • A good approach is always to prototype for a small input size, and worry about a big input size later.
     • The interviewer will ask you to do this. C. EDGE CASES
   • Always think about / talk about edge cases. D. Output?
   • What kind of output / what format?
     • Missing a detail in the output specification is a common gothca.

3. Talk through the simplest possible version of the problem

   • Extremely small / simple data
   • Extremely simple implementation (no edge cases yet, etc)
   • You might end up writing pseudocode or code for this.

4. Explain your approach to solving it (recursion, iteration, etc.)

   • Ask the interviewer, "what do you think? does that make sense?"
     • Give the interviewer opportunities to ask you questions.
     • Approach the process collaboratively.
     • Shows your awareness of the process.

5. Pseudocode with your interviewer

6. Writing Code

   • Work in small (tiny, tiny) chunks.
     • Get each chunk working before you move on.
   • Start with the simplest possible implementation for the simplest possible case, and get that working.
   • Don't be afraid to ask questions / ask for help / check in.
   • Don't be afraid to switch gears if you get stuc.
   • KEEP TALKING.

7. Talking through the solution together / Explain how you would test it.

8. Be prepared for the interviewer to "add on " tasks / make the problem harder as you go.

   • This means you are doing well!

Always be speaking your mind, never go silent. Always be asking questions and if you get stuck, ask for help!