The Offer & First 90 Days
The phone rings and it's a yes. After all the months of learning and the weeks of interviewing, an offer is on the table. This final chapter is about closing well — evaluating the offer beyond the number, negotiating without fear, leaving your current job gracefully — and then starting strong, so the first ninety days build the trust that the rest of your career compounds on. Then we take a breath and look back at how far you've come.
Evaluating an offer beyond the salary
The salary is the loudest number, but it's rarely the one that decides whether you'll be happy in two years. An offer is a whole package — a role, a team, a trajectory — and the early job is the one that shapes everything after it. Slow down and look at all of it.
- The role & scope. What will you actually own? "Data engineer" can mean writing pipelines, babysitting dashboards, or something in between. Ask what a typical week looks like and what they expect you to be doing in six months.
- The team & manager. Your manager will shape your first year more than any other single factor. In your interviews, did they listen? Did the team seem like people who'd help you when you're stuck? A great manager on a mediocre product beats a bad manager on a famous one.
- Growth & mentorship. Are there senior engineers to learn from? Will someone review your code and explain why? Your first role should make you better, not just busier. A team where you're the only data person is a hard place to grow early.
- The actual work. Modern stack or legacy mess? Are they building something or just keeping the lights on? Both can be fine — just go in knowing which one you're signing up for.
- Stability. Is the company funded and growing, or one bad quarter from layoffs? Ask about the team's history and how the data function is viewed inside the org.
- Comp components. Total compensation usually has three parts: base (guaranteed salary — the part you can count on), bonus (often a target percentage, not guaranteed), and equity (stock or options that vest over years, worth more at big public companies and far riskier at startups). A "$140k offer" with $90k base and the rest in startup equity is a very different thing from $140k base.
Bonuses get cut and startup equity often ends up worth nothing. For your first data job, weight the guaranteed base salary most heavily — it's the only number you can pay rent with. Treat bonus and equity as upside, not as part of what you're counting on.
Here's a quick scan for reading the health of an offer and team. None of these are dealbreakers on their own, but the pattern tells you a lot.
| Green flags 🟢 | Red flags 🔴 |
|---|---|
| Clear role and a written job description that matches what you discussed | Vague role, "we'll figure out what you do when you start" |
| A manager who answered your questions thoughtfully | A manager who dodged questions about workload or growth |
| Other engineers to pair with and learn from | You'd be the only data person, with no one to review your work |
| Documented onboarding, runbooks, real engineering practices | "Everything's in people's heads," no docs, constant firefighting |
| Comp in writing, with base/bonus/equity broken out | Pressure to accept verbally before you see the written offer |
| They give you time to decide (a few days to a week) | "Exploding" offer — decide in 24 hours or it's gone |
| People speak well of their teammates and the work | High turnover, or interviewers who seemed burned out |
Negotiation basics
This is the part that makes everyone nervous, so let's defuse it first: negotiating is expected. Recruiters do this every day. They almost always have room above their first number, and a first offer is rarely their best one. Politely asking for more is normal professional behavior — it does not make you greedy, and a well-run company will not pull an offer because you negotiated courteously. The worst realistic outcome is "that's our best we can do," and you're exactly where you started.
Not negotiating can quietly cost you thousands of dollars a year — and because future raises are usually a percentage of your current salary, that gap compounds for your whole career. A five-minute, polite conversation is one of the highest-paid things you'll ever do. It's worth the discomfort.
A few principles that keep you on solid ground:
- Don't give the first number if you can avoid it. When a recruiter asks "what are you looking for?", you can deflect: "I'm focused on finding the right fit — what range do you have budgeted for this role?" Let them anchor first. (If pressed, give a researched range, not a single number.)
- Negotiate the whole package, not just base. Base salary is the priority, but equity, signing bonus, and even start date are all negotiable. If they truly can't move on base, ask about a signing bonus or extra equity.
- Use competing offers — honestly. A real competing offer is the single strongest lever. "I have another offer at $X and would love to make this work" is completely fair. Never invent one; getting caught lying is the one thing that genuinely torches an offer.
- Always be warm and collaborative. You're not fighting them; you're working with them toward a yes. Express genuine enthusiasm for the role while you ask. Enthusiasm plus a polite ask is a combination recruiters respond well to.
Scripts make it concrete. Read these aloud once — they sound a lot less scary in your own voice:
# When asked for your number first
"I'd rather understand the full picture before naming a figure —
what range is budgeted for this role?"
# The core ask (warm + specific)
"Thank you, I'm really excited about this team. Based on my
research and the scope of the role, I was hoping we could get
the base closer to $X. Is there flexibility there?"
# With a competing offer
"I want to be transparent — I have another offer with a base of
$X. I'd much rather join you. Is there room to close that gap?"
# If base is truly capped
"I understand the base is fixed. Could we look at a signing
bonus or additional equity to bridge the difference?"
# Closing the deal graciously
"That works for me — I'm thrilled to accept. Could you send the
updated offer in writing so I can sign?"Verbal promises evaporate. Before you formally say yes, get the final numbers — base, bonus, equity, start date — in a written offer letter or email. Then accept. This protects you and is completely standard; no reasonable employer will be offended.
Accepting gracefully & resigning professionally
Once the written offer matches what you agreed, accept warmly and promptly. Send a short, enthusiastic note, confirm your start date, and ask what they need from you before day one. First impressions start now — a prompt, gracious acceptance sets the tone.
Then, politely decline any other companies still in progress. A two-line thank-you keeps those doors open; the industry is smaller than it looks, and a recruiter you treat well today may have your next role in three years.
If you're a career-changer leaving a current job, resign like a professional — this matters more than people realize:
- Tell your manager first, in person or on a call, before anyone else hears it. Don't let them find out secondhand.
- Give proper notice — typically two weeks, or whatever your contract or field expects. Offer to help document your work and hand off responsibilities cleanly.
- Keep the reason simple and positive. "I've found an opportunity that's the right next step for me." You don't owe anyone a list of grievances, and airing them gains you nothing.
- Stay engaged to the end. The last two weeks are when reputations are made or broken. Finish strong.
Your industry is a small, well-connected village. The colleague you part with kindly becomes a reference, a referral, or a future teammate. Even if you're relieved to leave, leave gracefully — it costs nothing now and pays off for decades.
The first 90 days
You got the job. Now the goal shifts: turn that offer into trust. The first ninety days are not about heroics or rewriting their architecture — they're about learning the lay of the land and proving you're someone the team can rely on. A simple way to frame the ramp is in three thirty-day phases.
Days 0–30 — Learn. Your job is to absorb, not to impress. Get your environment working, read every runbook and design doc you can find, and trace how data actually flows through their systems. Meet your teammates one-on-one. Ask questions relentlessly — in your first month, "I don't understand this yet, can you walk me through it?" is a sign of diligence, not weakness. Nobody expects a new hire to know the system; they expect you to learn it.
Days 30–60 — Own a small piece. Now turn learning into delivery. Take ownership of one bounded thing — a pipeline, a dashboard, a recurring fix — and ship something real, end to end. It doesn't have to be big. Shipping a small, correct change early is the fastest way to earn trust: it proves you can navigate their codebase, their review process, and their deploy pipeline, and come out the other side with working software.
Days 60–90 — Be a reliable contributor. By now you should be shipping steadily and owning your corner of the system without hand-holding. Reliability is the whole game here: when you say you'll do something, it gets done; when something breaks in your area, you handle it. Start reviewing teammates' work and answering questions you now know the answers to. You're becoming part of the team's load-bearing structure.
Read the runbooks before you ask what's in them. Pair with a teammate on a real task in week one — you'll learn more in an hour beside someone than a day alone. Ship something small early to build trust. And find a mentor: someone slightly senior who'll answer your "dumb" questions without judgment. New hires with a go-to person ramp far faster than those who struggle in silence.
Growing into senior
You'll want to know what comes after "hired and ramping." Here's the secret that surprises a lot of new engineers: the path to senior is not mostly about getting better at code. Technical skill is the price of entry. What actually moves you up is a different, broader set of qualities:
- Ownership. Senior engineers take responsibility for outcomes, not just tasks. They see a problem and fix it without being asked, and they don't drop things on the floor.
- Scope. You grow by handling bigger, fuzzier, more ambiguous problems — designing a system rather than implementing a ticket someone else specced.
- Reliability. Being the person whose work simply works, consistently, is worth more than occasional brilliance. Trust is the senior engineer's real currency.
- Communication. Writing a clear design doc, explaining a tradeoff to a non-engineer, disagreeing without friction — these multiply your impact far beyond what your hands can build.
- Helping others. Mentoring juniors, reviewing thoughtfully, making the whole team better — seniority is partly measured by how much you raise the people around you.
And keep learning, because the field never stops moving. The tools you learned in this curriculum are a foundation, not a finish line — new engines, new patterns, and new platforms will arrive, and the engineers who stay relevant are the ones who keep reading and building. When you're ready to deepen your systems thinking, the system-design reference is your "level up" reading — the same designs you reasoned about in interviews, in more depth, for the rest of your career.
You don't become senior the day HR changes your title — you become senior the day you start acting like it: owning outcomes, communicating clearly, and lifting the team. Start practicing those behaviors in your first 90 days and the title catches up to you.
How far you've come
Stop for a moment and look back, because what you've done is genuinely remarkable.
You started this curriculum with the foundations — your first SELECT statements, your first Python scripts, learning to drive a shell and put your work under version control. You probably felt like a beginner, because you were one. Then you built up the craft: real data modeling, pipelines, the patterns that turn raw data into something trustworthy. You picked up the tooling that professionals actually use — orchestration, warehouses, the modern stack — and learned not just how to run it but why it's built the way it is.
Then you did the thing most learners never reach: you built a capstone. A real, working, documented data platform — one you designed, deployed, and can demo and defend in conversation. That artifact is proof, to yourself and to any employer, that you can do the work.
And then you ran the job search as the deliberate process it is — targeted applications, a portfolio that stands out, drilled interviews, system-design fluency — and you got hired. Now you're a ramping data platform engineer who can reason about systems at scale, hold your own in a design discussion, and ship code that other people depend on.
Think about the distance between that first nervous SELECT * FROM and where you stand now. That is not a small step. That is a transformation, and you earned every part of it by doing the work.
The learning never stops — and that's the joy of this field, not a burden. But the steepest, scariest climb, from "I don't know if I can do this" to "I'm a hired engineer who's done it," is behind you. You crossed it. Everything ahead is growth from a position of strength.
✓ Check yourself
- Can you name the components of total comp, and why base matters most for a first role?
- Could you politely deflect "what's your number?" and make a warm counter-offer out loud?
- Do you know how to resign without burning a bridge?
- Can you sketch what your first 30, 60, and 90 days should look like?
- Can you name three things — beyond coding skill — that get you to senior?
Exercise — Draft your own 30/60/90 plan for your first data role
Write a one-page plan for your first ninety days at a data role (real or imagined). For each phase, list a goal and 2–3 concrete actions. Bring a version of this to your first week — managers love a new hire who shows up with a thoughtful ramp plan.
DAYS 0–30 — LEARN
Goal: Understand the systems, the people, and the codebase.
• Read every runbook and design doc; map how data flows
end to end.
• Have a 1:1 with each teammate; find a go-to mentor.
• Get my dev environment fully working; run the pipelines
locally and trace one through the whole stack.
• Keep a running list of questions and ask them freely.
DAYS 30–60 — OWN A SMALL PIECE
Goal: Ship something real and take ownership of one area.
• Pick up a bounded pipeline / dashboard / fix and own it.
• Ship one change end to end — through review and deploy.
• Document anything I found confusing, so the next hire
has it easier.
DAYS 60–90 — CONTRIBUTE RELIABLY
Goal: Be a dependable, trusted member of the team.
• Ship steadily; own my corner without hand-holding.
• Start reviewing teammates' PRs and answering questions.
• Check in with my mentor; set growth goals for the
next quarter.There's no single right plan — the value is in thinking like someone who's already trusted. A new hire who arrives with a plan like this signals exactly the ownership that gets people promoted.
Next
There is no next chapter — and that's the point. You've reached the end of the curriculum.
You walked the whole road: foundations, craft, tooling, a real capstone, and the job search that turned it all into an offer. You are no longer someone learning to become a data engineer. You are one — hired, ramping, and building. Be proud of that. It was hard, and you finished.
Keep this site as a reference whenever you need it, and head back to the curriculum home to revisit any chapter. Bookmark the Glossary & Cheat Sheets too — a quick lookup for every term and pattern you've met along the way.
Now go do great work. We're genuinely rooting for you. 🚀