M3 Assessment Presentation Guidelines

Back to Assessments Home

Presentation Guidelines

This guide will serve as a general outline for how students can present their code during a take-home challenge presentation.

Prior to the presentation:

• Clear your screen of all windows or tabs except the ones relevant to your presentation.

• Have any servers fired up and ready to go.

Suggested steps for presenting your project:

1. Overview

• Start with an overview of the app that you built, summarizing the tasks of the challenge. This can be as simple as verbally stating the main functions of the app.

2. Functionality

• Back End
  • Start with Postman and show how your app works through all your endpoints.
  • Run your testing suite and show your test coverage.
• Front End
  • Run through the app, clicking on all the links, entering text into the fields, show the user experience of the application, any responsive design, etc.
  • Run your testing suite and show your test coverage.

3. Readme & Planning

• Show your README (because of course you have a thorough, well-documented readme 🙂) Use this as a guide to show how you organized your application (schema, component tree, endpoints, screenshots or gifs of the UX/UI, etc.)

• Show your project board and any tools you used in the planning process.

• Share any clarifying questions you asked the company and how that guided your process.

Steps 2 and 3 are great places to talk about any challenges you experienced and how you overcame them, what resources you used, why you choose certain design decisions (page layout, filter options, routes, schema, etc.), and what features or changes you would implement next if you had more time to work on it.

4. Code

• Highlight 2-3 pieces of code that you are particularly proud of, either because it was a challenge and you figured it out, it’s something new you implemented, or because that piece of code makes you feel like a wizard! No need to walk through the fine-details of how the code is working, you can safely assume your reviewer is familiar with how React or Rails is working. Of course if they ask specific questions, then you can get into the details.

5. Questions

• Ask if the reviewer has any questions or would like to see anything else.
• Optionally, you can invite feedback from your reviewer. The more specific the feedback you ask for, the better. (ex. “I would love to hear your thoughts on how I structured my database” or “I would love feedback on how I constructed my components.”)

Some General Do’s & Maybe Not’s

Do:

• Show off code that you are proud of.
• Admit when there is a known bug. It’s better if you tell them about it than if they find it and wonder if you missed it. When you share a known bug, you can talk about why you think it might be happening, what you tried, and what you might try next (including reaching out to mentorship for help). This will show you’re thoughtful and familiar with your code.
• Be familiar with the tasks that were given to you and make sure to show each feature and any testing that went along with it. (Be proactive and show this instead of waiting for the interviewer to ask you for each item.)

Maybe Not:

• Walk through your code, line by line, explaining what each line does. This takes up a lot of time and often the interviewer understands how it is working. If they need clarification, they will ask.
• Start your presentation with “What would you like to see?” It’s better to be proactive and take them through your code.
• Expect your interviewer to lead the conversation. Unless it’s clear that they want to drive the conversation, don’t hesitate to jump in and take the lead! You know your work best, so you know what parts of the project make the most sense to show off.