Chapter 1 of 7 · 5 checks · 4 min
Before day one and week one: access, setup and people
Get the logistics out of the way, get a working development setup, and meet the people you will work with most.
Confirm your start time, manager, equipment and first-day plan before day oneMust
Why it matters and how to check
A week before you start, reply to HR or your manager to confirm the basics: start time and place (or video link), who you report to, when your laptop arrives and what you should have ready, such as ID documents or bank details for payroll.
Ask one more question: "Is there anything I should read or install before I start?" Many teams have a public engineering blog, docs or an open source repo. Spending an hour on the product as a user is also worth it. You are ready when you know where to be, who to ask for and what day one looks like.
Do
- Confirm in writing who your manager and onboarding contact are
- Use the product yourself before day one
Avoid
- Trying to learn the whole tech stack in advance
List every system you need access to and chase the gaps in week oneMust
Why it matters and how to check
In week one you will need accounts for email, chat, the code host, the issue tracker, CI, cloud consoles, documentation and VPN. Missing access is the most common reason new developers sit idle. GitLab's remote onboarding guide lists account creation trouble among the common early problems.
Make a short list, tick off each system as it works, and send one message to your buddy or IT with everything still missing rather than asking piecemeal. Week one is done when you can open the repo, the tracker and the docs, and post in the team channel.
Do
- Keep a written access list and update it daily
- Ask your buddy which access request process to use
Avoid
- Waiting silently for access to appear
Get the project running locally and fix the setup docs as you goMust
Why it matters and how to check
Follow the README or setup guide to build the project, run the tests and start the app locally. Setup docs are often out of date, so you will hit errors. Write down each problem and how you solved it.
Turning those notes into a docs fix is an ideal first contribution: it is small, useful and gets you through the review process early. You are done when you can run the app and its tests from a clean terminal, and your notes are either merged into the docs or shared with the team.
Do
- Note every setup error and its fix
- Open a small pull request to update the setup guide
Avoid
- Spending a whole day stuck on setup without asking for help
Meet your onboarding buddy and each teammate in your first two weeksMust
Why it matters and how to check
GitLab's onboarding guide recommends an onboarding buddy so new people always have someone to ask "newbie questions". If your team has not assigned one, ask your manager who you should go to for day-to-day questions.
Book a short call or coffee with each person on your immediate team. Ask what they work on, what they wish they had known in their first month and who else you should meet. A Microsoft study of developers who joined remotely found building social connection with the team was one of the biggest challenges, so do this on purpose. You are done when you know each teammate's name, area and preferred way to be contacted.
Do
- Keep a simple list of who owns what
- Ask each person who else you should meet
Avoid
- Only talking to your manager for the first month
Learn where the team talks, decides and asks for helpShould
Why it matters and how to check
Every team has unwritten rules: which chat channel is for questions, whether decisions happen in docs, tickets or meetings, how quickly people expect replies, and when standups happen. Learning these early saves you from asking in the wrong place.
Read the last two weeks of your team channel and a few recent design docs or tickets. Then confirm with your buddy: "Where should I ask questions about the build? Where are decisions written down?" You are done when you know where to post a question so the right person sees it.
Do
- Join the team, incident and help channels on day one
- Note working hours and time zones of teammates
Avoid
- Sending direct messages for questions that belong in a team channel