Architecture or System Design Interviews are a common way for Software Companies to evaluate candidates and are open ended enough to have volumes written about them. This talk will try to address expectations from interviewers and candidates for this interview type and Bharat's account for how Indeed manages them.

1. Under the Hood
of Architecture
Interviews at
Indeed

2. Introduction
- Software engineer for 6 years, at Indeed, India for 5
- Trainer for Architecture Interviews
- Conducted 100+ Architecture Interviews
- Organised calibration sessions for cross-site interviewer panels
Disclaimer: This is not a presentation by Indeed. It is my personal account of how
Architecture Interviews and interviewing, work at Indeed, some of its implications
and learnings.

3. Interviewing Philosophy at Indeed
- Candidate experience is the top priority
- Allowing them to best represent themselves
- Providing all the necessary directions for them to succeed
- What does this do?
- At best, a good time for everyone involved. At worst, a learning
experience for the candidate
- Requires good training. A fine line between helping the
candidate succeed and giving away the solution

4. Interviewing Philosophy at Indeed (contd.)
- Conducting objective interviews
- Involves defining beforehand the specific criteria for evaluation and communicating that
precisely and widely
- What does this do?
- Consistent experience for all candidates
- Consistent evaluation across geographic sites

5. Learnings for interviewers
- Mastering the interviews one thing at a time
- Interviewing is open ended enough to not require more complications due to changing interview
type, or the way of asking questions to the candidate
- Once mastered, interviewer knows their round in and out. There are fewer or no surprises
- Note: must keep in mind that it’s still a first time for the candidate :)

6. Learnings for interviewers (contd.)
- Criteria to evaluate a candidate on
- Finding out: how well the candidate would perform designing systems in your team
- No correct solution, everything has tradeoffs
- Ability to understand the problem, any relevant requirements or technical constraints, offer a
system architecture that solves the problem with justification and alternatives considered, find
solution(s) to problems that can arise
- The final solution on paper
- The process to reach that solution
- (Optional) Knowing what to communicate

7. Learnings for interviewers (contd.)
- Responsibility to help candidates succeed
- Help highlight the strengths of the candidate
- If they don't have the necessary skills in one area, there’s little use in asking more questions
about it
- Perhaps they are knowledgeable about something else that is relevant
- Hints to keeping conversation useful and ensure no time is wasted
- No reason to be rude or cause something that spills into next interviews

8. Learnings for candidates
- Lead the interview as you would lead a design
- Have a planned structure in mind, ahead of time

9. Learnings for candidates (contd.)
- Product requirements are important – defining the problem
- Scoping a problem can introduce or remove components from your design

10. Learnings for candidates (contd.)
- Technical depth helps – just overview is not enough
- Preparation through reading designs may lack circumstantial knowledge – something may work
well in theory but require checks and balances in practice
- Draw from experience on projects, or build sample systems

11. Learnings for candidates (contd.)
- No right answer – everything has trade-offs
- Justification and reasoning is very important
- There’s almost always an alternative. Contrasting and comparing displays technical breadth
- Remember to stay relevant to the problem at hand

12. Summary
Interviewers
- Focus on mastering one thing at a time
- Formulate a criteria of evaluation
- Help candidates succeed
Candidates
- Lead the interview like a design review
- Clearly collect requirements
- Demonstrate technical depth
- Justify choices made