Saltar a contenido

14 - First 90 days on the job

What this session is

What the first 90 days of your first AI engineering job actually look like. What to prioritize, what to avoid, and the moves that compound.

The mistake to avoid first

The number-one failure mode for new AI engineers: trying to ship impressive AI work in the first month. You don't yet know the codebase, the data, the team's conventions, the eval setup, or what "good" looks like here. Impressive work without context produces things that get reverted.

Instead, the first 30 days are about understanding the system you've joined.

The 30-60-90 frame

Days 1-30: Learn

Goal: become useful at small things, learn the system.

Daily: - Pair / shadow as much as possible. - Read existing code in the area you'll work on. - Read past PRs in that area. Understand the team's review style. - Read internal docs. Take notes. Ask questions.

Weekly: - Ship one small PR. Tiny scope. The point is to learn the dev loop, not impress. - Run the eval pipeline end-to-end yourself, even if it's not your task. - Attend every team meeting. Listen more than you speak.

Don't: - Propose architecture changes. - Argue for tools the team isn't using. - Be the loudest person in design reviews.

By day 30 you should: - Have shipped 2-5 small PRs. - Know the names and roles of everyone you work with. - Be able to run the team's training, eval, and inference pipelines. - Have a map of the codebase, even if rough.

Days 31-60: Contribute

Goal: own one meaningful piece of work end-to-end.

Weekly: - Own one ticket of meaningful size. Drive it to completion. Ask for review early. - Continue shipping incidental small PRs. - Start contributing in design conversations - opinions backed by data or experience from the first 30 days.

By day 60 you should: - Have shipped one feature or improvement that the team cares about. - Be the go-to person for at least one narrow area. - Have improved one piece of dev experience or docs for future hires.

Days 61-90: Lead a small thing

Goal: prove judgment, not just execution.

Weekly: - Take on a piece of work where the design is not fully specified. Propose the design. Get feedback. Implement. - Mentor anyone newer than you, even by one week. - Identify one process / tooling gap. Either fix it or write a doc proposing how.

By day 90 you should: - Have driven a piece of work with technical judgment, not just execution. - Have a real opinion about the team's tech direction, expressed constructively. - Have built trust with your manager and at least 2-3 teammates.

What "good" actually looks like at each level

For a junior AI engineer (entry / L3)

  • Ship reliably.
  • Ask good questions, often.
  • Take feedback well.
  • Don't break production.
  • Know your specific area well.

That's it. Don't try to be a senior in your first job. Be a great junior.

For a mid-level (L4)

  • Lead small projects end-to-end.
  • Mentor juniors.
  • Improve team-level tooling.
  • Recognize and surface risks.

For senior (L5+)

  • Drive cross-team initiatives.
  • Set technical direction in your area.
  • Force-multiply via mentorship and review.
  • Manage ambiguity.

If you came in as senior at your first AI role: you may need to recalibrate. Senior backend engineer ≠ senior AI engineer. Spend 30-60 days as an apprentice in the AI specifics, even if your title says otherwise.

The eval discipline shift

The single biggest cultural shock for engineers from web/backend backgrounds: AI work is measured differently.

In web: tests pass = ship.

In AI: tests pass and evals improve and nothing regresses on key metrics = ship. Some changes that "work" make eval worse. Some that "feel wrong" improve eval. Trust eval over intuition.

If your team doesn't have eval discipline, this is the highest-leverage thing you can fix.

The data discipline shift

Second biggest shift: you'll spend a lot more time on data than you expected.

Cleaning. Curating. Labeling. Understanding distributions. Spotting shifts. Building pipelines that handle bad data gracefully.

"AI engineering" sounds like model work. Most of the actual hours are data work.

This is true for every specialization. Make peace with it.

How to learn the codebase fast

The fastest way is not to read everything. It's:

  1. Find the entry points. Where does a request, training run, or pipeline start? main functions, API routes, scheduler entries.
  2. Trace one path end-to-end. Pick one feature. Follow it through every file it touches. Take notes.
  3. Run the debugger on the path. Set breakpoints. Watch state flow.
  4. Read the tests. They document expected behavior more clearly than docs.
  5. Ask "why" before "how." Architecture decisions usually have history.

Do this for 3-4 different paths in your first month. You'll know the codebase better than people who've been there 6 months but never traced.

Managing your manager

Your manager wants:

  • Predictable execution. Tell them when you'll deliver. Hit it. If you won't, tell them early.
  • No surprises. Bad news early > bad news late.
  • Visibility. Don't make them wonder what you're doing.

Practical: - Weekly written update. Short. What you shipped, what you're working on, what's blocked. - 1:1s are yours. Bring an agenda. Don't waste them with status. - Ask for feedback explicitly. Most managers under-deliver feedback unprompted.

The compounding moves

Small things that pay off all year:

  • Build relationships with adjacent teams. Data, infra, product. You'll need favors.
  • Write things down. Decisions, design discussions, "I tried X and here's what happened." Your team will thank you.
  • Be the person who improves docs. Quiet, high-leverage.
  • Reply quickly in Slack/email. Underrated.
  • Show up consistently. Even on hard days.

What you might wonder

"What if my team doesn't do AI well?" Common. Many companies are scrambling to "do AI" without strong fundamentals. You can: (a) learn what not to do; (b) be the person who introduces discipline; (c) leave after 12-18 months. Often all three.

"What if imposter syndrome is bad?" Universal. You'll feel underqualified for at least the first 6 months. So does everyone. The cure is doing the work, not therapy-ing the feeling.

"What if I picked the wrong specialization?" You can pivot from inside a job. Common pivots: applied LLM → serving, applied LLM → MLOps, MLOps → fine-tuning. Stay 12+ months before the pivot to avoid resume-hopper signals.

"When should I start looking for the next job?" Stay for at least 18-24 months in your first AI role. The compounding learning is enormous. After that, fair game.

Done

  • Have a 30-60-90 frame.
  • Know the cultural shifts (eval, data discipline).
  • Know the compounding moves.

Next: The next 12 months →

Comments