How I'd think through reducing job-search friction for India's 10M annual graduates
How I'm approaching this
I'm walking through this the way I would in a product design interview — out loud, showing my reasoning at each step. I'll start by scoping the problem, pick the user I'm solving for and why, generate a wide brainstorm before cutting it down, pick one north-star metric and defend it, and then explicitly call out what I'm leaving on the table. The goal isn't a perfect answer — it's a clear reasoning chain.
Step 1 of 8
Before I jump in, I'd ask a few clarifying questions to make sure I'm solving the right problem.
Q: Is this an acquisition problem or an engagement problem?
→ Engagement. Freshers know LinkedIn exists. The friction isn't getting them onto the platform — it's what happens once they're searching for jobs. I'm scoping to the job-search experience specifically, not profile discovery or recruiter reach.
Q: Are we optimising for freshers finding jobs faster, or for LinkedIn's business?
→ Both, and they're aligned. A fresher who gets a job through LinkedIn becomes an employed professional — LinkedIn's core power user. The acquisition cost of a life-long user is effectively zero if the platform earns trust at the first-job stage. This is a long-term LTV play, not just a UX fix.
Q: Which market am I designing for primarily?
→ India, but the pattern is global. India has the highest density of this problem — 10M graduates/year, WhatsApp-native job search culture, high LinkedIn penetration among students, and the Naukri benchmark showing there's a clear market for fresher-specific job experiences. I'll design for India with global generalisability in mind.
Q: What's in scope?
→ Job discovery and filtering experience for users with 0–1 year of experience. Out of scope: profile optimisation features, recruiter-side products, LinkedIn Learning tie-ins. I may reference them as future v2 work.
Step 2 of 8
I wouldn't just say “freshers.” I'd segment first, then pick one segment to anchor the solution on.
Tier 1 CS grad
IIT/NIT graduate, strong projects, high network
Friction: Low
Already gets recruiter inbound. LinkedIn works reasonably well for them.
Tier 2/3 grad
PrimaryB.Tech from state university, solid skills, no network
Friction: Very High
Has to find every opportunity outbound. The filter problem hits them hardest.
Non-tech fresher
Commerce/arts grad looking for marketing, ops, analyst roles
Friction: High
Even fewer fresher-friendly filters in their domain. But a harder design problem — I'd address after tech freshers.
The user I'm designing for
Priya — B.Tech CSE 2024, Tier-2 college, Hyderabad
Opens LinkedIn every morning. Spends 2–3 hours searching. Applies to 5–8 jobs. Gets called back by 0–1.
“I spend more time figuring out if I can apply than actually applying. Most of what I see isn't for me — but I don't know that until I'm halfway through the job description.”
Her current job-search journey
Search 'Software Engineer'
2,000+ results
Filter: Entry Level
Still 800+ — filter is broken
Open posting #1
'2 years required'
Open postings #2–#8
Same pattern, every time
Find one relevant posting
1 in 9. Applies.
Repeat tomorrow
No system improvement
Step 3 of 8
I wouldn't jump to solutions yet. I'd form a hypothesis about the root problem first — because the solution shape is very different depending on which one is true.
H1: The 'Entry Level' filter is a false signal
Primary35–40% of jobs tagged 'Entry Level' on LinkedIn require 2+ years of experience. Recruiters aren't lying — they just use the field inconsistently. The filter gives freshers false confidence and wastes more time than no filter at all.
H2: Freshers lack confidence, not information
Secondary~72% of freshers self-filter out of roles they're actually eligible for. The JD language ('preferred: 2 years') reads as a hard requirement even when it isn't. This is a signal design problem — the product doesn't tell users what's a requirement vs what's a preference.
H3: LinkedIn's graph isn't being used for freshers
OpportunityLinkedIn's unique advantage is the professional graph — alumni data, company hiring patterns, career paths. None of this is surfaced for freshers. Naukri doesn't have this data. This is an opportunity, not just a problem.
H4: This is a recruiter behaviour problem, not a product problem
RejectedIf recruiters filled in the experience field correctly, the existing filter would work. But I'm not betting on changing recruiter behaviour without a product forcing function — they have no incentive to tag carefully. The product has to compensate.
What I'd test before building
I'd pull a sample of 500 “Entry Level” LinkedIn jobs in India and manually score them against experience requirements. If H1 is confirmed at >30% false-positives, the fix is a product-layer signal, not recruiter education. I'd also run 10 user interviews specifically probing for whether the confidence gap (H2) is real or rationalised.
Step 4 of 8
Before I cut, I'd generate broadly. Here are 8 ideas — ranging from obvious to unconventional. I'm not filtering yet.
Fresher Mode toggle
A persistent filter toggle in job search that combines structured experience fields + NLP signals to surface only 0–1yr roles.
Highest impact per unit of effort. Directly addresses the core friction — filtering before the user opens anything. Doesn't require recruiter behaviour change to work.
Fresher-Friendly badge on job cards
ML-powered badge visible in search results before opening a posting, so users can scan without clicking.
Eliminates the per-posting read-to-qualify loop. Works even without Fresher Mode active. Builds trust in the filter system over time.
Dedicated 'Fresh Start' job hub
A separate tab or section for campus roles, new-grad programs, and alumni-referred entry-level openings.
Leverages LinkedIn's unique asset — the professional graph — for freshers. Alumni connections are a higher-quality signal than any keyword filter.
Experience mismatch signal before applying
A soft warning before submission: 'This role typically looks for X years. Similar profiles still apply — here's the data.'
Solves the confidence gap without gatekeeping. 72% of eligible freshers self-filter; honest data flips that.
Fresher profile amplifier
Guided setup flow to frame projects, coursework, and certifications as work-equivalent experience.
Important but it's a supply-side fix (making the fresher more visible to recruiters). The core problem is demand-side friction (freshers finding relevant roles). I'd build this in v2 after the search experience is fixed.
Job alert with 'Fresher verified' pre-filter
Email/push alerts that only fire when a new role passes the fresher-signal threshold.
Good retention feature but doesn't solve the in-session discovery problem. Also depends on having the NLP model first. Natural v1.5 addition.
Employer 'Open to freshers' recruitment badge
A company-level certification on the LinkedIn company page showing hiring history of freshers.
High-value signal but requires significant recruiter-side adoption work. Wrong bet for v1 — build demand-side trust first, then pull recruiters in.
AI assistant that evaluates fit and drafts message
'You're 70% fit for this role. Here's what to highlight in your application.' AI-drafted outreach message.
Scope creep. Solving for fit communication before solving for finding the right role is putting the cart before the horse. Also, LinkedIn already has AI features here.
Moving forward with
Parked for later
Step 5 of 8
I have 4 ideas I want to build. I still need to decide what's P0 (launch together), P1 (sprint 2), and what waits for validation.
| Feature | Impact on north star | Effort | Dependencies | Priority |
|---|---|---|---|---|
| Fresher Mode Toggle | High — directly filters irrelevant results | Medium | NLP model | P0 |
| Fresher-Friendly Badge | High — eliminates per-card manual read | Medium | Same NLP model as above | P0 |
| Experience Mismatch Signal | Medium — confidence gap fix | Low | None — structured field only | P0 |
| Fresh Start Hub | Medium-High — LinkedIn graph leverage | High | Alumni data pipeline | P1 |
Why Toggle + Badge ship together
The Toggle and Badge share the same NLP model — the infrastructure cost is incurred once. If I ship the Toggle without the Badge, the filter works but search results still look identical. If I ship the Badge without the Toggle, users get signal on individual cards but still have to scroll past irrelevant ones. Together, they solve the problem end-to-end. Shipping separately would halve the impact without halving the effort.
Step 6 of 8
Spec for the 4 features I'd ship, in priority order. Click each to see the design decisions.
A persistent toggle in the Jobs search bar that activates an ML-powered filter: experience_years ≤ 1 in the structured field + NLP detection of fresher-signal phrases in JD text + recruiter-set opt-in flag. Non-qualifying jobs are dimmed (not hidden) when active — transparency over suppression. Persists across sessions in user settings.
User Story
As a fresher, I want one toggle that filters to jobs genuinely open to me, so I stop manually reading 40 job descriptions to find 4 relevant ones.
Acceptance Criteria
Step 7 of 8
I'd resist reporting a dashboard of 6 metrics. The discipline is picking ONE that best captures whether the problem is solved — and being honest about the trade-off.
North Star Metric
Qualified applications per search session — fresher cohort
A “qualified application” = applied to a role where experience requirement ≤ 1yr. This directly measures whether the fresher found relevant roles and had the confidence to act. Target: move from the current estimated 1–2 per session to 3–4.
Why I rejected the obvious alternatives:
Total applications submitted
Can go up while match quality drops. A fresher applying to 20 clearly wrong roles looks like a win in this metric. It measures volume, not signal quality.
DAU among 0–2yr experience users
Freshers with high job-search intent already have high DAU — frustration and all. Improving DAU without improving outcomes would be a hollow metric win.
Job-to-hire conversion rate
I don't control post-application outcome. Recruiter quality, market conditions, and interview performance are all out of scope. Don't measure things you can't influence.
Time spent in Jobs section
Engagement time going down is actually success if I reduce the time wasted on irrelevant postings. A 'reduce time' improvement would look bad in an engagement metric.
Step 8 of 8
Good PM thinking isn't just about what you build — it's about what you decide NOT to build and why. Here are my four explicit trade-offs.
Fresher Mode dims irrelevant results, it doesn't remove them. If I hide them, I create a two-tier job market where freshers lose access to stretch opportunities and recruiters eventually have a 'fresher-only' posting strategy that ghettoises entry-level roles. The toggle is a signal layer, not a fence.
The tension I'm accepting
This means the mode feels less 'clean' than a full filter. That's a deliberate trade-off for long-term equity.
Profile visibility is a supply-side fix — it helps recruiters find freshers. But the core problem is demand-side: freshers can't find relevant roles. Fixing supply without fixing demand means a better-seen candidate who still hits the same search-friction wall. Sequence matters.
The tension I'm accepting
Freshers often ask for profile help. This will feel like a gap in v1. I'd communicate the roadmap clearly.
Recruiters don't fill in experience fields accurately. I could build a 'suggest experience level' nudge into the posting flow — but recruiter adoption is slow and I don't control that surface in this initiative. The NLP model compensates for recruiter inconsistency without requiring behaviour change.
The tension I'm accepting
Long-term, recruiter data quality is the right fix. But I'd rather ship a working product in 6 weeks than a perfect product in 18.
I'd launch the Badge only to NLP confidence ≥80% predictions from day one — so there's no 'without badge' control group in production. The risk of shipping a low-precision badge (and destroying trust) outweighs the experimental rigour of a clean A/B. I'd measure badge click-through and downstream apply rate as a proxy for model quality.
The tension I'm accepting
This means I can't cleanly attribute apply-rate lift to the Badge vs the Toggle. I'd use holdout cohorts by college cohort rather than individual randomisation.