When doing this exercise as the interviewee, you should record yourself answering the interviewers question. This must be uploaded on youtube and the link is one of the components of your development journal. If you prefer, you may make the video private and invite your PM. This will be of great use when working with your career coach!
In order to get you guys more practice whiteboarding, we're going to have you pair up with a partner once a week and have you both swap between being an interviewer and an interviewee. This ensures that each student gets in at least one live whiteboard practice session a week.
This is how it's going to work. Everyone will be a assigned a problem. This will be the problem that you will pose to your interviewee when it's your turn to be interviewer. You're being assigned the problem at the beginning because it's very important that you get familiar with your assigned problem. In order to be an effective interviewer, you need to know the problem you're asking inside and out.
A working reference solution will be given to you, but you should figure out other ways to solve the problem because everyone thinks about problems differently. What's important here for you as an interviewer is be familiar with multiple approaches to solving your given problem, as well as the tradeoffs between working solutions. Your interviewee may very well come up with a solution to the problem that is very different from the reference solution or your own preferred solution, but that doesn't mean they are wrong. At that point, it will be your job as their interviewer to discuss with them the tradeoffs between their solution and yours.
Additionally, the working reference solution you've been provided with will be in JavaScript, but we don't want to limit interviewees to having to whiteboard in JavaScript. Some of them may wish to go with Python (or even C if they're really brave). You should be able to effectively act as their interviewer regardless of the language they choose to implement their solution in. This will give you the chance to discuss problems in multiple languages, or in pseudocode.
As an interviewer, you hold a lot of power in your hand over your interviewee. You can make life pretty straightforward (though this doesn't necessarily mean easy) for them, or you can absolutely ruin their day. It goes without saying that we're aiming for as much of the former as possible.
For the purposes of this whiteboard pairing exercise, your job as an interviewer is to set up your interviewee for success as much as you possibly can. While the question that you pose to your interviewee may itself be challenging, we want everything else to be lined up such that your interviewee has every chance of succeeding.
This means that your interviewee should not have to deal with vague instructions, unclear expectations, or the mind games of trying to guess "what does the interviewer actually want?". This is why it's of the utmost importance that you, the interviewer, review the instructions of your assigned problem and make sure that the instructions and expectations of the problem much as much sense as possible. If they don't, then they need to be cleared up. Better for you to figure these things out beforehand than for your interviewee to have to suffer through it in the moment.
Additionally, another very important function of interviewers is to provide constructive feedback to your interviewee. This is very important, since the whole point of this exercise is to get you all more comfortable and better prepared for whiteboarding in a real-world interview setting. Tell your interviewee what and how they could have done better. If they weren't able to solve your problem to completion, give them pointers on how to improve, for example, "When seeing a problem like this, your first thought should be to use this data structure because of x, y, and z."
Don't ever put your interviewee down. Everyone is here to learn. Don't forget that, and always try to be patient with your interviewee.
As you interview, mentally note things that you appreciated that the interviewee did, and things you think might not have reflected positively on them. (You don't have to share this information with them; if you do, make sure you do it in the nicest, most constructive way possible.) Remember these do's and don't's when you are the interviewee.
The goal of the interviewer is usually not to see if you can solve the problem (though is is the goal for some interviewers). The goal is generally to see how you think your way through a problem. This is to your benefit; if you don't know the answer, that's fine--just think your way though it.
But don't think just to yourself. Think aloud. The interviewer wants to see your thought processes. This benefits you a couple different ways:
- It's easier to think about a problem when you're talking out loud.
- The interviewer can tell if you're getting closer to the right track, and can offer you hints to guide you along.
When you are asked a whiteboarding question, step one is: understand the question. Pore over it, describing aloud what the question is asking. If something doesn't make sense, get clarification. If you don't understand the problem, the interviewer will note it, and you'll be extremely unlikely to be successful with the problem.
Keep Polya's Problem Solving Techniques in mind.
Barely any whiteboarding questions will have obvious answers. Don't get frustrated if you don't see the answer right away. Usually the problems have to be probed and broken down before any kind of answer becomes apparent. Frustration will prevent you from thinking clearly, and will leave a very negative impression on the interviewer.
Instead of being frustrated, look upon the problem as a curiosity that can be explored. Turn the problem over in your head and look at it from different angles. The problem itself is fascinating to look at, even if you can't see the answer.
If it helps, try to imagine that the interviewer is on your team, and that you're working collaboratively. Even if they aren't actually helping, this mindset can put you more at ease and allow you to think more clearly.
Finally, don't cheat. You'll only be cheating yourself. Here at LS, the goal is to get practice coming into a semi-stressful environment and being presented with a problem for which you don't know the answer, and have to think on your feet. If you practice the problem in advance, you'll lose out on that opportunity. There's no penalty at Lambda School if you don't get the answer. Use the time to practice solving difficult problems from a cold start.
Googling during a whiteboarding pairing session is not forbidden. That being said, Googling should be done within reason. Obviously don't allow your interviewee to just google a solution to the problem. However, checking MDN for a useful method is acceptable, as well as checking Wikipedia for a definition. Use your best judgment as an interviewer.
If the interviewee needs to know a function signature, one approach might be to look it up for them and provide it to them.