Take-Home Presentation Guidelines

Presentation Guidelines

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

Note

Keep in mind that some companies will have their own guidelines on presenting which takes precenedence over this guideline.

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.
Have Postman setup in advance to show your endpoints (BE).

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

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.

For an API only application, start with Postman and show how your app works through all your endpoints.
If you are working with a monolith, present the user interface and show the user experience.
If you have a testing suite, now would be a great time to run it 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 nitty-gritty.

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.”)

The above steps are not written in stone and if you prefer to switch up the order, that is fine. The more important idea is that you have a process for showing your code in a succinct, effective way. Using this guideline can help to ensure you hit all the relevant points about your app and your process.

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.