Hiring Junior Engineers: Make Initiative Visible With AI

Hiring junior engineers for initiative means examining how someone chooses a problem, checks an assumption, and uses evidence to decide what to do next. Give candidates a comparable opportunity to show those behaviors. A working prototype can help, but so can a well-supported decision to build nothing.

That last possibility matters more when a convincing demo takes less effort. You can be impressed by what a candidate made and still know little about whether the problem deserved their attention. The useful question begins before the code: what did they notice, and why did they pursue it?

What does “hunger beats tenure” change about junior hiring?

Felix Rieseberg’s October 27 essay offers an encouraging starting point. He describes changing his own coding interviews and seeing newcomers make useful things with AI. His advice also reaches experienced newcomers who lack status or influence. A focused prototype gives someone without much status a way to make an opportunity visible. He also acknowledges that his replacement interview is unfinished.

For a hiring manager, the next step is to turn that insight into questions you can examine. Initiative involves deciding where effort belongs. An engineer might challenge a familiar requirement, investigate a recurring customer complaint, or discover that an apparently technical obstacle is an unanswered policy question.

None of those contributions requires being the loudest person in a meeting. A candidate who quietly asks why a requirement exists may be showing exactly the behavior you want. You need a way to distinguish a useful question from an attractive performance of confidence.

There is an older foundation for this thinking. In his 2011 career essay, Patrick McKenzie connects engineering work to business value. Applied to hiring, that means asking what improves for a customer or colleague. It does not mean demanding that an inexperienced applicant invent a revenue strategy from outside your company.

Give them enough context to identify a useful contribution. You are examining how they reason with what they can know.

Why doesn’t a faster demo settle the question?

AI productivity research gives you reasons to examine the setting before drawing conclusions about an individual. It does not establish that juniors generally outperform experienced engineers, or the reverse.

Cui and colleagues’ company experiments involved 4,867 developers and found a pooled increase of about 26% in completed tasks with an AI coding assistant. The full draft treats differences by experience and tenure cautiously: subgroup patterns were suggestive and generally lacked statistical significance. These were earlier coding-assistant experiments measuring task output, not a test of business judgment with today’s agents.

Meanwhile, Daniotti and colleagues’ observational GitHub study found benefits concentrated among more experienced developers. Here, experience meant years active on GitHub, rather than verified workplace seniority. AI use was inferred, and contributions served as an output measure. Those choices make it a different question from the randomized company experiments.

For your interview, the implication is practical. Record which tools someone used, what they understood before using them, and how they checked the result. Do not infer their potential from a broad label such as junior, AI-native, or experienced.

You also need to separate a demonstration from a commitment to operate it. A prototype can show that an interaction is possible. It leaves open whether customers want it, whether it fits the existing product, and who will support it. Your follow-up after a coding solution passes can examine implementation decisions. The earlier question is whether this was a useful solution to attempt.

Separate initiative from access to an opportunity

A portfolio tells you what a candidate can show you. It cannot tell you every opportunity they have had, or every useful contribution they were allowed to make public.

Someone may have a large personal project, a confidential workplace example, a contribution to a community group, or very little finished work. Ask about the decisions within the example before rewarding its size. A small change made under real constraints can support a richer conversation than an elaborate application whose purpose remains vague.

Then offer another route. A candidate who cannot share prior work should be able to investigate a bounded problem you provide. Supply the same core context, allowed tools, expected effort, and definition of a useful response. If access to an AI tool matters, arrange comparable access rather than making a personal subscription an unspoken requirement.

The US Office of Personnel Management’s structured-interview guidance supports common questions and consistent standards for job-related competencies. That is a sound organizing principle here. It does not validate this particular exercise or turn a subjective impression into a proven predictor.

Be explicit about what you expect a junior to know already. OPM’s work-sample guidance distinguishes skills required at entry from those taught after hiring. If you intend to teach your product domain, let the exercise reveal how someone learns about it. Do not disguise missing company context as missing initiative.

Clear conditions also help candidates decide whether to participate. State the effort limit, permissible AI use, submission format, and how to ask questions. Our guide to testing take-home assignment instructions covers that groundwork.

Give candidates a problem worth investigating

Use an exercise that allows more than one reasonable next step. If the only acceptable outcome is your preferred feature, you are assessing agreement with an unstated answer.

Consider a hypothetical startup whose new customers often leave before inviting a teammate. The team suspects the invitation flow needs a redesign. You are hiring a junior product engineer, so you prepare a fictional research packet: a simple journey map, example support notes, a small set of example sessions, and the current invitation screen.

Ask the candidate to recommend one next step that would help you understand or reduce this first-use friction. Explain the product’s goal, the limits of the packet, and what they may ask the interviewer. A short written explanation, a sketch, or a small prototype is acceptable. The quality of the investigation matters more than the amount produced.

One candidate immediately builds a smoother invitation modal. It may be good work. Ask which evidence made the modal the best place to intervene. Can they distinguish trouble sending an invitation from a user who has no reason to invite anyone yet?

Another candidate notices that several example users are evaluating the product alone before seeking approval. They ask whether inviting a teammate is actually necessary to experience its value. The interviewer explains that solo evaluation is permitted, but the current onboarding language makes invitations sound mandatory.

Now the candidate has a useful choice. They could prototype a clearer route for solo evaluators. They could propose testing revised instructions before changing the interface. Or they could recommend gathering evidence about why people leave before spending engineering time.

Suppose they choose the last option. Their explanation identifies the uncertain assumption: leaving without inviting someone does not necessarily mean the invitation experience failed. They propose a short follow-up with evaluators who agree to take part and explain which answers would justify a product change. They also identify a limitation: the supplied sessions cannot show whether a departing evaluator returns later.

That response may contain no code. It can still show initiative through a relevant question, a plausible alternative explanation, and a test that could change the decision. The interviewer should examine whether the proposed test would actually distinguish those explanations. Merely asking for more research should not become an automatic good answer either.

Set a firm boundary around the exercise. This is a proposed exercise, with no established predictive validity. Use fictional or appropriately prepared material, and do not turn applicants into an unpaid product-discovery team. If the work becomes a substantial commercial assignment, define and compensate that assignment separately.

Ask for the reasoning that changed the next step

A useful review follows the candidate’s decisions from the information available to the action proposed. It should leave another reviewer able to understand why you found the work promising or concerning.

In the example, write down that the candidate questioned the meaning of the invitation metric and connected it to the evaluator’s goal. Record the information the interviewer supplied. Then describe how the candidate used that information. This matters because a strong follow-up to a hint is different evidence from noticing the issue independently.

Use a few common questions to keep the discussion grounded:

• What made this problem worth investigating before the other problems you noticed?
• Which constraint did you check, and how did the answer affect your approach?
• What result would make you abandon your proposed next step?
• What remains unknown, and who would need to be involved before proceeding?

Listen for an answer that can survive a reasonable challenge. If the candidate proposes new onboarding copy, ask what would happen if people still leave. If they propose research, ask why that information is worth its cost. Their ability to revise a position is more useful evidence than having an instant defense for everything.

Avoid translating every observation into a personality judgment. “Asked whether solo evaluation was supported” is specific. “Has founder energy” tells the next reviewer very little. It may also hide disagreement about the job you are hiring someone to do.

You can prefer one approach and still recognize thoughtful work in another. Agree on the job-related behaviors before discussing which candidate impressed you most. Keep the evidence, its limits, and your recommendation distinct enough for a colleague to challenge your reasoning.

What can applicants show without a large portfolio?

Choose an example with a decision you can explain. The project does not need to be large, public, or commercially successful, provided you are permitted to discuss it.

You could describe a repeated manual step you investigated, an unclear instruction you tested with its users, or a feature you stopped building after learning more. Explain what you initially believed, what you checked, and what happened next. If you cannot verify an outcome, say what you observed rather than inventing a business result.

When AI helped, explain the division of work concretely. Perhaps it generated alternatives, wrote a rough implementation, or helped analyze an error. Show where you selected among its suggestions, checked a claim, or rejected an answer. A list of tools gives the interviewer less to examine than one decision you can defend.

You can also explain what you would do with better access. Name the customer question you could not answer or the permission you would need for a test. That shows an awareness of the boundary around your evidence. Do not disclose an employer’s confidential material to make the story more impressive.

If the employer requests a new exercise, ask for the expected effort and assessment criteria. You should understand whether a prototype is necessary and whether a reasoned recommendation is acceptable. Knowing the task’s limits lets you spend your effort on the question they actually want answered.

What do managers owe engineers with fresh eyes?

Give newcomers a way to question assumptions while they still notice them. Hiring someone for initiative makes little sense if every subsequent question requires influence they have not yet acquired.

James March’s 1991 work on organizational learning offers a useful explanation. His models examine how organizations can lose variation in beliefs as members learn established practices. Newcomer contributions arise from different perspectives, rather than superior knowledge on average. This is organizational theory, not evidence that inexperience makes an engineer better at using AI.

Put that idea into ordinary management practice. Explain the customer goal, make someone available for questions, and give the engineer time within their work to investigate a bounded opportunity. Help them distinguish a real technical constraint from a decision nobody has revisited.

When you reject a proposal, explain what would change your mind. When a test fails, recognize what the test helped clarify. Otherwise you teach people to bring you polished success stories and keep their doubts private. Your junior-engineer apprenticeship plan can provide the learning support that an interview cannot.

The opportunity should have a decision owner, too. Someone needs to read the result, choose whether to continue, and help with the next dependency. Producing a prototype that nobody considers is a poor lesson in initiative.

Keep the evidence useful in Kit

Keep the submitted work, the task’s conditions, and your reviewers’ reasoning together. That makes it easier to discuss the actual evidence when memories of an impressive conversation start to diverge.

In Kit, Portfolio Upload can collect prior work a candidate is permitted to share. Work Sample can hold an employer-provided task with a private brief, visible expected effort, and a deadline measured from the candidate’s start. Human reviewers can record scores, comments, and recommendations through the reviews and feedback workflow.

Those records give your team somewhere to examine initiative. You still have to provide a worthwhile opportunity and decide what the evidence supports. Start with a problem small enough to investigate, make the conditions clear, and leave room for an applicant to show that the next useful step is a better question.