--- title: Your First 90 Days in a New Engineering Job description: A practical plan for your first 90 days in a new engineering job — what to do each month, how to ship early safely, and the mistakes that cost credibility. url: https://usegreenroom.app/blog/first-90-days-new-job last_updated: 2026-07-31 --- ← Back to blog Careers # Your first 90 days in a new engineering job July 31, 2026 · 12 min read ![First 90 days in a new engineering job guide — cover from Greenroom, the AI mock interviewer](/assets/blog/first-90-days-new-job-hero.webp) In week two he found it: a service doing three database round-trips where one would do. He rewrote it over a weekend and opened a 900-line pull request titled "perf: fix obvious N+1." The review had eleven comments. The first one, from the tech lead, just said: "This is deliberate — see the incident doc from March." Nearly everything that goes wrong in a new job goes wrong that way: competence applied before context. Your first 90 days in a new job are not about proving you were worth hiring — that decision is already made — they are about earning the right to change things. This guide covers what to do in each month, how to ship early safely, and the mistakes that cost people credibility they then spend a year rebuilding. ## What the first 90 days are actually for Three things, in this order: build context (how this system, team and company actually work), build trust (people believe you will do what you say), and deliver something real (small, visible, useful). Notice what is not on that list — being impressive. New joiners who try to demonstrate seniority immediately usually damage the trust they are trying to build, because a confident opinion offered without context reads as arrogance rather than expertise. The engineers who are most respected at month six are almost always the ones who asked the most questions at month one. ![First 90 days in a new engineering job diagram — month one learn and ship something small, month two contribute independently, month three own an area and propose improvements](/assets/blog/first-90-days-new-job-diagram.webp) The first 90 days: earn context before you spend credibility on changing things. ## Month 1: learn deliberately, ship something tiny The goal is context, plus one small shipped thing so you feel like a participant rather than an observer. - Ship on day one or two if you can. A typo fix, a doc correction, a flaky test. It teaches you the whole pipeline — branch, review, CI, deploy — while the stakes are zero. This is the single best first task and good teams assign it deliberately. - Ask questions relentlessly, and write down the answers. You have a 30-day window where every question is expected. Use it. Keep a running document of terms, systems, acronyms and who owns what. - Write the onboarding notes you wish existed. Every step that was unclear or wrong. This is genuinely valuable to the team and it is the easiest early contribution to make — you are the only person who can see the gaps. - Meet people intentionally. Fifteen minutes each with your immediate team, your product manager, and one person from a team you depend on. Ask what they work on, what is painful, and what they wish engineering understood. - Read the incident history. Post-mortems teach you where the bodies are buried faster than any architecture doc, and they explain the weird code — like the deliberate three round-trips. - Ask your manager directly what success looks like at 30, 60 and 90 days. Startlingly few people ask, and the answer removes most of the guessing. One discipline for this month: write down every "that's odd" without acting on it. Keep a list. Most items will explain themselves by week six; the ones that do not are your credible improvement proposals for month three, and by then you will be able to argue them properly. ## Month 2: contribute independently By now you should be taking normal tickets without hand-holding. What changes is the nature of the work: - Take a feature end to end — design, implement, test, deploy, watch it in production. Owning something through deploy teaches more than three months of tickets. - Start reviewing others' code. Reviewing is how you learn a codebase fastest, and asking clarifying questions in review is genuinely useful even while you are new. - Be on call, or shadow it. Nothing builds system understanding like being responsible when it breaks. - Notice the informal rules. Who is actually consulted before a decision, how disagreement is expressed, whether estimates are aspirations or commitments. Every team has these and none of them are documented. - Ask for feedback explicitly. Not "how am I doing?" but "what's one thing I should do differently?" The specific question gets a specific answer. This is also the month to calibrate your communication. Over-communicating early is much safer than under-communicating: a short daily update on what you are doing and where you are stuck builds trust quickly, and it is cheap to dial back later. Our communication skills guide covers the habit. ## Month 3: own something and propose one improvement By month three you should own an area — a service, a feature domain, a workflow — that people route questions to you about. That ownership is what makes the next promotion conversation possible. This is also when you spend the credibility you have built, carefully. Take your "that's odd" list, pick one thing, and propose it properly: what the problem is, what it costs in concrete terms, what you propose, what it would take, and what the risks are. One well-argued proposal lands; five simultaneous complaints read as someone who does not like how things are done here. And revisit the 90-day expectations you agreed in month one. Ask your manager for an explicit check: what has gone well, what should change, and what the next quarter looks like. That conversation is also the natural place to raise scope or growth. ## The mistakes that actually cost people - Rewriting before understanding. The intro's story. Ugly code often encodes a real constraint — a client requirement, an outage, a performance edge case. Ask why before proposing how. - Constant comparisons to your last company. "At my old company we did X" is fine once as context and corrosive as a habit. It reads as unwillingness to engage with the actual situation. - Not asking questions to seem competent. The most expensive form of pride available to a new joiner. Three days stuck on something a colleague could have explained in four minutes is a worse signal than the question. - Disappearing into a big task. Two silent weeks makes people nervous regardless of the outcome. Show progress in fragments. - Over-promising in week one. Your estimates are unreliable because you do not yet know the system. Give ranges and update them. - Only talking to your immediate team. The relationships that make later work easy are cross-team, and they are much easier to start while you are new and everyone expects introductions. ## If it is going badly Sometimes month two feels wrong — the work is not what was described, the codebase is worse than expected, or you are struggling more than you think you should. Some honest calibration: - Feeling slow and stupid for six to eight weeks is normal, especially in a large legacy codebase. Impostor feelings peak here for almost everyone. Our impostor syndrome guide covers it. - Raise concrete blockers early rather than saving them for a review. "I've been stuck on the deploy pipeline for two days" is a solvable problem; the same thing discovered at month three is a performance conversation. - Distinguish adjustment from mismatch. Adjustment improves week by week. A genuine mismatch — the role is materially different from what was advertised, or the environment is unhealthy — does not, and it is worth naming honestly with your manager before concluding anything. - Leaving early is survivable if it comes to that, but it costs a real amount of narrative work later, so exhaust the honest conversations first. Our reason for job change guide covers explaining a short stint. ## The First 90 Days, mentors, ChatGPT — where each fits - The First 90 Days (Michael Watkins) — the standard reference, written for managers and leadership transitions, so translate rather than apply literally as an IC. - Your own onboarding notes — the highest-value artefact you will produce this quarter, and useful to the next joiner. - Incident post-mortems and design docs — the fastest route to real system understanding, and usually unread by new joiners. - A peer who joined six months ago — the single best person to ask about unwritten rules, because they remember what confused them. - Your manager's stated 30/60/90 expectations — free, specific, and rarely requested. - ChatGPT — useful for understanding unfamiliar code and drafting an update. It cannot tell you that the three round-trips were deliberate. - Greenroom — most relevant before you start: Ari, the AI interviewer, is built for the interviews that got you here, and for the next set. Fair tradeoff: it is an interview tool, not an onboarding coach. > The core truth: the first 90 days buy you the right to change things. Ask why before proposing how, ship something tiny in week one, keep a list of everything odd, and spend your credibility on one well-argued proposal rather than five simultaneous opinions. ## The 90-day checklist - Week 1: ship something trivial, ask your manager what success looks like at 30/60/90, start the questions document. - Month 1: read incident history, meet ten people intentionally, write the onboarding notes you wish existed, list every "that's odd" without acting. - Month 2: own a feature end to end, start reviewing code, join the on-call rotation, ask for one specific piece of feedback. - Month 3: own an area, propose one well-argued improvement from your list, and review the 90-day expectations explicitly with your manager. Also useful: our multiple offers guide and notice period guide cover getting here, and the senior engineer guide covers where this ownership leads. ## Frequently asked questions ### What should you do in your first 90 days at a new job? Build context, build trust and deliver something real, in that order. In month one, learn deliberately, ship something trivial in the first week to exercise the whole pipeline, read incident post-mortems, meet people beyond your immediate team, and ask your manager what success looks like at 30, 60 and 90 days. In month two contribute independently. In month three own an area and propose one well-argued improvement. ### What should you ship in your first week at a new engineering job? Something deliberately trivial — a typo fix, a documentation correction, or a flaky test. The value is not the change itself but that it takes you through the entire pipeline of branching, review, CI and deployment while the stakes are zero. It also makes you feel like a participant rather than an observer, and good teams assign exactly this kind of task on purpose. ### What are the most common mistakes new engineers make when joining a team? The biggest is rewriting code before understanding why it is the way it is, since ugly code often encodes a real constraint or a past incident. Others include repeatedly comparing everything to a previous company, avoiding questions in order to appear competent, disappearing silently into a large task for weeks, over-promising on estimates before you understand the system, and only building relationships within the immediate team. ### How long does it take to feel productive in a new engineering job? Feeling slow for the first six to eight weeks is entirely normal, particularly in a large or legacy codebase, and impostor feelings typically peak in that window. Most engineers feel genuinely productive somewhere between month two and month three, and fully embedded around month six. The useful distinction is that adjustment improves noticeably week by week, while a genuine role mismatch does not. ### Should you suggest improvements as a new joiner? Yes, but not immediately and not all at once. Keep a written list of everything that seems odd during month one without acting on it — most items will explain themselves by week six. In month three, pick one item and propose it properly with the problem, its concrete cost, your proposal, the effort involved and the risks. One well-argued proposal lands; five simultaneous complaints read as someone rejecting how the team works. ### What should you ask your manager when you start a new job? Ask directly what success looks like at 30, 60 and 90 days, which removes most of the guesswork about priorities. Also ask who you should meet outside the immediate team, how the team prefers to receive updates and raise blockers, and what the biggest current risk to the team's goals is. Later, ask for one specific thing you should do differently rather than the vaguer question of how you are doing. The first 90 days start with the interview that got you there. Greenroom runs mock interviews out loud with Ari and scores structure, clarity and depth — free to start. Curious how it works? See how AI mock interviews work.