Coding interviews (aka. whiteboard interviews, or programming interviews) are the primary tools used by Indeed and major tech companies (e.g. Google, Amazon, Facebook) to measure technical skills for potential employees. There are a lot of articles and talks to help interviewees prepare and perform well on the coding interview. However, not many of them share insight into how employers conduct coding interviews and their challenges. This talk is mainly for companies/managers who want to improve their hiring, or persons who are inspired to be a good interviewers. Wanasit will share his insight on how Indeed (and other tech companies) designed their interviewing processes and trains interviewers, including their principles and challenges. For the interviewees or students, this talk helps you understand the interviewer-side perspective, thus, helps you prepare for the next interviews. It also includes a few uncommon interviewing tips at the end.

1. How Indeed asks
Coding Interview Questions
An insight from conducting hundred of interviews for engineering at Indeed

2. About me (Github: wanasit)
Software Engineer @ Indeed Tokyo
● At the company for more than 7 years
○ (ex Hiring Manager)
● Interview Trainer (Coding interviews)
○ I have coached other interviewers
○ I have written interview questions

3. About this presentation
● Disclaimer: This presentation is NOT written by Indeed
○ Mostly based-on my research and personal experience about
interviewing (not only, but mostly, @Indeed)
● Goal: To hopefully raise the standard for interviewing experience
among tech companies and engineers in Japan
○ To help the companies identify the right engineers
○ (= To help more engineers get job)

4. Agenda
1. About Structured Interviews
○ How Indeed (and other tech companies) organize the interview process
and its principles.
2. About Coding Interviews
○ Format and interview approach
○ About choosing questions and training interviewers
3. Tips for taking coding interviews
○ Probably uncommon advices from the interviewer’s perspective

5. Structured Interviews

6. Use Structured Interviewing
At Indeed (Google, FAANG), we use Structured Interview(s):
● Structured interviews != Coding interviews (not exactly)
● From Google research (supported by previous other researches)
○ The only scientific proven prediction for performance after hiring
○ Having the structure is more important than the questions or
exercises you use (coding or not).

7. Unstructured Interviewing
● A interviewer (a manager or engineer) ask arbitrary questions:
○ "Tell me what is your strength and weakness” , "How many golf balls would fit
inside a 747 airplane?", “Could you implement binary search in Java?” …
○ (then, decided with arbitrary reasons on what/how they are good answer)
● Problem: “Everyone think they’re good at interviewing”
○ They often believe they “understand” and “see-through” the candidate
○ (This also includes the speaker :p)

8. Structured Interviewing
1. Use a well-designed interviewing process
○ A standardized set of interviews, questions, and exercises
○ A shared understanding of what good (feedbacks, rubrics, etc)
2. Provide interviewer training and calibration
3. Be aware off and counter subjective bias(es)
(+ Constant review and adjustments)

9. Indeed’s Interview Process (SWE)
1. Phone Screen Interview or Karat (Whiteboard-like 30-60 mins)
2. The main/on-site interview (1-2 day)
○ x2 Whiteboard Coding Interview (aka. Coding Interview)
○ x1 Architecture Interview (aka. System Interview)
○ x1 Code Review Interview
○ x1 Resume Deep-Dive Interview
3. Team matching and hiring
** Note: All above are constantly reviewed and subjected to change

10. Bias or “Personal soft-spot”
Each interviewer rates engineer as good/bad based-on observations
(subjective or objective, technical or non-technical)
● “His English is difficult to understand…”
● “He doesn’t write tests…”
● “He can implement X algorithm in y min!!”
● …
However, are these reliable signals? e.g. what if this one candidate (in this one
interview) happen to have a bad day (and forgot to write test)? or vise versa?

11. To counter the bias
Don’t interview alone (Avoid: A single point of failure).
Have multiple independent interviews
Also, make sure they are really “independent” e.g.
● Interviewers are not allowed to discuss until the debrief
● More junior interviewers always speak first
● Or, at Google, the interviewers do not even attend the debrief discussions

12. Coding Interviews

13. Coding Interviews
● aka “Whiteboard Coding Interviews” (or just “WB interviews”)
● You are expected to solve a programming problem on a whiteboard
or an online shared document
○ You are expected to write realistic “workable” code (no pseudo code, no
hand-wavy explanation)
○ A session is 45~60 minutes. Typically a single problem (but some companies,
e.g. Facebook, may ask you solve multiple easier problems)

14. The Interviewer Objectives
1. (Primary) Get the signals on candidate technical skills
○ “(in 1 hour) form a strong opinion about the person if the person would work
productively as an engineer at Indeed”
○ Keeping the candidate focus. Hint or unblock if necessary.
○ Avoid telling candidate what to do, only point out the relevant facts/problems.
2. (Optional) Keep the experience positive
○ Keeping things challenge for his/her experience level.
○ Avoid pressuring he/she (whether he/she is doing well or not)

15. The Interviewer Training Progression
● Student
○ Pick an interview question. Shadow (observe) interviews on that question.
○ (Also, encouraged to beta-test asking that question to other engineers)
● Leading with Shadow
○ Start asking the question to the candidate.
○ Reversed shadowed by more experienced interviewers (on that question).
● Graduated
○ Is allowed to solo interview and reversed shadow

16. Choosing Interview Questions
● Relevant and practical
○ A realistic problem with common data structures (no “exotic” data structure
and algorithms)
● Challenging (in a good way)
○ Avoid a single "Aha" moment or “either you know or you don't” questions.
○ Has multiple ways and layers. Requires thoughtful design and implement.
● Robust / Easy-to-ask
○ Agnostic to programming language, frontend/backend experience, etc…

17. Choosing Interview Questions (2)
Above-all-else: Always try the questions with engineers in your company
● Note how far/fast can the interviewees solve
● Note how many different ways people can solve the problem
○ Or different ways people fail at the problem
○ (e.g. most candidates missing that single "Aha" insight, TypeScript is
easier than other platform, …, etc)

18. Tips for taking coding interviews

19. Tips for taking coding interviews
Disclaimer: Personal opinions. Not guarantee the results.
(but so as other advices on the internet)
1. Practice: Coding skill > Algorithms
2. Practice: Foundation > Puzzle solving
3. Write Clean Code

20. 1. Coding Skills > Algorithms
● (from my experience, in contrary to what most people say)
● The #1 reason people fail is: not be able to do programming well
○ Not because their lack of algorithm knowledge
○ This require “normal” programming experience you could gain
at work (or school)
■ However, this still requires deliberate practices (e.g. code review,
pair programming, side projects, …, etc)

21. 1. Coding Skills > Algorithms
● You should be able to turn your ideas into code proficiently
○ In a programming language of your choice (Some libraries are ok)
○ No pseudo code, no hand wavy explanation. If you cannot do what you said
should-be-done, it is not useful
○ If you couldn’t or could “barely” solve the problem with code, it is unlikely that
you’d be able to employ more sophisticated techniques
● You should understand your code in details
○ e.g. how the data are moved, stored, organized, etc.

22. 2. Foundation > Puzzle Solving
What we hope
candidates prepare
What candidates often
actually prepare

23. 2. Foundation > Puzzle Solving
● When you “over-practice” puzzle solving
○ Harm engineering practice (e.g. you would not write code like this in real life)
○ It’s visible in the interviews (e.g. no principle/analysis/.., suddenly the solution)
● Focus on getting hired vs improving your foundation:
○ Study/review the courses or textbooks would help you be a better engineer.
○ And it’s compounded even if you don’t get hired now.
● My recommended is 7:3 (or 8:2) Studying/LeetCode-ing

24. 3. Clean Code Matters
Myth: “The interviewers don’t care about is your code quality (as long as
it solve the problem efficiently)”
● First, this is wrong. Most interviewers do care.
● Second, (even if it’s true) it is missing the point…
○ You are NOT only writing the code for the interviewer
○ You are writing the code for yourself

25. 3. Clean Code Matters
● Because you don’t really have time or energy to debug later…
○ Do not ever think that the interviewers will not spot your bugs
● You should write code as “clean” as possible
○ (whether in production or interview)
○ Use good naming.
○ Use good abstraction (private methods/functions)
○ Be able to reason about your code at each routine

26. Summary

27. Summary
● For Employers/Interviewers
○ Use structured interview(s)
○ For coding interview:
■ Choose the right interview questions (or exercises)
■ Train/Calibrate interviewers on the question
● For Students/Interviewee(s)
○ Practice programming well (before doing difficult algorithms)
○ Spend time to understand the foundation (not just LeetCode puzzle)

28. Investment Cost on Interviewing
How much it cost Indeed to interview an engineer:
● x5 interviews each with 1-2 interviewers
● 1h interview + 1h feedback/discussion (+1h practicing)
● => 20~30 hours (aka. a whole weekly sprint for one engineer)
e.g. if we want to hire 3 engineers and the interview passing rate is 20~30%,
then, we would have 10~15 interviews. Remove X sprints from the roadmap…