📓 4.4.0.17 Whiteboard Evaluation Rubric

In this lesson, we will cover the evaluation form that students will use to review their peers' whiteboarding performance. This evaluation form will be filled out on Epicenter. During an approximately 90-minute session, you will fill out around three evaluation forms depending on the size of your group. Your feedback is anonymous for the students in your group. At the end of the session, you can find the feedback that your peers left you on Epicenter by going to the Peer evaluations tab.

Note that the evaluation form below adds brief explanations for each item. To keep the actual form down to a single page, these explanations will not be included on the evaluation form itself.

Evaluation Form

Interviewer Name: __

Date of Interview: ___

---

(All interviewees will receive anonymous feedback. Your name is required so your teacher can review your feedback. The section above the line will be removed before your feedback is given to the interviewee.)

Interviewee Name: __

Interview the candidate using the following criteria.

Meets expectations:

All of the time: The candidate always met the expectations. Great work!

Most of the time: The candidate met the expectations most of the time. Nice work, but there is room for improvement.

Some of the time: The candidate met the expectations some of the time. Further practice is recommended.

None of the time: The candidate did not meet the expectations and will need to redo the interview. Further practice is needed.

Criteria:

The evaluation form includes both technical and professional criteria. You will evaluate each of the questions below using the following scale: always, mostly, sometimes, never.

Technical Criteria:

Did the interviewee:

Ask clarifying questions? The interviewee should always ask clarifying questions before whiteboarding. This way, the interviewee can ensure they understand the problem.

Write down inputs and outputs? The interviewee should write down expected inputs and outputs before writing out their solution.

Consider edge cases? The interviewee should consider edge cases such as unexpected user inputs.

Use technical language correctly? The interviewee should correctly use technical language. Examples include knowing the difference between functions and methods, parameters and arguments, and so on.

Explain their solution clearly, including summarizing the code from input to output? The interviewee should walk interviewers through their solution and explain their code.

Correctly solve the problem? The interviewee should solve the problem or come reasonably close to solving the problem.

Professional Criteria:

Did the interviewee:

Speak in a clear and easy to understand voice? It's essential for interviewers to be able to understand you — so no mumbling or whispering. Try to pace yourself and don't speak too quickly. If you are a remote student, this also means ensuring that your mic is working correctly and checking in to make sure the interviewer understands you.

Make eye contact? Eye contact is an essential part of a good interview. Don't just stare at the whiteboard — make sure you are actually interacting with your interviewers.

Make good use of whiteboard space and use legible handwriting? The interviewer should be able to read the solution. The interviewer should start at the top left corner of the whiteboard (not in the middle). If you are a remote student, this means ensuring that you are correctly screen-sharing your code and that your code is well organized.

Feedback:

You will be expected to write constructive feedback in this section for each peer you interview. We will discuss writing constructive feedback in a future lesson.