Your first tech job cheat sheet

1. 1Before day oneWhat to check, set up and learn between accepting an offer and your first morning, so you arrive calm and ready to learn.7 concepts

   1. 1Employment contractThe signed document that sets your role, pay, start date, working hours, leave, probation, notice period and the rules you agree to follow.
   2. 2IP, non-compete and side work clausesContract terms that give the employer rights to what you create, limit where you work after leaving, restrict side projects or ask you to repay training costs…
   3. 3Fake job offerA fraudulent offer that asks you for money, bank details or a paid "training kit", often after a chat-only interview with no video call or company email.
   4. 4Company researchLearning what the company sells, who its customers are, how it makes money, its main competitors and, where public, its tech stack and team structure.
   5. 5Account security basicsTwo-factor authentication on every work account, a password manager, a locked screen when you step away and never reusing personal passwords for work.
   6. 6Light pre-start learningA short refresher on the basics of the stack named in the job description, Git and the terminal, rather than trying to master everything before you start.
   7. 7Impostor feelingsThe feeling that you were hired by mistake and will soon be found out, very common among new engineers in their first months.

   7 in this chapterOpen this chapter
2. 2The first two weeksGetting set up, finding your way around a codebase and a team, and learning how to ask for help well.8 concepts

   1. 1Onboarding planA written list of what you should learn and deliver in your first weeks and months, agreed with your manager.
   2. 2Local development environmentEverything needed to build, run and test the code on your machine: tools, versions, access, secrets and seed data.
   3. 3Reading an unfamiliar codebaseA deliberate way to learn a large codebase: start from entry points, follow one real feature end to end, read its tests and use git log to see how it changed.
   4. 4A good questionA question that states the goal, what you tried, what you expected, what happened and the one specific thing you need.
   5. 5Timebox before askingA fixed amount of time you spend trying on your own before asking for help, agreed with your team and adjusted as you grow.
   6. 6Onboarding buddyA teammate assigned, or chosen by you, to answer everyday questions about the code, tools and unwritten rules in your first weeks.
   7. 7Working notesA private running document of commands, answers, names, terms and decisions you meet each day.
   8. 8Starter taskA small, low-risk ticket chosen so a new joiner goes through the whole path: branch, change, test, review, merge and deploy.

   8 in this chapterOpen this chapter
3. 3Working with your teamThe rituals, tickets and written habits that software teams use to plan and coordinate work.8 concepts

   1. 1StandupA short daily meeting, often 15 minutes, where the team shares progress toward the current goal, the next step and anything blocking them.
   2. 2Ticket and acceptance criteriaA ticket describes a piece of work; acceptance criteria are the checks that must be true for it to count as done.
   3. 3Estimates and story pointsRelative sizes teams give to tickets, based on effort, complexity and uncertainty, rather than exact hours.
   4. 4Sprint cycleA fixed period, often one or two weeks, that starts with planning what to do and ends with reviewing what was done.
   5. 5RetrospectiveA regular team meeting to discuss what went well, what did not and what to change in how the team works.
   6. 6Low-context written updatesMessages that make sense on their own: what, why, current state, link and what you need, without assuming the reader was in the room.
   7. 7Working with product and designProduct managers decide what to build and why; designers decide how it looks and behaves; engineers decide how to build it and flag trade-offs.
   8. 8Plain English at workShort sentences, common words, one idea per message and a structure people can scan, useful whether English is your first language or not.

   8 in this chapterOpen this chapter
4. 4Your first pull requestsGetting changes reviewed and merged safely, reviewing other people's code, and what to do when something breaks.9 concepts

   1. 1Small pull requestA change focused on one thing, small enough that a reviewer can understand it properly in one sitting.
   2. 2Pull request descriptionThe text on a pull request that explains what changed, why, how it was tested and anything the reviewer should look at closely.
   3. 3Self-reviewReading your own diff in the review tool before asking anyone else, as if you were the reviewer.
   4. 4Testing your changeAdding or updating automated tests for what you changed, running them locally and making sure the CI checks pass before review.
   5. 5Receiving code reviewReading comments as feedback on the code, answering each one, asking when a comment is unclear and pushing back politely with reasons when you disagree.
   6. 6Reviewing other people's codeReading a teammate's change for correctness, clarity and tests, and writing specific, kind comments that say whether each point blocks the merge.
   7. 7Safe deploys and rollbackWays to release without breaking production: testing on staging, hiding new code behind a feature flag, releasing gradually and knowing how to revert.
   8. 8Incidents and on-call as a juniorWhen production breaks, the team follows an incident process; juniors usually shadow on-call first, gather facts, communicate and escalate rather than fix…
   9. 9Blameless postmortemA written review after an incident that describes what happened, the impact, the causes and the fixes, focusing on systems rather than individuals.

   9 in this chapterOpen this chapter
5. 5Communication and visibilityKeeping your manager and team informed, raising problems early, and collecting the evidence of your work.8 concepts

   1. 1Status updateA short, regular written note on what you finished, what is in progress, what is blocked and what you need.
   2. 2Raising blockers earlyTelling the right person as soon as something stops your progress or puts a date at risk, with what you tried and what would unblock you.
   3. 3One-on-oneA regular private meeting with your manager, usually weekly or every two weeks, that belongs to you as much as to them.
   4. 4Work log and brag documentA running list of what you did, why it mattered and the evidence, such as links to pull requests and messages of thanks, added to weekly.
   5. 5Asking for feedbackAsking specific questions about specific work, such as "what would have made that PR easier to review?", rather than "any feedback?"
   6. 6Receiving feedback wellListening fully, asking for an example if unclear, thanking the person and saying what you will try, even when the feedback stings.
   7. 7Managing expectationsSaying clearly what you will deliver, by when and with what risk, and updating people as soon as that changes.
   8. 8Giving creditThanking people publicly or telling their manager when a teammate helped you or did great work.

   8 in this chapterOpen this chapter
6. 6Productivity and learning on the jobManaging your time and focus, using AI assistants responsibly, and learning the domain as well as the code.8 concepts

   1. 1Prioritising your workKnowing which of your tasks matters most this week, usually from your team's goals and your manager, and doing that first.
   2. 2Focus blocksProtected stretches of one to three hours without meetings or chat, used for the hardest thinking work.
   3. 3Context switchingMoving attention between different tasks, messages and meetings, each switch costing time to get back into the problem.
   4. 4Getting unstuckA routine for when you are blocked: restate the problem, reproduce it, read the error fully, shrink the case, check logs and history, then ask.
   5. 5Company AI policyYour employer's rules on which AI assistants you may use, with which data and code, and whether AI-written code must be marked or reviewed.
   6. 6Verifying AI outputReading, understanding, testing and owning every line an AI assistant suggests before it goes into a pull request.
   7. 7Confidential company dataSource code, customer data, credentials, plans and internal documents that you agreed to protect when you signed your contract.
   8. 8Domain knowledgeUnderstanding the business area your software serves, such as payments, logistics or health, its terms, rules and users.

   8 in this chapterOpen this chapter
7. 7Workplace basicsProbation, reviews, pay, leave and rights, and looking after yourself, described in general terms that vary by country and company.9 concepts

   1. 1Probation periodAn initial period, often three to six months, during which either side can end the job with shorter notice, followed by a confirmation.
   2. 2Performance reviewA regular, often yearly or twice-yearly, assessment of your work against expectations, usually with a self-review, peer input and a rating.
   3. 3Notice period and leaving wellThe time you must work after resigning, set in your contract, plus the handover, documentation and goodbyes that leave a good impression.
   4. 4Payslip, tax and benefitsYour payslip shows gross pay, deductions such as income tax, social security or provident fund, and net pay; benefits include insurance, leave and allowances.
   5. 5Working hours and leaveYour contracted hours, overtime rules, annual, sick and public holiday leave, as set by your contract, company policy and local labour law.
   6. 6Harassment and how to report itUnwelcome behaviour such as bullying, discrimination or sexual harassment, and the channels to report it: manager, HR, an ethics line or an external authority.
   7. 7BurnoutThe World Health Organization describes burnout as an occupational phenomenon from chronic workplace stress that has not been successfully managed: exhaustion…
   8. 8Healthy boundariesClear, reasonable limits on when you are reachable, how much you take on and how you recover, agreed openly with your team.
   9. 9Remote and office etiquetteEveryday norms such as camera and mute habits, status and calendar hygiene, time zone awareness, quiet in shared spaces and respecting people's focus time.

   9 in this chapterOpen this chapter
8. 8Your first year planSetting goals with your manager, earning more responsibility, your first raise conversation and knowing when a move makes sense.7 concepts

   1. 1Goals with your managerThree or four written goals for the year, agreed with your manager, each with what success looks like and how you will show it.
   2. 2Career ladderA company document describing what is expected at each level, such as junior, mid and senior, across skills like delivery, quality and communication.
   3. 3Asking for more responsibilityAsking for a slightly bigger, specific piece of work once you deliver your current work reliably, with a plan for the support you need.
   4. 4First raise conversationA prepared conversation about pay, usually timed with the review cycle, based on your evidence, your expanded scope and market data.
   5. 5Checking your market valueComparing your pay with current data for your role, level and location from salary sites, published ranges and trusted peers.
   6. 6When changing jobs early makes senseReasons that justify leaving within the first year, such as unpaid salary, harassment, no real engineering work or a clear offer of much better growth.
   7. 7Mentors and your internal networkPeople beyond your manager who advise you, such as a senior engineer, a mentor in another team or your manager's manager.

   7 in this chapterOpen this chapter
9. 9Glossary, A to ZEvery concept in the sheet and the smaller terms it uses, in one list.150 terms

First 90 days, reviews, growing fast.