Field notes / Engineering Leadership
How to evaluate a product engineer through their work
A practical hiring conversation around inspectable artifacts: product decisions, implementation boundaries, operational ownership, and tradeoffs.
A demo is a good place to start a hiring conversation. It is a limited place to end one. A polished interface can show product craft, but it cannot by itself establish how someone makes decisions, handles a failure, or works with a team.
I want the public work on this site to support a more useful conversation. That means making the role, implementation choices, and limitations visible alongside the product.
Start with an artifact you can inspect
Choose a small product path and try it. What is the user trying to accomplish? Which states are visible? Is there a useful response when something changes or fails? Ask the engineer which part they owned rather than inferring ownership from the presence of a project logo.
The Lively Icons case study identifies my role and includes a real interface. Its demonstration uses static icon artwork, selection state, and optional motion. Those are specific choices a conversation can examine.
Inspect evidence across the whole product
Use this as a conversation guide. A public work sample does not prove every capability or reveal private work.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Four work-sample evidence cards: user problem, implementation decisions, failure handling, and communication of tradeoffs. Use this as a conversation guide. A public work sample does not prove every capability or reveal private work.
The evidence map is a proposed evaluation framework. Public work samples do not reveal everything about a person’s experience, and they should not force disclosure of confidential work. The map is a way to identify useful questions, not a scoring system that claims to predict job performance.
Ask about constraints before alternatives
It is easy to propose another architecture after seeing a finished artifact. First ask about the constraints: the team, the user, the operating environment, and what had to remain simple.
Then compare another approach. What would it improve? What new responsibilities would it create? Which new information would make the original decision worth revisiting?
For Lively Icons, the boundary between static artwork and the behavior around it is a useful example. Motion can change without forcing the icon itself to depend on the demo’s timing or selection logic. Reduced-motion preferences are part of that conversation, not an afterthought.
Move from the demo to the decision
A proposed hiring conversation connects an inspectable artifact to its constraints, alternatives, and ownership.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Four linked interview prompts: observe the artifact, ask about constraints, compare alternatives, and discuss ownership after launch. A proposed hiring conversation connects an inspectable artifact to its constraints, alternatives, and ownership.
Look at what surrounds the happy path
A product engineer should be able to discuss more than a successful screen. Ask how a failed save is represented, how duplicate requests are handled, and who will operate the system after launch. The depth needed depends on the role; the point is to connect the artifact to the responsibility being considered.
The AI product imagery workflow offers a different kind of evidence. Generation is only one part of a process that also needs input quality and human review. Ask which decisions the system makes and which decisions remain with a person.
A useful answer can include an acknowledged limit. It is more informative to hear where the artifact stops than to receive an unsupported claim that it solves every related problem.
Use writing to examine decision-making
Technical writing can make a decision inspectable over time. Does it explain the problem, alternatives, failure modes, and consequences? Can you tell which parts are observed experience and which are a proposed approach?
My engineering operating workflow is another starting point. It explains the role of AI-assisted briefs and recurring checks while retaining human judgment. Discuss which parts would fit your team and which would not.
Connect the conversation to the actual role
Bring the role’s real constraints into the discussion. A position focused on product delivery needs different evidence from one responsible for an engineering organization. Ask what the person would need to learn and where they would need help.
A work sample is evidence for a conversation, not a replacement for references, role-specific evaluation, or mutual expectations. The goal is a clearer understanding of how the person thinks and what the role requires.
The hiring profile collects the relevant public work. If you see a potential fit, share the role and team context.
From the idea to the work
Give the team a clearer way forward.
Work through architecture, delivery habits, and the engineering decisions that are slowing your team down.