Technical Take-Home Assignments: How Indian Product Companies Actually Evaluate Them

Most candidates treat a take-home assignment as a coding test with extra time. It isn't. It's a judgment exercise — and the way you scope, document, and present your work tells the interviewer far more than whether your code compiles.

Product-first companies at the mid-to-top tier of the Indian market — Swiggy, Razorpay, CRED, Groww, Zepto, Meesho, Juspay, Zerodha, and most well-funded startups — now use take-home assignments for at least one round. Service companies rarely do. If you're targeting product-first roles, either on-campus or off, you will face one.

This post covers what evaluators actually look for, a phase-by-phase approach to doing the work, fully written examples for three role types, a before/after on documentation, and the mistakes that consistently kill strong candidates.

What they're actually testing

A coding assessment on HackerRank tests whether you know algorithms under time pressure. A take-home tests something different: can you build a real piece of software — or analysis, or strategy — without supervision, and can you make sensible decisions when the brief is under-specified?

Three things dominate the evaluation scorecard.

Decision quality over implementation. The senior engineer reviewing your submission is not primarily impressed by technical sophistication. They want to understand: given the gaps in the brief, what did you choose to build, what did you leave out, and why? A straightforward implementation with a clear explanation of trade-offs often scores higher than a polished codebase with no reasoning attached. Reviewers have seen thousands of submissions; they haven't seen your thinking before.

Scope discipline. Under-specified briefs are deliberate. Companies specifically leave them vague to see whether candidates will scope the problem reasonably or spiral into over-engineering. A candidate who submits a fully production-grade microservices architecture for a two-day assignment signals that they don't yet have the judgment to work under real business constraints. Shipping the right 20% on time is a skill. So is knowing what the right 20% is.

Honest communication of limitations. Engineers who present incomplete work as complete are harder to work with than those who clearly name what they left out and why. A section called "What I'd do with more time" is not a concession of weakness — it demonstrates that you can distinguish between what was appropriate for a two-day exercise and what a production system would require. Every experienced engineer on the review panel has made that same distinction under real deadlines.

The three phases that determine your score

Phase 1: Scope before you build

Read the brief twice before writing a single line of code. Then write down three things:

• The core requirement (what absolutely must work for the submission to be taken seriously)
• The nice-to-haves (features that would add signal but are not load-bearing)
• What you are explicitly not doing, and why

This list becomes the opening section of your README and the opening two minutes of your presentation slot. It immediately communicates to the reviewer that you have product judgment — you understand that trade-offs exist and that consciously choosing not to build something is often as important as choosing to build it.

Most candidates skip this step and dive straight into coding. This is the phase that separates the top 20% of submissions from everyone else, and it takes 30 minutes.

Phase 2: Build to a standard you can defend

Whatever you build, make sure you can walk through every significant decision in an interview 48 hours later. The most common failure: a candidate builds something that works, does not fully understand why it works, and then gets exposed when the interviewer asks "why did you use X instead of Y?"

For SDE assignments: Tests signal more than extra features. A submission with meaningful test coverage and three working features will typically score higher than one with six features and no tests — because test coverage shows you understand that correctness is non-negotiable in production software. Write at least happy-path tests and one negative-case test per core function.

For data assignments: Reproducibility matters most. Your analysis should run end-to-end from a single command or notebook, with data sources clearly documented. An interviewer who cannot reproduce your results cannot evaluate them. If you used a cleaned version of the data, include both the cleaning script and the rationale for every cleaning decision.

For PM and APM assignments: The reasoning behind your recommendation matters more than the recommendation itself. Show your logic: what user problem you started from, what data informed your prioritisation (app store reviews, support ticket themes, public metrics), what alternatives you considered and discarded, and why your proposed solution is the right bet given the stated constraints. A two-page document with clear reasoning outperforms a ten-page document that buries the logic under diagrams.

Phase 3: Document and present like a professional

Your README is a first-class deliverable, not an afterthought. Every submission needs at minimum:

1. Setup instructions — how to run the project from a clean environment in under five minutes
2. Design decisions — three to five choices you made and the reasoning behind each
3. What's out of scope — what you deliberately left out and what a production version would include
4. Where to look first — if the reviewer has 15 minutes, what should they start with?

The presentation slot (usually 20–30 minutes) follows the same structure. Open by restating your understanding of the problem and your scoping decisions. Then demo the core functionality. Close with limitations and what the next iteration would look like. An interviewer who doesn't hear your scoping decisions before they see your demo cannot evaluate it properly — they have no frame for why you built what you built.

Worked examples by role

SDE: building a URL shortening API

A common brief: "Build a URL shortening service. Users should be able to shorten a URL and retrieve the original. There's no UI requirement."

Strong submission framing (opening of README):

"What I built: A REST API with two endpoints — POST /shorten and GET /:code for redirect.

Scope decisions: I chose SQLite as the storage layer to eliminate setup dependencies. A production version would use PostgreSQL for persistence under load, with Redis in front for high-read caching. I added per-IP rate limiting at 10 requests/minute — a URL shortener without rate limiting is trivially abused as a spam relay. I did not implement click analytics or URL expiry — these are the obvious next features but would have pushed the project significantly beyond a two-day scope.

Design choice: I used base62 encoding rather than MD5 hashing. MD5 generates a 32-character hash you then truncate, which introduces collision risk. Base62 encoding of an auto-incrementing ID is shorter, human-readable, and collision-free at any scale that would use SQLite anyway.

Tests: Run with pytest tests/. Coverage includes: happy path, duplicate URL handling (same URL → same code), retrieval of an invalid code (404), and rate-limit enforcement."

Notice what this framing does: it shows production awareness (rate limiting, collision risk), makes an explicit trade-off (SQLite now vs PostgreSQL later), names the missing features and why they're missing, and explains the test coverage. The interviewer knows all of this before they read a single line of code.

When they ask "why SQLite?" you have a real answer ready: it eliminates a setup step for the reviewer, and you've already acknowledged that it wouldn't survive production. That's a much better position than scrambling to justify a default choice you never consciously made.

---

Data: churn analysis on e-commerce transaction data

A common brief: "Here is six months of customer transaction data. Give us your analysis."

Strong submission framing (opening of notebook or README):

"Problem definition: I defined churn as a customer who made at least two purchases in their first 30 days but made no purchase in the subsequent 60 days. I chose this definition over a simpler 'no purchase in 90 days' threshold because the data shows a bimodal pattern — one-time buyers behave very differently from repeat customers, and conflating the two groups would obscure the actual churn drivers.

Model: I used gradient boosting (XGBoost) — 79% precision, 74% recall on a 20% holdout set. The top three predictors were: recency of last purchase, gap between first and second purchase, and average order value trend (rising vs declining). I deliberately skipped deep learning — the dataset is 12,000 rows, not enough for a neural architecture to outperform a well-tuned ensemble.

The finding that matters: 62% of churn is concentrated in the first 30 days after the second purchase. This isn't a modelling finding — it's visible in the raw cohort data before any model. A reactivation email targeting customers at day 25 after their second purchase would capture the highest-risk group with the smallest intervention.

Next step I'd recommend: A/B test a reactivation email for the top 1,000 at-risk customers and measure 30-day lift before building any further model complexity."

The phrase "A/B test a reactivation email" is what separates a data analyst answer from a data scientist answer. It shows you think in decisions and experiments, not just model accuracy. Most fresher candidates stop at the confusion matrix. The ones who get offers name what decision their analysis drives.

---

PM/APM: prioritising features for a payments app

A common brief: "Here are 10 requested features for our payments product. Pick your top 3 and explain your prioritisation."

Strong submission framing:

"My framework: I scored each feature on two dimensions — estimated retention impact (based on app store reviews and publicly available UPI adoption data) and estimated implementation complexity (rough LOE, informed by a conversation with a friend in payments engineering for a sanity check). I ranked by impact/effort ratio, then applied a strategic filter: does this feature help us win on the axis that matters most in the next 6 months?

Top 3 recommendation:

1. UPI transaction history with categories — 70% of negative reviews mention 'can't track spending'. High impact, moderate complexity.
2. One-tap retry on failed payments — Failed payments are the #1 drop-off. A one-tap retry that pre-fills all fields is low complexity and addresses the highest-frequency frustration.
3. Split bill request via UPI link — Low complexity, drives both acquisition (shareable links) and engagement (repeat use case).

What I deprioritised and why: Feature 6 (credit integration) has the highest potential impact but requires regulatory approvals and a lending partner — realistic timeline is 8–12 months. It belongs on the roadmap but not in the next sprint. Feature 9 (loyalty rewards) has strong demand but creates a cost structure that isn't sustainable without a monetisation model we don't have yet."

The explicit deprioritisation — naming what you chose not to do and why — is what most PM candidates skip. An interviewer reading this knows you understand execution risk, regulatory constraint, and unit economics. Those are the PM instincts they're hiring for.

Before/after: the same submission, two very different impressions

Weak README:

"This project implements a URL shortener. Supports creating and retrieving URLs. Built with Python and Flask. To run: pip install flask then python app.py"

Strong README:

"A URL shortening API — Flask + SQLite.

To run: pip install -r requirements.txt && python app.py — starts on port 8080. No external services needed.

Scope decisions: Core flow (shorten + redirect) is complete. Added per-IP rate limiting (10 req/min) and a 404 handler for expired/invalid codes. Click analytics and a management UI are out of scope — next obvious features, but would take the project well past two days.

Design: Used base62 encoding of an auto-incremented ID rather than hashed URLs — shorter codes, no collision risk, easier to debug. SQLite for storage: no setup friction for reviewers, not appropriate for production scale.

Tests: pytest tests/ — happy path, duplicate URL handling, invalid code (404), rate-limit enforcement.

Start here: app.py for the API logic, tests/test_app.py to see the coverage."

Both submissions represent the same working project. The strong README takes an extra 20 minutes to write. It roughly doubles the reviewer's confidence in the candidate. Most candidates write the weak one.

Common mistakes

Mistake 1: Treating scope as an open invitation. The brief is under-specified on purpose. Candidates who build everything imaginable — authentication, admin panel, analytics, webhooks, export functionality — within two days often score lower than those who built three things cleanly and explained why they stopped there. Scope creep on a take-home signals you haven't yet learned to work in a business environment where judgment about what not to build is a daily requirement.

Mistake 2: No documentation, or documentation that's just setup steps. Reviewers read your README before they run your code. A bare python app.py tells them nothing about you. Your reasoning for the choices you made is the most valuable deliverable in the package — do not leave it out. If your README doesn't have a "Design decisions" section, add one before you submit.

Mistake 3: Submitting code you can't fully explain. This ends take-home presentation slots early and badly. If you used a library or a pattern because you found it on Stack Overflow without understanding it, you will not survive "why did you use this approach?" Choose a solution you understand end to end, even if a more sophisticated one exists. A simple, defensible solution that you can walk through confidently outperforms a polished solution you can't explain.

Mistake 4: Opening the presentation with the demo. The most consistent structural mistake in the presentation slot. Start with your understanding of the problem and your scoping decisions — then show what you built. Forty-five seconds of framing changes how the reviewer processes everything they're about to see. Walking them through a demo cold, before they know what you were trying to accomplish, means they're scoring your work against their own unstated assumptions rather than against your stated scope.

What to do this week

Find one publicly available take-home brief — GitHub has hundreds tagged "take-home", "case study", or "technical assignment" in repos named interview-prep or similar — or invent one for a product you use daily. Set a 48-hour clock and treat it exactly as a real submission.

At the end of those 48 hours, write your README before you review your code. This order matters: if you can't describe your design decisions from memory, you didn't make them consciously. Rewrite the README until every decision has a reason and every out-of-scope choice is named.

Then do a ten-minute presentation to a friend or roommate: problem, scoping decisions, demo, limitations, next steps. If they can summarise the core trade-off you made without prompting, your communication is clear enough for an actual interview room.

One well-executed practice submission — with documentation you're proud of and a presentation you've run twice — is more useful than reading ten guides about take-home strategy.

---

If you're preparing for a take-home in the next few weeks, CareerClutch's mock interview tool includes a take-home review mode where you submit a project and get structured feedback on scope, documentation, and the follow-up interview. The most common feedback we give: the work was strong, but the README didn't show any of it.