- 15 mins Introduction
Per interview.
- 10 mins Introduction
- 15 mins Interview
- 5 mins wrap-up
Wrap-up and questions
- 45 mins wrap-up and questions.
- To work out if they want to hire you.
- Technical fit.
- Experience fit.
- Personality or "culture fit".
- Requirement is generated.
- Sourcing - advertise and network.
- Review resumes.
- Interview candidates.
- Decide on a candidate.
- Apply for the role.
- Complete a code challenge.
- Have a phone screen.
- Onsite times x interviews...
- Phone.
- Remote / Video conference.
- Onsite.
- Algorithms and Structures.
- Technical interview.
- Whiteboard/Coding exercise.
- Product interview.
- Abstract problems.
- Heavily theoretical.
- What's the best technique to solve a problem?
- Relies on prior study - often LOTS of prior study.
- Not just knowing the algorithm but how to articulate it.
- If you can't go deep, go broad.
- "I don't know but..."
- Propose alternative idea(s).
- Their behavior sends important signals.
- Technical questions - what is a thing?
- Often hands on:
- Troubleshoot a problem.
- Solution-centric - how would you do it?
- Architecture - draw an architecture.
- Best practices for Engineering.
- Also study-based.
- Work on problems and problem solving.
- Be able to talk through process - "When we did our projects we did..."
- Tests and testing are often weaknesses - know background and types even if you've not written a lot. Know the why.
- Know Git, GitHub, Eng workflow, Agile.
- Not knowing is okay.
- "I haven't done but I have done..."
- "I have done x with y so I am looking forward to z."
- Turn the question(s) around:
- "We did some Agile, what do you do?"
- "What it's like to work on x?"
- "Do you have a tool for x, what's it like?"
- The solution is important.
- But the journey is important too.
- Show your working!
- Best method to learn is to run exercises.
- Rehearse/practice talking through your solution as you build.
- Ask questions - this isn't a one way street.
- Assumption is the mother of all ice cream truck crashes.
- Break the problem down - start with data structures, model and then code.
- Pseudo-code beats no code.
- Usually done by a designer or product manager.
- They want to know how you'll work within a product lifecycle.
- They want to know if you care about their product.
- Often overlaps with personality interview.
- Know them and their product.
- Typical questions:
- "What's worst aspect of product?"
- "What would you change?"
- "What do you love about the product?"
- "Why do you think product does x?"
- Be enthusiastic about their product.
- Have a good story about their product.
- Have a product idea.