What Our Onboarding Actually Looks Like

New engineers do not spend their first week here watching orientation videos or reading a wiki nobody has updated since it was written. They spend it shipping something small, real, and reviewed by the same standards as everyone else's work, because the fastest way to actually understand a codebase is to make a change to it and have someone explain why the change needs adjusting.

Day one

Environment set up, a walkthrough of the architecture from whoever is free, and a first ticket picked specifically because it touches two or three parts of the system without requiring deep context on any of them. The goal for day one is a merged pull request, even a small one, because nothing builds confidence like seeing your own change go live.

Week one and the ninety day mark

By the end of week one, most new hires have shipped three or four small changes and sat in on a client call, so the work stops feeling abstract. By ninety days, they are running their own reviews and owning a real piece of a real project, not because we rushed them there, but because that is roughly how long it takes to build genuine context through actual work rather than documentation.

You learn a codebase by changing it, not by reading about it.

We check in formally at two weeks and again at ninety days, mostly to ask what is confusing and fix the onboarding process itself, which has changed a dozen times based on exactly that feedback.