Getting the offer is the hard part — or so it seems. But I have watched dozens of engineers who passed brutal technical interviews stumble badly in their first 90 days, and I have watched others who barely squeaked through become the engineer their manager references when people ask "who should I talk to?" The difference is rarely technical. It is almost always behavioural.

The first 90 days of a new engineering role are disproportionately important. Research consistently shows that the reputation you build in your first three months as a new employee shapes how people perceive you for years. At product companies where speed of iteration matters, the first 90 days set the tone for your entire tenure.

This guide is specific to Indian product companies and startups — the culture, expectations, and politics are meaningfully different from what western management guides assume.

What We Cover

  1. Week 1: Listen, learn, and map the system
  2. Month 1: Ship your first impact
  3. Month 3: Establish your working style
  4. Navigating people: manager, tech lead, team
  5. Common mistakes that derail new engineers
  6. India-specific workplace dynamics to understand
  7. How to set yourself up well for your first performance review
90
Days to establish your reputation — research shows first impressions last 2+ years
30%
New engineers who do not complete their first year at Indian product companies
Week 3
Ideal target for shipping your first code to production
5×
Faster way to build trust: asking smart questions vs. saying nothing for fear of looking ignorant

Week 1: Listen, Learn, and Map the System

The most common mistake new engineers make in week 1 is trying to show how smart they are. The second most common mistake is staying quiet for fear of showing they do not know something. Both are wrong. Week 1 is about building your map — understanding the system you have joined.

Week 1 Checklist

Set up your dev environment and run the codebase locally. This sounds obvious but often takes 2–3 days at a large codebase. Do not skip it — debugging a broken local setup yourself teaches you more about the system than reading 10 wikis.
Read every open PR and every merged PR from the last 2 weeks. This tells you what the team is working on, what the code review culture is like, and who the most active reviewers are.
Ask your manager for a 30-minute 1:1 on day 2 or 3. In this meeting, ask: "What would a great first 30 days look like? What's the one thing new engineers most often miss when they join?" Most managers will tell you exactly what you need to know.
Map the system architecture. Spend 2–3 hours going through the codebase and any available architecture diagrams. Draw your own simple diagram of how the services interact. Ask your tech lead to correct it. This single exercise will teach you more than a week of reading documentation.
Identify the "go-to" people on the team. Every team has 2–3 people who know where everything is. Find them, introduce yourself, and ask if you can reach out with questions. Most engineers are happy to help someone new who shows genuine curiosity.
Fix a small bug on day 4 or 5. Even a documentation fix or a typo in a comment counts. Getting one commit through the full workflow (write code → open PR → address review → merge) before week 1 ends tells your team you are already productive and removes friction from future PRs.
The Question Journal Keep a running document of questions you have as you explore the codebase and systems. Do not ask every question immediately — batch them. Send a message to your tech lead or buddy every 1–2 days: "I had a few questions from exploring the code today — do you have 15 minutes sometime?" This is more respectful of their time and shows you are thoughtful, not impulsive.

Month 1: Ship Your First Impact

By the end of month 1, you want one thing: something meaningful in production with your name on it. It does not need to be a large feature — it can be a performance improvement, a bug fix that had real user impact, or a tooling improvement that makes other engineers' lives easier. The act of shipping something real sends a stronger signal than any amount of onboarding conversations.

Month 1 Checklist

Claim your first meaningful ticket by day 8–10. Do not wait to be assigned. Look at the backlog, find a ticket that is well-defined (not "redesign the entire auth system"), and ask your manager if you can pick it up. Taking initiative this early is noticed.
Over-communicate on your first task. Send a Slack message when you start: "Starting on [ticket] today — will share a PR for review by [date]." Update when blocked. Send the PR with a clear description of what changes, why, and how to test. This sets a great precedent.
Respond to all code review comments within 24 hours. Review cycles that drag show you do not prioritise the process. Even if you are working on other things, address review comments as soon as they come in. This signals professionalism and earns you faster reviews in return.
Write tests for your first task. Even if the existing code has poor test coverage, add tests to everything you touch. This signals engineering standards and protects you from being blamed for future regressions.
Have a 1:1 with your manager at the end of week 3. Ask: "What feedback do you have from my first few weeks? Is there anything I should be doing differently?" This shows maturity and gives you course-correction before bad habits set in.
Understand the on-call or incident process. Know who gets paged when something breaks, how incidents are handled, and what your responsibility is. Ask if you can shadow the next on-call rotation even if you are not on it yet.

Month 3: Establish Your Working Style

By month 3, the "new engineer" grace period is effectively over. Your team now has a clear picture of how you work. The goal of month 3 is to close the gap between "new engineer who is learning" and "engineer the team relies on."

Month 3 Checklist

Own your first feature end-to-end. This means taking a feature from the spec to production — writing the design doc (if the team uses them), breaking it into tasks, implementing, writing tests, coordinating the rollout, and monitoring production metrics afterward. This is the clearest signal of engineering maturity.
Start reviewing other engineers' PRs. Do not wait until you feel like an expert. Even if your comments are mostly questions ("What's the reason we use X here instead of Y?"), you are contributing to the review culture and learning faster. Engineers who give good reviews consistently get promoted faster.
Document something that was not documented. Every team has tribal knowledge — things everyone knows but nobody wrote down. Identify one thing (a deployment process, a gotcha in the codebase, a runbook step) and write it down. Share it with the team. This is low-effort but very high-visibility.
Build your peer relationships. Have at least one 1:1 coffee (virtual or in-person) with each person on your immediate team. Ask what they are working on, what they find challenging, and what they wish they had known when they joined. This builds genuine relationships, not just professional acquaintance.
Propose one improvement. By month 3 you have enough context to identify something that could be better — a flaky test suite, a deployment that takes too long, a missing monitoring alert. Write a 1-page proposal and share it with your tech lead. You do not need to fix it — proposing it signals that you think like an owner, not just an executor.

Navigating People: Manager, Tech Lead, Team

The technical part of your first 90 days is the easier part. The harder part is navigating the team dynamics. Here is what I tell every Prepflix student starting a new role:

Your manager is your most important relationship. Managers at Indian product companies are often overloaded — they are managing 5–8 engineers while also doing IC (Individual Contributor) work. The engineers who get the most manager attention are usually those who either create the most problems or communicate proactively and make the manager's job easier. Be the second type. Give your manager a brief Slack update at the end of every week: "Shipped X, started on Y, blocked on Z — escalating to [person] tomorrow." This takes 2 minutes and gives your manager what they need for their own status updates.

Your tech lead is your learning multiplier. The tech lead is the person who can most accelerate your learning — they know the codebase deeply, they understand the product history, and they are the gatekeeper for code quality on the team. Build this relationship with genuine curiosity rather than flattery. Ask for code reviews even on small things. Ask: "Can I walk you through my design thinking before I start implementing?" A good tech lead will correct your approach and you will ship better code. A great tech lead will teach you why.

Your peers are your long-term network. The engineers on your team today will be your references, your co-founders, your referrals, and your friends for the next 10 years. Invest in these relationships early and authentically. The engineers who only transact — only talk to colleagues when they need something — are visible and are not well-regarded.

Common Mistakes That Derail New Engineers

Mistake Why It Happens What to Do Instead
Staying silent when blocked for more than a day Fear of looking incompetent; not wanting to bother senior engineers After 4–6 hours of trying yourself, ask for help. State exactly what you tried, what you expected, and what happened. Good engineers appreciate focused questions.
Over-engineering the first task Wanting to impress; not understanding the priority of shipping speed Solve the minimum problem. Ship it. Get feedback. Iterate. A simple solution in production beats an elegant solution in a PR for 3 weeks.
Comparing your speed to veterans Anxiety about being "good enough" A 5-year engineer who knows the codebase takes 2 hours on a task that takes you 2 days. That is normal. Compare yourself to yourself 30 days ago.
Not asking why Assuming existing patterns are always correct Ask why technical decisions were made. "Why do we use X here instead of Y?" is almost always a welcome question. You either learn something or surface a technical debt opportunity.
Working in isolation instead of asking for feedback Not wanting to show incomplete work Share early drafts: "I'm thinking about approaching this like X — does that make sense before I start implementing?" Early feedback saves days of rework.
Focusing on looking busy rather than being effective Insecurity; wanting to signal effort No one cares how many Slack messages you sent. They care about whether your code shipped and worked. Ship something real. That is the only measure that matters.

India-Specific Workplace Dynamics to Understand

Working at an Indian product company or startup has some cultural dynamics that are worth understanding explicitly:

Hierarchy is real but not always visible. Indian engineering teams are more hierarchical than what many western startup guides assume. Your senior engineers and tech lead's opinions carry significant weight — even when the culture presents itself as flat. Early in your tenure, agree in public and disagree privately with data. Once you have built credibility, your disagreements will carry more weight.

Your manager's manager matters. In many Indian product companies, skip-level relationships are important. Pay attention to how your manager's manager behaves, what they value, and how they run meetings. You do not need to manage up aggressively — but being visible and respected at that level can meaningfully affect your performance rating and promotion trajectory.

Team lunches and informal channels are important. Relationships at Indian product companies are often cemented over lunch, chai, or after-hours conversations — not just in meetings. Participate in these. Do not eat alone at your desk for the first 30 days.

Documentation and process maturity varies wildly. At a 3-year-old startup, there may be no onboarding doc, no architecture diagram, and no runbooks. At a 10-year-old product company, there may be extensive docs that are all outdated. In either case, your ability to navigate ambiguity and self-direct is the actual competency being tested.

How to Set Yourself Up Well for Your First Performance Review

Most Indian product companies do performance reviews every 6 months. Your first review will happen approximately 3–6 months after you join — right at the edge of your foundational period. Here is how to ensure it goes well:

Track your impact from day 1. Keep a private document that lists every significant thing you ship, every bug you fix, every improvement you propose. Include metrics where possible: "Reduced API latency by 35%" or "Shipped the notification system that now serves 50K users." At review time, you want to be able to list 10 concrete things — not "I worked really hard."

Have explicit goals with your manager by the end of month 1. Ask your manager: "What specific outcomes would make you rate this first half-year as 'strong performance'?" Get this in writing (a Notion doc, a Jira ticket, even a Slack message). Review against these goals monthly. This gives you clarity and removes subjectivity from your review.

Ask for feedback before the review, not during it. The worst time to receive critical feedback is in a formal performance review — it is too late to act on it for that cycle. Ask your manager for informal feedback at month 2: "Is there anything I should be doing differently right now?" This gives you 4 months to course-correct before the review.

Build peer testimonials early. Many companies include peer feedback in performance reviews. The peers who give you the best testimonials are the ones you helped — the engineer you unblocked, the one whose PR you reviewed thoroughly, the one you helped debug an incident. Help people now and you will have advocates during your review.

The 30-60-90 Day Check-in Framework At day 30: tell your manager "Here is what I have done in my first month, here is what I plan for the next month, and here is where I need help." At day 60: same format but with more depth and evidence of impact. At day 90: "Here is what I have shipped, what I have learned, and here is my plan for the next quarter." Engineers who communicate this proactively never get surprised at review time — and neither do their managers.