• Solve algorithms in a technical interview setting
• Identify the Big O time complexity of an algorithm

For this activity, you and your partner will each choose a problem and solve it in front of one another, and you will also calculate the time complexity for the solution. You may select a problem you have already solved or a problem you have not yet solved during this Phase. You may complete this activity using an actual whiteboard, if available, or in the IDE of your choosing, such as VS Code or an online REPL.

Keep in mind that these challenges tend to make people nervous, so remember to always be kind, patient, and encouraging. Also be aware that nerves can cause people to come up with some pretty weird solutions to problems, so remember to bring your empathy with you!

Plan to spend 15 minutes in each role. This means you and/or your partner might not have enough time to finish the solution, and that's OK. If you can reasonably spend more time on this, you can, but do put a time limit on it. Be sure to calculate Big O for time complexity even if your solution isn't complete. If you can, try to reason about and discuss what Big O would be if you had completed it based on your pseudocode.

As the interviewer your job will be to first present the problem. Explain the challenge to your partner and provide some example test cases. You are not expected to provide every possible test case or edge case. Instead, provide just enough detail for the interviewee to understand the problem and ask clarifying questions. Example: "For this challenge, your function will accept a single string as input and return it in reverse. So if it were to receive 'cat', it would return 'tac'."

You will also need to answer questions. Your partner might ask you to confirm their understanding of the problem or whether or not they should handle certain edge cases. If you don't know the answer to a question, it's OK to say "I don't know" or "I'll let you decide." Sometimes the interviewer doesn't have the answers.

Notice when your partner gets stuck and needs a nudge in the right direction. Provide helpful tips or hints, but don't give away the answer. Ideally, your partner will ask questions when they get stuck, but if you notice that they're struggling with something for a little too long, don't be afraid to give a little nudge. You can also ask in advance if your partner would like a hint before providing advice.

When time is up, provide a constructive review of your partner's performance. Some areas to talk about include:

• Problem explanation: did your partner explain the problem back to you in their own words and confirm their understanding before coding? Did they ask clarifying questions when necessary?
• Testing: did your partner check their understanding against the given test case/s? Did they write their own?
• Pseudocoding: did your partner explain what they were going to do out loud before coding and with pseudocode? Did they check their pseudocode against the test cases?
• Solution: did your partner solve the problem? Was their syntax correct? Did they handle all of the test cases? Were variables and functions named appropriately? How readable was the code?
• Openness to feedback: Did they ask for feedback when necessary? Were they receptive to your feedback?

Ultimately, it is more important for the interviewer to evaluate the interviewee's communication during this exercise, so if time is an issue, focus your review there rather than on the solution itself. When providing feedback, be specific, so your partner has an opportunity to improve. Also structure your feedback into two sections. For example, you might talk about what went well and then what can be improved, rather than mixing them together.

As the interviewee, your job will be to solve the problem posed by your partner. The Interviewer instructions above explain which areas you should focus on in order to ace your interview. The content in the Welcome section of this course will also help, so make sure you read it before attempting your first whiteboard challenge.

Here are some general tips:

• Communication is key: explain the problem and your approach to the solution
• Assume you haven't been given all of the information, such as all of the inputs you need to account for
• Ask for help when you need it and be receptive to feedback
• Don't be afraid to admit when you know there's a better way to do something, e.g. "I know I'm brute forcing this solution and there's a more efficient way, but I want to solve it first and then optimize once I know I can solve it."

When time is up, provide a constructive review for your interviewer. Some areas to talk about include:

• Did the interviewer communicate clearly? Could you understand the challenge and did they answer your questions in a manner that you could understand?
• Did they give you time to solve the problem or explore a possible solution before providing feedback? In other words, were they patient?
• Was their feedback helpful?