Thirty days isn't enough time to judge a dedicated engineer on output alone, but it's plenty of time to judge the trajectory. By day 30, you should be able to tell whether this person is heading toward full integration or stuck in a holding pattern where they're still waiting to be told what to do. Here's what actually distinguishes the two.
What should be true by the end of week one?
The engineer should understand the shape of the codebase and the shape of the team, not necessarily have shipped much yet. They should know who to ask for what, roughly how your release process works, and where the parts of the system that scare everyone actually are. If by day 5 they're still asking where to find basic things like the staging environment or the deploy pipeline, that's usually an onboarding gap on your side, not a red flag on theirs.
What does good look like by the end of week two?
A first real contribution, reviewed and merged, even if it's small. Alongside that, their questions should be getting more specific. Week one questions sound like "how does this system work." Week two questions sound like "why does this specific function handle the edge case this way instead of that way." That shift from general to specific is the clearest sign someone's building a real mental model instead of just coasting on surface familiarity.
What should be happening by the end of week three?
Independent work on moderately complex tickets, with a declining need for hand-holding on things they've touched before. This is also the point where retention signals start to show. Are they engaging in planning discussions, or just executing what's assigned? Are they flagging technical debt or risk they notice, even on tickets outside their immediate scope? An engineer who's only ever reactive by week three usually stays reactive, which caps how much value the engagement ever delivers.
What should the 30-day mark actually tell you?
Whether this is a long-term fit, not whether they're fully ramped. Full ramp on a non-trivial codebase realistically takes 2 to 3 months, sometimes longer on legacy systems with thin documentation. What 30 days should tell you is trajectory: is output per week increasing, are review comments shrinking in volume and severity, is the engineer starting to take initiative instead of waiting for direction. If the trend line is up, the engagement is working even if raw output still looks modest. If the trend line is flat, that's worth addressing at 30 days rather than hoping it improves at 60.
What's the single biggest mistake companies make in the first month?
Judging day 30 against day 1 of a developer who's been on the team for 2 years. That comparison is set up to make every new hire look slow, dedicated or not, remote or local. The honest comparison is this engineer's day 30 against their own day 1, and against the realistic ramp curve for your specific codebase's complexity. A team with clean documentation and clear ownership boundaries should see faster ramp than a team running on 5 years of undocumented tribal knowledge, and judging both against the same 30-day bar isn't fair to either the engineer or the comparison.
What should you actually review at the 30-day mark?
A short, honest conversation covering three things: what's gone well, what's been harder than expected, and what needs to change for month two. This isn't a performance review, it's a calibration check for both sides. The engineer should leave it knowing exactly what's expected next. You should leave it with a clear read on trajectory, not just a gut feeling. Teams that skip this conversation and just let the engagement run tend to discover problems at month three that were visible, and fixable, at day 30.
For how we structure the first month on every engagement, including what we actually track at the 30-day mark, see how we work. If you're earlier in the decision and still weighing whether a dedicated engineer is the right call, why offshore developers keep leaving covers the retention side of this, and why teams stay with us 18+ months covers what we do to keep the trajectory pointed up past month one. For what should already be true before day 30, see the first two weeks and augmenting vs replacing.