Developer Onboarding: Your First Two Weeks as an Engineer

Back with another one in the series where I break down things I had to learn the hard way. This one is not about an algorithm. It is about developer onboarding: the first two weeks at a new engineering job, and why those weeks matter more than most of us admit.

I used to think the interview was the hard part. You grind LeetCode, you get the offer, and then you relax. That was my mistake. The first two weeks set the tone for how a team reads you for months. Most developer onboarding hands you a laptop and a wiki link and assumes the rest sorts itself out. Here are the developer onboarding tips I wish someone had handed me before day one.

The gap nobody warns you about

Here is what tripped me up. In an interview you are judged on whether you can solve a problem. In your first two weeks you are judged on something fuzzier: whether people trust you. I walked into my first real role assuming I had to prove I was smart, so I pushed a big pull request in week one to show I could ship.

It backfired. The PR touched code I did not understand, broke a staging deploy, and made two senior engineers spend an afternoon cleaning up after me. I had optimized for looking capable instead of being useful. The real goal of developer onboarding is not to prove you are a genius. It is to become someone the team can rely on.

Week one: learn before you build

The strongest move in your first week is to resist the urge to ship. Your job is to build a map of how things work, not to add to the pile.

Read the code the way you read a new city. You do not memorize every street; you find the main roads and how to get around. Find the entry point, trace one real request from the API layer down to the database, and write down what you see. I keep a scratchpad open all week where I dump questions and acronyms as I hit them.

# onboarding-notes.md
## Open questions
- Why does auth call billing on signup? (asked Priya: legacy)
- What is a "shard rotation"? (ask in standup)
## Landmarks
- API entry: services/gateway/handler.go
- Deploy: main -> CI -> staging -> manual promote

Then get the app running locally end to end. Nothing kills momentum like a broken setup on day three. Follow the README, and every place it fails or lies, fix it as you go. That single act unblocks you and quietly signals that you improve things you touch.

The social layer matters as much as the code

Here is the part engineers underrate. A lot of the first day at a new job is not technical at all. Your team members are forming a quick, sticky impression, and you have more control over it than you think. This is even more true if you are working remotely, where every interaction carries more weight. Arrive early to calls, keep your camera on, and stay open minded when someone does things differently than your last team. A little prep helps too: confirm your schedule with HR, update your LinkedIn profile, and book a short intro meeting with your manager for the first week.

Ask questions early, but ask them well. In your first week you are supposed to have lots of questions. Before I ping someone, I write down what I already tried. That turns a vague how does deploy work into a specific I got through staging, but I cannot find who approves the production promote. It shows you did the reading, and people are far happier to help someone who tried first. A good rule: if you are stuck for more than 30 to 45 minutes, that is a signal to ask, not a failure.

Figure out who owns what and write it down. Knowing that Priya owns billing and Marco owns the deploy pipeline is worth more than any diagram. Route a question to the right person on the first try and you look like you have been paying attention, because you have.

Week two: ship something small and safe

By the second week you should start contributing, but the first thing you ship should be small on purpose. Your first PR is not about impact, it is about proving you can move through the whole pipeline safely. Pick something tiny: a flaky test, a stale doc, a log line missing context. The goal is to touch the entire workflow: branch, code, test, review, merge, deploy.

# before: a log that tells you nothing
logger.error("payment failed")

# after: a log the on-call engineer will thank you for
logger.error("payment failed",
    extra={"user_id": user.id, "amount": amount, "code": err.code})

That change is small. It is also exactly the kind of thing that makes a senior engineer think this person gets it. You made the system easier to operate without touching anything risky.

Your first code review is a personality test. When feedback comes in, do not get defensive and do not over-apologize. Ask clarifying questions, make the changes, and thank the reviewer. Teams remember how you take feedback far longer than they remember the bug you introduced.

Communicate your progress before you are asked

One habit made a bigger difference than anything technical: a short, regular status update. Whether your team does standup or async check-ins, share what you did, what you are doing, and where you are blocked. It tells your manager you are making steady progress and it surfaces blockers before they become week-long stalls. Silence reads as I have no idea what they are doing. A three-line yesterday, today, blocked note reads as I can trust this person to flag problems.

A quick mental model

If you remember nothing else about developer onboarding, remember the arc: days one to three, get set up and read code; days four to seven, answer your own questions and map who owns what; week two, ship one small safe change and take feedback well. You are not trying to be the smartest person in the room by Friday. You are trying to become the person the room does not have to worry about. That reputation compounds over the long term.

Common mistakes I have watched happen

Beyond my week-one PR disaster, three traps swallow smart new hires. Pretending to understand in a design meeting helps no one; a good question often surfaces something the whole team glossed over. Rewriting code you do not understand yet ignores that the messy version usually encodes three years of edge cases. Going silent when stuck is the worst outcome; beginning a new job means recalibrating what asking for help means. Early on, it is the job.

What to focus on next

Good software engineer onboarding does not stop at day fourteen. Teams that are good at onboarding software engineers make this repeatable, but strong software developer onboarding still comes down to the same fundamentals. Keep the onboarding notes alive and turn the best answers into real documentation. Volunteer for the on-call shadow rotation, because nothing teaches a system faster than watching it break. And say yes to small cross-team tasks, since your value grows with the number of people who know they can count on you.

If you are still in the interview stage, it is worth studying how strong engineers communicate under pressure. I have been working through the interview and career tracks on Levelop, and this problem kept pulling me back because getting the offer is only half the game. You can find more write-ups on the Levelop blog, including a companion piece on the first 90 days as a software engineer.

References

1. Wikipedia, Onboarding, en.wikipedia.org/wiki/Onboarding.
2. Wikipedia, Code review, en.wikipedia.org/wiki/Code_review.
3. The Pragmatic Programmer, Andrew Hunt and David Thomas, on learning a codebase incrementally.
4. Google, Code Review Developer Guide, google.github.io/eng-practices/review.