1on1 Meeting Basics for New Grad Engineers: First 90 Days

In a Q4 performance calibration meeting at a Tier 1 tech company in Mountain View, an engineering manager presented an L3 software engineer with a 142,000 USD base salary and 50,000 USD in annual stock grants. The manager argued that the engineer was tracking toward a Needs Improvement rating. The team had expected the engineer to be fully autonomous on minor features by Day 60, but instead, they spent their weekly 1on1s treating their manager like a university professor, waiting for assignments and asking for validation on basic pull requests.

The calibration panel agreed: the engineer was treating 1on1s as academic progress reports rather than strategic alignment sessions. This is where most new graduates fail. They assume that doing the work is enough, but in reality, your ability to manage up in your first 90 days dictates your entire career trajectory at the firm.

The problem is not your technical execution; it is your communication latency. Your manager is not a teacher grading your homework; they are an allocator of capital and resources who needs to know if you are a safe investment.

If your manager has to spend their weekly thirty minutes extracting information from you, you are a high-overhead asset. To transition from a liability to an asset, you must master the operational baseline of the engineering 1on1. This article outlines the exact mechanics of how to run these meetings during your first 90 days to establish yourself as an autonomous, high-leverage engineer.

What should a new grad engineer talk about in their first 1on1 with their manager?

The first 1on1 meeting is not an update on your onboarding checklist, but a calibration of your alignment with team operational standards. You must use this initial conversation to establish a clear contract of expectations, understand how your manager defines success, and identify the team's immediate pain points.

The first counter-intuitive truth is that your manager does not want to hear what you did; they want to see how you think about what you do. Many new graduates enter their first 1on1 with a list of completed HR training modules, expecting praise.

Your manager assumes you will complete your HR onboarding; they are far more interested in whether you understand the team's current quarterly objectives and how your ramp-up plan intersects with those goals. If you spend your time discussing administrative tasks, you signal that you cannot distinguish between low-value compliance and high-value contribution.

During this first session, you must explicitly ask about the team's operational rhythm and definition of done. You need to know how the manager prefers to receive communication, what constitutes a blocker, and how the team handles code reviews. This shows that you are focused on integrating into their existing system rather than forcing them to adapt to your style.

Use this exact script to set the tone during your first 1on1:

I want to make sure I am aligning with your expectations from week one. Beyond the standard onboarding checklist, what are the specific technical metrics or milestones you want to see me hit by Day 30, Day 60, and Day 90? Additionally, what is the best way for me to flag blockers to you between our weekly 1on1s?

How do I structure my weekly 1on1s during the first 90 days of an engineering role?

To maximize career velocity, structured 1on1s must transition from tactical blockages in the first 30 days to system-level observations by Day 90. Your agenda must be prepared twenty-four hours in advance, documented in a shared repository, and categorized by immediate blockers, project progress, and professional development.

In a debrief for an underperforming L3 engineer who was ultimately let go after six months, the hiring manager noted that the engineer never brought an agenda to their 1on1s. The manager had to invent topics to discuss, which transformed the meeting from a collaborative alignment session into an exhausting interrogation. The goal of a 1on1 is not to prove you are smart, but to prove you are reliable. You must own the document.

During the Day 1 to Day 30 phase, your structure should focus on onboarding velocity. You are learning the codebase, understanding the build systems, and shipping your first minor bug fixes. Your agenda items should focus on clarifying architecture and identifying technical debt that slows down your local environment setup.

During the Day 31 to Day 60 phase, your agenda must shift toward feature delivery. You should discuss design doc progress, pull request feedback loops, and cross-functional dependencies.

By Day 61 to Day 90, you should be discussing independent execution, system reliability, and contributing to sprint planning.

Use this script to introduce a structured agenda document to your manager:

I have created a shared 1on1 document where I will drop my agenda items by Monday afternoon for our Tuesday meeting. I have structured it into three sections: Blockers and Decisions, Active Project Status, and Onboarding Milestones. This will help us focus our thirty minutes on high-leverage items rather than status updates that we could handle over Slack.

What are the expectations for an entry-level software engineer in 1on1s versus senior engineers?

Senior engineers use 1on1s to negotiate resource allocation and align on strategy, whereas new grads must use them to prove they can operate with low management overhead. While a senior engineer is expected to bring systemic organizational problems and organizational politics to the table, a new grad must focus on demonstrating technical curiosity, execution reliability, and rapid feedback assimilation.

The second counter-intuitive truth is that asking for feedback too often signals insecurity, not a growth mindset. Senior engineers understand that feedback is a continuous loop integrated into their daily pull requests and design reviews. When a new grad asks, how am I doing, in every single 1on1, it forces the manager to act as a therapist. Your manager does not want to manage your emotions; they want to manage your output.

A senior engineer (IC6/L6) operating at a 220,000 USD base salary level will use their 1on1 to discuss multi-quarter technical roadmaps, cross-team resource constraints, and career progression for their junior peers. As an L3 engineer, your focus is execution. Your manager expects you to show that you can take a well-defined task, identify the edge cases, write clean code, and get it through the CI/CD pipeline without requiring constant hand-holding. Your 1on1s should reflect this focus by centering on engineering rigor, testing methodologies, and architectural patterns.

📖 Related: Gilead Sciences PM promotion timeline leveling guide and review criteria 2026

How can a new grad engineer ask for feedback during a 1on1 without sounding insecure?

Effective feedback requests focus on specific operational outcomes and architectural decisions rather than generic personal validation. Instead of asking for a subjective assessment of your performance, you must ask for feedback on concrete deliverables, communication clarity, or technical choices.

The goal is not to seek comfort, but to acquire data. When you ask, do you have any feedback for me, you place the cognitive burden on your manager to recall your work, synthesize it, and present it gently. This usually results in useless, generic platitudes like, you are doing great, keep it up. This does not help you grow, and it does not help you prepare for calibration.

The third counter-intuitive truth is that managers evaluate your potential based on how you handle their critique, not how quickly you agree with it. If you ask for feedback on a specific pull request or design document, you show that you are looking for objective technical growth. You must show that you can take critical feedback, implement it immediately, and prevent the same mistake from happening in the next sprint.

Use this script to extract high-quality, actionable feedback during your 1on1:

I noticed my pull request for the data ingestion service took three review cycles because of edge cases in our error-handling logic. I want to improve my code quality before sending things to review. What specific testing strategies or static analysis tools should I incorporate into my local workflow to catch these issues earlier next time?

How do I bring up technical roadblocks or project delays to my manager in a 1on1?

Escalating a roadblock is an exercise in option analysis, not a delegation of your problem back to your manager. When you encounter a blocker, you must never present it as a dead end; you must present it alongside at least two viable solutions, their trade-offs, and your recommended path forward.

In a Q3 post-mortem for a delayed infrastructure migration, the engineering lead pointed out that a new grad engineer had been blocked on a third-party API integration for ten days without raising it. When asked why during their 1on1, the engineer said they did not want to look incompetent. By hiding the block, they turned a minor delay into a critical project failure. Your manager does not expect you to know everything, but they do expect you to have situational awareness.

When you bring a blocker to your 1on1, you must frame it clearly with the business impact, the technical root cause, and your proposed solutions. This shows that you are actively trying to solve the problem rather than waiting for someone to solve it for you.

Use this script to escalate a project delay without sounding helpless:

Our work on the user billing service is currently blocked because the staging environment database schema is out of sync with the production migrations. This will delay our integration testing by forty-eight hours.

I have investigated two options: first, I can write a temporary migration script to align staging manually, which takes four hours but introduces drift risk; second, I can work with the database reliability team to run a clean sync, which takes twenty-four hours but ensures consistency. I recommend the second option to avoid technical debt. Does that align with your risk tolerance for this release?

📖 Related: Amazon TPM career path and levels 2026

What should be on a new grad's 1on1 agenda to show initiative?

Initiative in a 1on1 is demonstrated by presenting structured insights about the codebase, team workflows, or cross-functional friction rather than asking what to do next. You must identify high-leverage opportunities to improve the team's efficiency and present them as lightweight, low-risk experiments.

Initiative is not about working longer hours, but about identifying high-leverage bottlenecks. Consider an L3 engineer who noticed that the local development environment setup guide was outdated, causing new hires to spend three days troubleshooting dependency errors. Instead of complaining about it, the engineer spent two hours updating the setup script, verified it with a peer, and brought the result to their 1on1. They had saved forty hours of developer friction for the next hire. This is the kind of initiative that gets noticed in calibration debates.

When you bring an initiative to your manager, make sure it is something you can realistically execute without disrupting your core deliverables. Do not propose massive architectural rewrites that will take six months. Focus on small, impactful improvements to tooling, documentation, automated testing, or monitoring.

Use this script to propose an initiative during your 1on1:

While working on my onboarding tasks, I noticed our integration test suite takes twenty-five minutes to run locally because we are making serial API calls. I spent an hour experimenting with parallel test execution on a local branch and managed to bring the run time down to eight minutes. I would like to spend half a day this sprint cleaning this up and putting together a pull request to update our CI pipeline. Would you be open to me prioritizing this alongside my current feature work?

Preparation Checklist

This checklist will ensure you enter every 1on1 with the structured preparation required of a professional software engineer.

Update your shared 1on1 document at least twenty-four hours before the meeting, outlining the exact agenda items you wish to cover.

Work through a structured system for cross-functional communication; the PM Interview Playbook covers handling product-engineering friction with real debrief examples, which is critical for understanding what your product manager and engineering manager expect from you during these early sprints.

Document all progress on your assigned onboarding milestones, noting any technical concepts or system architectures that require deeper clarification.

Prepare a clear summary of any pull requests submitted, design documents written, or bugs resolved during the week, focusing on outcomes rather than activities.

Identify any active technical blockers, formulating at least two possible solutions with their associated trade-offs before presenting them to your manager.

Write down one specific question regarding the team's broader technical strategy or product roadmap to show you are looking beyond your immediate tasks.

Review the action items from your previous 1on1 to ensure you can provide a status update on every item you committed to resolve.

Mistakes to Avoid

Avoid these three common operational pitfalls that signal lack of preparation, high management overhead, or poor professional maturity during your first 90 days.

Treating the 1on1 as a passive status update session.

BAD: Spending twenty minutes listing every meeting you attended, every Slack message you sent, and every line of code you read, expecting your manager to find the value in it.
GOOD: Providing a two-minute high-level summary of your deliverables, then immediately transitioning to architectural alignment, blockers, and process improvements.

Hiding technical blockers out of fear of looking incompetent.

BAD: Remaining silent on a difficult database optimization task for a week, hoping you will figure it out, while the sprint deadline approaches and other team members depend on your delivery.
GOOD: Spending a maximum of two hours attempting to unblock yourself, then documenting your attempts and bringing the structured problem to your manager with proposed paths forward.

Asking for constant personal reassurance and subjective feedback.

BAD: Asking your manager in every meeting if they are happy with your performance, if you are doing okay, or if they think you will pass your probation period.
GOOD: Asking for objective feedback on a specific design choice, code pattern, or documentation update to show that your goal is technical excellence rather than emotional comfort.

FAQ

How do I handle a 1on1 if my manager frequently cancels or reschedules our meetings?

If your manager cancels, do not take it personally, but do not let your alignment drop. Send a structured Slack update containing your active projects, blockers, and proposed solutions. If a blocker is critical, explicitly request a brief five-minute sync to unblock your workflow.

What should I do if my manager does not provide clear direction or onboarding milestones?

You must take ownership of your onboarding. Draft your own 30-60-90 day plan based on the team's current quarterly goals and present it to your manager in your next 1on1 for feedback and sign-off. This turns a vague expectation into a concrete contract.

Is it acceptable to discuss career progression and promotion during my first 90 days?

No. Your first 90 days must be entirely focused on establishing baseline competence, reliability, and low management overhead. Discussing promotion before you have shipped a single major feature signals entitlement and a lack of situational awareness. Focus on execution first.amazon.com/dp/B0GWWJQ2S3).

Your next 1:1 doesn't have to be awkward.

Get the 1:1 Meeting Cheatsheet → — scripts for tough conversations, promotion asks, and managing up when your manager isn't great.