Most hiring managers for product management, design, and software engineering roles want to evaluate what a candidate can DO, not just what they SAY. There are many ways to do this, but it’s important for both candidates and hiring managers to understand and use the right approach for each.
The most common options we see at BravePath are:
- Take-Home Assignment: create a work product in? about one week, then submit it for offline evaluation or live presentation / Q&A
- Live Working Session: create a work product in about 30-60 minutes, either alone followed by Q&A, or through real-time whiteboarding
- Previous Work Review: submit previously completed work for offline review or live presentation / Q&A
Some options are more common for certain roles — like take-home assignments for product managers or previous work (portfolio) presentations for designers — but there is one universal principle to consider in a job market this hot. The more friction you add to the interview process, the more candidates you will miss out on. That’s why it’s so important to be thoughtful about which option you choose …
Take-Home Assignment
Most common for product managers and software engineers, this option requires the candidate to complete a custom work product in their “free time,” either for offline evaluation or for presentation and Q&A. Because this requires the biggest time commitment, it always creates the most friction in the hiring process. This will guarantee that you lose out on qualified candidates — especially top talent with options — who are unwilling or unable to commit the time. You should really really hate your other options to use this one.?
- Don’t ask for solutions to world hunger. You shouldn’t need to evaluate every skill. Focus on what is most important, and explore others in Q&A.?
- Recalibrate the time investment. In a recent audit, our team found candidates spent at least 2X the time suggested by the hiring manager (and the “gold standard” candidate spent 6X). This creates a dangerous and artificial calibration point that will consistently produce false negatives.
- Don’t make the assignment specific to your company. This looks like a request for “free consulting” and — more importantly — unfairly disadvantages the candidate. Evaluations will be more accurate using a topic interviewers are equally unfamiliar with.?
- Make this a late-stage interview. Make sure a candidate is interested in the role and has had an opportunity to ask their own questions before asking them to invest this much time.?
- Be realistic. Say how many days you will need only after you’ve seen the instructions. Then time box your effort.?
- Don’t sleep on the Q&A. Many of our clients see as much value in the Q&A (if there is one) as they do in the original assignment.
- Document your assumptions. Most employers are looking for insights into how your brain works more than a “right answer.”
Live Working Session
Live working sessions are most common for product managers and software engineers, but could also be used for designers. Similar to the take-home assignment in many ways, this option takes far less time. The interviewer describes an assignment, then either leaves the candidate to work alone for ~30-60 minutes before coming back for Q&A, or stays for collaborative whiteboarding. This option drives fewer candidate opt-outs because it requires no personal time, and is our strong recommendation at BravePath over the take-home assignment.
- Creatively de-scope. It’s easy to ask too much. If you need to test for both breadth and depth, consider something like “Identify at least four areas of work. Identify the most critical one. Explain your choice and flesh out solution(s) for that area.”?
- Calibrate appropriately. Account for the time constraint, emphasize the Q&A, and have current team members try it to calibrate and build empathy.
- Respect personality diversity. Some talented people don’t think well on their feet. If a real-time whiteboarding doesn’t accurately reflect the work environment, consider the version with personal work time.
- Ask if it’s possible to prepare. Ask if any preparation will be beneficial before you spend all night cramming for something unnecessarily.?
- Ask for feedback. A few quick “What do you think?” exchanges show a collaborative approach and may allow you to address concerns immediately.??
- Show a growth mindset. Don’t let a single mistake take you down. Changing direction based on feedback, and/or building on ideas from the interviewers are great ways to impress.?
Previous Work Review
Most job interviews require talking about previous work, but some hiring managers want to see the actual work product in context. This is most common for designers (portfolio review) and software engineers (public code repository). This could be an early-stage offline review of a link on a resume, or a later-stage live presentation covering a specific set of questions.? This option will typically require the least preparation for candidates, but unless customized, could be hit-or-miss for hiring manager needs.?
- Respect sensitive work and have a backup plan. Some candidates a) work on products they cannot share with you and/or b) are passive and haven’t updated their work samples in X years. Think twice about completely ignoring these candidates and be ready with a backup plan.?
- Mind the friction. Weigh the need for something unique — which will alway cause friction — against the need to not miss out on top talent.?
- Time-shifting effort. A burst of energy to create something this summer could pay big dividends in January when you’re ready to consider new roles but don’t have time for extra work in the interview process.
- Fill in the gaps. If you are short on experience, consider doing side projects that demonstrate skills and work product required for the role you want.?
Final Thoughts for Any Format
- Set clear expectations. Tell candidates what the exercise is designed to help you learn, where candidates tend to succeed or fail, if it’s possible to prepare or not, etc.?
- Be flexible, but equitable. It’s important to evaluate all candidates on the same criteria, but consider doing that with different techniques under different circumstances.?
- Give detailed feedback. PLEASE thank candidates for their time and give them detailed feedback proportional to the time they invested, even — and especially — if you think they bombed the interview.?
- Consider recording. Recording the presentation and/or Q&A (if there is one) can help compare candidates or allow absent interview panelists see the candidate in action.??
- Take one step at a time. Decide what you’re willing to do one step of the interview process at a time. You may not be motivated to complete a “take-home exercise” when you first hear about a role, but after meeting the hiring manager and deciding this is your dream job, you may feel differently.?
- If you can’t read the room, ask. Reading a room (Zoom?) of people you just met during exercises like this is a super valuable skill. Even if you have the skill, but especially if you don’t, keep your answers short while offering more detail if required and ask for feedback on what they would like to hear most instead of assuming.
My team and I recruit and coach product managers, designers and software engineers of all levels for a living, and we’ve seen these tips make or break many opportunities. I hope this helped you think about how you will approach the interview process the next time you find yourself on either side of the table.?
Have any questions? Agree or disagree with me? Add your thoughts in the comments or email me to discuss!?
Product & Design Leader ? SaaS, DTC, Marketplaces ? HR Tech, Healthcare, more
2 年And there could even be a hybrid of the Live Working Session and Previous Work Review. Start with the Work Review (great for introverts, testing presentation skills) but actively use it as a launching off point into a Working Session (for the more extroverted, think-on-the-feet type). Change one of the core assumptions of the previous work and see how that changes the choices and approaches. Introduce a new made-up finding after user research or initial testing. Add a significant implementation or technical snag.