How to develop engineers: goals, feedback, staged learning

​

Overview

Developing junior engineers is the work of raising the level of what early-career engineers can do without support. Junior engineers have not yet built up the fundamentals and the volume of experience that let them judge their own code, so the team has to shape what they learn and in what order. Junior engineers are not limited to new members, and developing them is a separate concern from onboarding: a new member’s adjustment to the team is covered in Onboarding. This page covers development from the team’s side, not the learner’s. It describes how to run development through goals, feedback, and staged learning, how a team learns together, and what the mentor still has to provide when AI agents are part of daily work.

​

How to develop engineers

​

Set goals together

Agree on the target before starting. The manager and the member should share three things: the level the member is aiming for, what the organization expects of that level, and the period in which to reach it. Describe the target level in observable terms. “Can implement a specified feature, including tests, without support” can be checked; “understands the frontend well” cannot. A skill map that lists the knowledge expected for each role and level makes these descriptions consistent across the team.

​

Share the current state as facts

State the gap between the current level and the target level concretely, based on actual changes and reviews. A vague assessment leaves the member unable to tell what to change. Pair that statement with two others: that the gap itself is not a problem, and that closing it is a shared task. Giving direct feedback well is a skill, and the people giving it benefit from practicing it.

​

Give feedback in one-on-ones

A one-on-one is a regular conversation between the member and a mentor or manager. It is not a status report but time for the member: they bring the topics, such as looking back on recent work, problems they are stuck on, and their career, and the other person focuses on drawing those out. For a junior engineer, hold one-on-ones frequently at first and reduce the frequency as the member grows. Early on, meet often enough that small questions and blockers are resolved the same day; as the range of work the member can handle alone widens, space the meetings out. Use one-on-ones for reflection and feedback, not for planning tasks. Discuss and coordinate tasks in a separate meeting with the people involved. In the one-on-one, review a recent pull request together as a retrospective, looking at what went well, what could be improved, and the reasoning behind the review comments. Make feedback and instructions concrete. “Handle this task by changing this, then this” gives the member something to act on; encouragement or general advice alone does not. Pair programming is also an effective way to show how the work is done.

​

Learn in stages

Rather than cramming many things in at once, split what the member needs to learn into the following three perspectives, and have them master each one separately. Volume comes before quality because each pull request is a feedback opportunity. Making a small change every day and getting a little feedback each time builds skill faster than spending a week on one large change and receiving many comments at once. Fundamentals matter more, not less, now that AI agents write code. Without that foundation, it is hard to judge whether the code or explanation an AI produces is correct, and errors get accepted unnoticed.

​

Separate avoidable mistakes from worthwhile difficulty

Mistakes that self-review can catch — typos, lint errors, leftover debug code — do not depend on skill or experience, so expect them to disappear early. Difficult and important topics such as testing, type design, and asynchronous processing are where struggling is expected. The question is whether the member is struggling in the right places. More difficulty on hard topics is a sign of progress. Repeating the same mistake is the signal to address.

​

Prioritize the correct method over speed

Ask the member to follow the correct procedure every time. Before changing existing code, check that tests cover it, and add tests first if they do not. When researching, read official documentation and other primary sources. Speed is not a target in the early period. A correct procedure repeated many times becomes fast; a fast but incorrect procedure has to be unlearned. Ask for progress, not results. A member who submits small pull requests every day and finishes a large task over several weeks is on track. A member who spends days thinking without submitting anything is not, because no feedback can reach them.

​

Protect time for focus

Early in a member’s growth, keep the member’s attention on the assigned tasks. Inquiry handling, incident investigation, and cross-team coordination belong to more experienced members until the member can deliver without support. When there is nothing to do, look for work together: reading code side by side almost always turns up a small refactoring or a missing test. Reading and writing code comes before output for an audience. Writing articles and speaking at events are worthwhile, but they should not take time away from the input that growth depends on.

​

Learning as a team

​

Short study sessions

A study session is a recurring time in which members present what they have learned to each other. Keeping each session short makes it sustainable alongside regular work. A common format is a five-minute presentation followed by five minutes of questions, held within the team. Lower the cost of presenting so that sessions continue:

• Do not require slides. A shared screen or a written note is enough.
• Allow a presenter to skip by announcing it before the session.
• Set a theme, such as using AI in development, but allow other topics.

Beyond knowledge transfer, presentations show what each member is working on and interested in, which helps the team understand each other. Short sessions are not suited to systematic learning or deep dives; use them alongside other forms of study.

​

Keep the development material editable

Store the onboarding documents, the skill map, and the development guidelines where every member can propose changes, such as a Git repository. Material that only its author can update falls behind the team’s actual practice.

​

The mentor’s role with AI

​

What still needs people

AI cannot supply what is not written down. Write down the history behind an architecture and the domain knowledge so that both people and AI agents can refer to them, as described in Onboarding. Even then, judgment about trade-offs and the team’s values about how to develop are learned mostly by working alongside people. When a specification is ambiguous, an AI agent can proceed on an assumption instead of raising the question, and the mismatch surfaces later as rework. The mentor’s role shifts from teaching how to write code to creating opportunities to understand the product and its users: explaining the domain with diagrams, reading specifications together, and inviting the member to design discussions and user meetings.

​

Build the ability to judge AI output

Using AI is not a problem in itself. The ability to tell whether its output is correct is what mentoring has to build. A member who cannot yet write code and tests unaided, or recognize an incorrect answer, cannot verify what an AI agent produces. That ability rests on fundamentals. With a grounding in data structures and algorithms, networking and HTTP, databases, security, and operating systems, a member can tell where an AI’s output is likely to be wrong and check it against official documentation and other primary sources. Without it, a plausible mistake goes straight into production. One approach is to stage AI use:

1. Let the member use AI freely at first, and review the quality of the resulting pull requests together.
2. If the quality shows gaps, ask the member to solve problems they cannot yet solve alone without AI, and explain why.
3. Lift the restriction step by step, starting with research and with changes the member has already made correctly elsewhere.

Once restrictions are lifted, keep one rule: review every pull request an AI agent creates before merging it. Guiding AI output to correct code through review is a skill in its own right.

​

Related pages