Repository navigation
How to run a mock interview for Reactor Prep
Mock interviews for Prep purposes should be relatively short.
Most failure modes emerge pretty quickly -- within the first 10 minutes. See the "Common warning signs" section below.
Thus, dragging out a mock interview for 30 to 40 minutes and then talking about it for another 15 to 20 minutes is kind of a waste of valuable time. This time could be better spent practicing and/or running a whole new mock interview.
- Keep mock interviews to 20 minutes.
- Be friendly but not too helpful.
- Resist the urge to talk too much.
- The more you talk, the less airtime they have.
- The less airtime they have, the less chance they have to perform.
- That said, if the interviewee asks you stuff, of course you can and should engage with them.
- Try to hint as little as possible.
- The more you hint, the less autonomous they are, and this counts against them in the real interview.
Most interviewees will demonstrate many things that could be improved.
However, it's human nature to only be able to absorb a few things to improve at one time. Much more than that becomes overwhelming.
- Keep commentary / feedback to 5 to 10 minutes.
- Offer a maximum of 3 takeaways to improve for next time.
- Make sure to really read the problem first.
- Look for assumptions and actively clarify them.
- Use your interviewer as a kind of pairing partner
- Ask (thoughtful) questions and present multiple options.
- Don't just dive into coding
- Make a plan first
- Make a quick skeleton
- Talk about what you intend to do next more so than just narrating a blow-by-blow of what you're doing now.
- This gives your interviewer a better chance to help you avoid pitfalls.
- It's ok to be silent for short stretches.
- You can focus on just finishing basic coding that doesn't merit much commentary.
- It's not ok to be silent for long stretches.
- Bring the interviewer along for at least the high points of your thought process.
- Review and over-learn JavaScript basics.
- Under live interview pressure it's to forget and be uncertain about syntax etc.
- Really memorize that stuff so you don't waste time on easily predictable / avoidable time-suckers.
- Just get a simple / brute-force implementation working first (often, by using a for-loop rather than higher-order functions) then convert to higher-order functions with extra time.
- Review higher order functions and make sure you can use them fluently.
- Writing them from scratch is a good way to double-check that you really understand what they do.
Most of the above stuff is covered in the Learn articles for Module 3. Read those, and feel free to direct students to re-read articles that are relevant to the area(s) where they demonstrated personal weakness.
Most learners, if they are going to do poorly on the interview, will pretty quickly show the following warning signs:
- At the very beginning, they don't read the problem properly, and begin solving the wrong problem.
- They don't ask questions.
- They just dive into coding.
- They make a "plan" that's too vague to be actionable.
- They talk for too long about their ideas, eating up implementation time.
- Their coding demonstrates fundamental misunderstanding of JavaScript.
- Their coding is illogical.
- Their code is rife with typos and other style problems, it looks sloppy.
- They quickly create code that doesn't work.
- Then they are ineffective at debugging.
- In particular they can't do the "Be the Interpreter" technique.
- They write code for a long stretch without testing it.
- They simply proceed way too slowly, they have no chance of finishing in time.
- They code in silence, typing away.
- They mumble to themselves incoherently and inaudibly.
- They jabber nonstop while coding. Yes they are talking, but but not usefully.
- They start writing an overly-complex implementation (e.g., using
reducewhen a for-loop is far simpler), and they can't execute on it, so they will run out of time.