Provide a Technical Task Prep Pack

Before the candidate starts the technical round, send them structured guidance based on whether it's a homework or live coding task.

📑 Technical Task Prep Pack Contents

Section	What to Include?	Why?
Task Overview	🔹 Problem statement & requirements 🔹 Expected time commitment 🔹 Format (homework vs. live coding)	Ensures they don’t misinterpret expectations.
What the Company Is Looking For	🔹 Key skills they will assess 🔹 How tradeoff thinking & decision-making will be evaluated 🔹 Emphasis on Shape Up/product mindset	Aligns their work with what really matters to the company.
Do’s & Don’ts for Success	✅ DO: Keep it simple, document decisions, prioritize MVP thinking ❌ DON’T: Over-engineer, add unnecessary complexity, ignore tradeoffs	Helps candidates avoid common mistakes.
Tradeoff Thinking Guidance	🔹 What constraints matter? 🔹 When to optimize vs. when to prioritize speed?	Ensures candidates approach problems like a product engineer.
How to Submit (If Homework)	🔹 Format required (GitHub repo, README, PDF, etc.) 🔹 Deadline & expected response time	Prevents logistical issues & delays.
Live Coding Tips (If Real-Time Task)	🔹 Speak out loud & engage the interviewer 🔹 Clarify assumptions before coding 🔹 Prioritize working solutions first	Ensures they showcase their problem-solving process, not just code quality.

💡 Optional: Include a short Loom video explaining best practices for Shape Up-aligned technical tasks.

💡 What is likely to be assessed?

Category	Question	✅ What a Good Response Looks Like	❌ Bad Response (Red Flag)	⚠️ Risk Factor to Mitigate
Overall Performance	How did the candidate perform in the technical task?	"They showed strong problem-solving skills and clear tradeoff thinking."	"They completed the task, but I’m not sure they fully understood the problem."	🚨 Lack of clarity in thinking—may struggle in real-world tasks.
Technical Strength	Did their solution meet the technical expectations?	"Yes, they wrote clean, well-structured code and explained it well."	"They solved the problem but didn’t document anything."	🚨 Poor documentation—hurts collaboration.
Tradeoff Thinking	Did they demonstrate strong decision-making and prioritization?	"They explained their decisions well and made pragmatic tradeoffs."	"They tried to do everything at once, without focusing on the core problem."	🚨 Over-engineering—misalignment with Shape Up mindset.
Communication & Documentation	If this was a homework task, was their README and explanation clear?	"Yes, I could pick up their code and understand their decisions easily."	"No, I had to ask them multiple clarifying questions to understand."	🚨 Fails to explain decisions—poor fit for async teams.
Thinking Out Loud (If Live Coding)	Did they articulate their thought process clearly?	"Yes, they walked through their approach before coding."	"They wrote code in silence, and we had to pull responses from them."	🚨 Silent coders struggle in collaborative teams.
Red Flags or Concerns	Would you be comfortable working with this person in your team?	"Yes, they demonstrated strong problem-solving and adaptability."	"I’m not sure—they struggled when challenged."	🚨 May not handle pressure well in a fast-moving environment.
Decision	Would you like to move them to the final interview?	✅ Yes, proceed ⏳ Needs further discussion ❌ No, stop process	"We’re unsure—we need to discuss internally."	🚨 Delays mean possible rejection—identify concerns fast.

Task-Specific Best Practices

📌 For Homework Tasks: Documentation is Critical

Since interviewers won’t be able to ask questions live, they will assess candidates based on how well they explain their approach in writing.

📌 Best Practices for Homework Tasks: ✅ Write a clear README:

Explain the problem statement (briefly).
List the key tradeoffs & decisions made (why they chose one approach over another).
Provide setup instructions (how to run the code).
Outline possible next steps (if they had more time, what would they improve?).

✅ Structure the code logically:

Use clear file organization.
Avoid unnecessary abstraction (too many classes/functions for a simple problem).
Comment only where necessary—let code readability do the work.