Hiring
We hire for understanding, not output. A candidate who executes cleanly but cannot explain why they made each choice is a no-hire, no matter how tidy the code, because what we are paying for is judgment under new conditions, not a transcription of a known pattern. One bad-fit hire costs the team far more than a slow search, so the bar stays high and the loop is built to catch the difference. This doc is the single source for the whole loop: the non-negotiables (hard filters that end the conversation), the rubric and the bar per level (how to score what is left and place it), and the loop itself: who to interview, the take-home, the interview, and the call.
The same shape runs for Product Engineer, Product Manager, and Product Designer: one take-home, one interview, one bar per level, intern to lead. What changes is the bar, not the process. The worked example below is Product Engineer’s; PM and PD run the same loop with their own case (draft: confirm the discipline-specific case per role).
The Non-Negotiables#
These are hard filters. Fail one and it is a no-hire, at any level, regardless of rubric score.
- Critical thinking, understands why. Asks why, challenges the prompt, and can re-derive and re-explain their solution from scratch. Tell: ask them to restate the problem and justify each decision; recognizing the right answer without being able to re-explain it is the red flag, because what you cannot re-explain, you do not understand. See The Illusion of Understanding and Find the Root.
- Honesty and integrity. Says “I don’t know” instead of bluffing, and owns a mistake mid-interview. Tell: watch what they do when stuck or wrong; do they hand-wave and fake familiarity, or name the gap plainly. See The Illusion of Understanding.
- Ownership and accountability. Treats the problem as theirs to solve, drives it forward, and does not wait to be led. Tell: between hints, do they push the problem forward themselves, or stall until spoon-fed. See Assume It Works Out.
- Low ego, coachable. Takes a hint without defensiveness and updates, but can still defend a good decision with reasons. Tell: give one corrective hint and one wrong-headed hint; the good candidate absorbs the first and pushes back on the second with reasoning.
- High agency, bias to action. When blocked, makes a reasonable assumption and moves rather than freezing. Tell: do they state an assumption and proceed, or stop dead. See Assume It Works Out.
Critical thinking is the filter the whole loop is built to detect.
The Rubric#
The technical screen scores four dimensions:
- Communication: understands the problem, asks the right questions, explains and visualizes the solution, and incorporates hints.
- Problem Solving: breaks the problem down, moves from a brute-force to an optimal solution, and reasons about time and space.
- Coding: translates the idea into readable, bug-free code.
- Verification: checks that the code works: dry run, sample cases, unit tests, edge cases.
The hint mechanic: the interviewer offers hints, and the candidate’s level is read from how far they get and how little help it took. The bar below is calibrated to that: an Intern is expected to need substantial hints, while a Senior reaches the optimal solution with almost none.
How to Test#
You do not ask “are you a critical thinker?” You engineer situations that force the signal out. The truth shows under pressure, never under a direct question: what someone cannot re-derive on the spot, they do not actually know.
The non-negotiables: probe and verdict. These surface inside the coding problem itself, not in a separate values interview.
| Filter | The move that forces it out | Pass | Fail |
|---|---|---|---|
| Critical thinking | ”Why does this work? What would break it?” Make them re-derive. Slip in a wrong premise and see if they catch it. | Re-explains from scratch, challenges the bad premise | Recites a pattern, cannot say why, accepts the wrong premise |
| Honesty | Push past the edge of what they know; ask them to explain something they claimed | Says “I don’t know” plainly | Bluffs, hand-waves with confidence |
| Ownership | Go quiet and give minimal guidance | Drives it forward, proposes the next step | Stalls, waits to be led |
| Low ego | Give one good hint and one wrong-headed hint | Takes the good, pushes back on the bad with reasoning | Defensive on the good, or blindly follows the bad |
| High agency | Inject a blocker or an ambiguity | States an assumption and proceeds | Freezes until unblocked |
Digging deep on problem solving. You read level from how far they get and how hard you had to push, so push in steps and watch where they stall:
- Restate, do not re-explain. Give the bare problem and stay quiet. Do they ask the clarifying questions that matter, or charge in?
- Approach before code. Ask how they would approach it. If they jump to typing, pull them back; you are testing thinking, not typing.
- Brute force first. “What is the simplest thing that works, even if slow?” Confirms they can actually solve it.
- Push for optimal. “Can we do better? Where is the bottleneck?” The size of the nudge it takes is the level signal: a Senior needs almost none, an Intern needs you to point at the data structure.
- Probe the why. “Why is that O(n log n)? What dominates?” Re-derivation, not recall. This is where pattern-matchers fall apart.
- Curveball a constraint. “Now the input does not fit in memory.” Tests reasoning from structure versus a memorized answer; the memorizer freezes, the thinker adapts.
- Withhold hints on purpose. Hint only when truly stuck, and note how big a hint was needed. That note is the score.
Probing the other three dimensions.
- Communication: make them drive the explanation. If you have to ask “why” to follow along, that is a dropped point. Test hint-incorporation by giving a deliberately vague nudge and seeing whether they find the path from it.
- Coding: watch them translate their own stated plan, not a fresh idea. Readable means you can follow it without narration. Let a small bug ride and see whether their verification catches it.
- Verification: never prompt “did you test it?” The signal is whether they reach for a dry run and edge cases on their own. Having to prompt it tells you they will not do it on the job either.
The Bar per Level#
The same signals, read at four levels. Cells describe what you actually see in the room.
Communication
| Signal | Intern | Junior | Mid | Senior |
|---|---|---|---|---|
| Question understanding | Asks a clarifying question or two when prompted | Restates the problem in their own words before starting | Surfaces ambiguities and constraints unprompted | Reframes to the real requirement behind the prompt |
| Incorporating hints | Applies a direct hint | Corrects course from a nudge | Integrates feedback into the approach, not just the line | Often pre-empts the hint, asks for the constraint they need |
| Explaining and visualizing | Narrates what they are typing | Walks through the approach before coding | Sketches the data flow and explains tradeoffs | Explains so you never have to ask “why” |
Problem Solving
| Signal | Intern | Junior | Mid | Senior |
|---|---|---|---|---|
| Breaking it down | Needs the problem decomposed for them | Breaks it into steps with some guidance | Decomposes cleanly on their own | Finds the core sub-problem others miss |
| Brute force to optimal | Reaches a brute-force solution with some hints | Brute force on their own, optimal with hints | Reaches optimal with light hints | Reaches optimal largely unaided, weighs alternatives |
| Time and space | States complexity when asked | Analyzes time and space when prompted | Reasons about complexity unprompted | Optimizes against the real constraint, knows when good enough is right |
Coding
| Signal | Intern | Junior | Mid | Senior |
|---|---|---|---|---|
| Idea to code | Turns a clear, given plan into working code | Codes the plan with minor stumbles | Smoothly turns the approach into working code | Code matches the stated plan on the first try |
| Readability | Works, but messy naming and structure | Reasonable names and structure | Clean, idiomatic, easy to follow | Reads like prose, the next engineer needs no explanation |
| Bug-free | Some bugs, finds them on a dry run | A few bugs, catches most on review | Mostly correct, handles the common cases | Correct by construction, few bugs even at the edges |
Verification
| Signal | Intern | Junior | Mid | Senior |
|---|---|---|---|---|
| Dry run | Runs the happy path when prompted | Dry-runs the main path on their own | Traces the code against several inputs | Verifies the invariant, not just the example |
| Test cases | Tries the given example | Adds a couple of sample cases | Writes cases that cover the branches | Writes the test that would catch the subtle bug |
| Edge cases | Misses most edge cases | Names the obvious ones (empty, null) with a nudge | Enumerates edge cases unprompted | Finds the edge case that breaks the naive solution |
Lead and above: hiring shifts from the coding screen to scope, judgment, and influence, a different loop run by leadership, not scored on this rubric.
The Loop#
Screen the application, send a take-home, run one interview, then call it. This is the Product Engineer worked example; PM and PD run the same shape with their own case.
Who to Interview#
Screen for signal, not pedigree. Advance a candidate when the application shows they have built things on their own (projects, not just coursework), a trace of how they think (a writeup, a repo with real commits, a stated reason for a choice), and curiosity and ownership in how they describe past work (“I noticed X, so I tried Y”). Pass on: only coursework, no evidence of building, or someone who lists tools but has never shipped anything.
The Take-Home#
The candidate-facing prompt is at systeric.com/careers/product-engineer-test (unlisted), and the take-home email links to it. The same problem runs for every level; the bar is what differs.
It is a mini version of how we work, not a coding puzzle. We hand them a loose problem as a short case study and they take it through the loop: frame it, decide what is worth building, prototype the core, and show how they would know it works. The current case: Maya, a small online clothing shop owner, drowns in repetitive customer questions in one chat inbox, hours, shipping, returns, where’s my order (a sample log is on the page); build something that cuts the load, they decide what. We picked a deliberately universal scenario so the test reads the same intern to lead: no insider context to decode, just judgment. The case quietly plants a critical-thinking hook, “Maya’s instinct is a chatbot, maybe”: the biggest cluster (“where’s my order”) is not actually fixed by faster answers, so a candidate who only auto-replies has missed the real lever. To stop weaker candidates freezing on the open brief, the page offers a default starting point (a script that drafts replies to the repeats) and says plainly it is not marked down; the extra credit is reserved for those who question whether that default is even the right lever.
They send back three things: a brief (about a page, the thinking), a prototype of the core (the single most important piece as one small script, no UI, runnable on the sample), and proof it works (tests, a recording, or logged runs over the messy cases). The brief is the point. We read product judgment and how they would operate the thing, not a polished UI. We cap the whole thing at three to four hours and tell them so: it is a thinking exercise, not a build-a-whole-app test. Rough code with a sharp brief beats a slick build with a thin one, because the second is usually AI without understanding.
Rotate the case periodically (edit the page) so it does not leak. Keep any new one in the same shape: a loose, universally legible problem with signal to mine, that they have to frame, prototype, and operate.
Grading the Take-Home#
The take-home maps to the product engineer attributes. Score each 0, 1, or 2; the scores read the same for everyone, the bar is what rises with the level. (Leverage is near zero this early, so we do not score it.)
| Attribute | Reject (0) | Weak (1) | Strong (2) |
|---|---|---|---|
| Product sense | Built something with no sense of the real problem or who it is for | Solved the stated problem, did not really decide what to cut | Framed the real problem and the user, picked a sharp slice, said what they left out and why |
| Critical thinking | Took the input at face value | Did the obvious analysis | Dug past the surface, found the real driver, questioned whether their own solution is even the right one |
| Engineering craft | Does not run, or a copy-paste tangle | Works, minimal, readable enough | The smallest thing that works, clean, sensible tech choices |
| Delivery & operations | No metric, no monitoring, no proof it works | Named a metric and gave some proof | Named the metric to watch and what to instrument, the failure modes and how to catch them, and gave real proof over the messy cases |
| Communication | No brief, or unreadable | The brief states what they did | The brief reads clearly the first time and defends the why |
| Ownership | Asked for a spec, or built only the literal minimum | Took the problem and ran with it | Owned the open problem end to end, made the calls, surfaced the risks themselves |
The floor, at every level. The build runs (craft is not 0) and the thinking is real: product sense and the brief are not generic. A slick build with a thin or generic brief is a reject, that is the tell for AI without understanding.
The bar by level. Intern and junior: a sound frame, a working prototype, and a basic metric and proof clears it; they may miss the deeper edges, you are reading trajectory. Mid: found the real driver, clean build, real monitoring thinking, on their own. Senior: reframed the problem (maybe a bot is not even the answer), sharp scoping, production-grade ops thinking. Lead: treats it as a system, what to standardize, how it scales, how to make it safe for a team. To grade a submission against a level, run /score-pe.
The Interview (45 to 60 Minutes)#
One conversation, three parts. You are testing the mind, not the syntax.
- Warm up (5 min). Put them at ease. One question about a project they care about. Listen for ownership and genuine interest.
- Walk and extend the take-home (30 to 40 min). The core. Have them walk their brief and build, then apply the same digging-deep technique to their own submission: make them re-derive the choice (“why this slice, what did you cut, how would you know it worked”), slip in a wrong premise, add a constraint they did not plan for (“now the questions come in three languages”, “now it is ten times the volume and half is noise”, “the right answers go stale every week”), and withhold hints until they stall, noting how big a hint it took.
- Their questions (5 to 10 min). What they ask tells you how they think and whether they have agency.
You are scoring the four rubric dimensions above (communication, problem solving, coding, verification) and the non-negotiables (critical thinking, honesty, ownership, low ego, high agency). Read it at the level they applied for: for the trunk (intern to mid), expect to give hints and read trajectory and coachability; for senior and lead, the bar is higher, they should reframe, find the non-obvious, and need no hand-holding.
Making the Call#
- Score with evidence, not vibes. For each dimension, write the specific moment that justifies the score. “Felt strong” is not a score.
- A failed non-negotiable ends it. Any hard filter failed is a no-hire, even with a great rubric score. Note where it showed so the debrief stays concrete.
- Hire at the level the evidence supports, not the one they applied for. The hint-amount calibrates it: Senior-level hints with Mid-level performance is a Mid.
- Coachability over polish, for the trunk. Intern to Mid, trajectory and coachability matter more than a polished result.
- No advancing on potential, for Senior and above. They must show the senior or lead behavior directly, in the room, not promise it later.
- When genuinely torn, no-hire. A wrong hire costs the team more than a slow search, and that cost lands on everyone around them.
How It Maps to Growth#
Each rubric dimension predicts a capability in the competency matrix, so a strong screen is also an early read on where the person will grow.
| Rubric dimension | Predicts (in the matrix) |
|---|---|
| Problem Solving | Discover’s “Getting to the root” and Define’s “Solution design” |
| Communication | The cross-cutting “Communication” |
| Coding | Build’s “Standards and quality” |
| Verification | Build’s “Ship discipline” and Launch’s “Watching and mitigation” |
The competency matrix is where a hired engineer then grows, dimension by dimension, from the bar they cleared on the way in.
Email Templates#
Copy these and fill in the brackets. The take-home email links the test page. The interview invite goes to whoever clears the take-home. The rejection works whether they did not pass the test or did not pass the interview. The offer covers any level. To grade a submission against a level, run /score-pe and paste it in.
Send the Take-Home#
Subject: A quick take-home from Systeric Hi [name], Thanks for applying. Before we talk, we'd love you to try a short take-home. It's a small run of how we actually work: a real case you frame, prototype, and show how you'd run. Plan for three to four hours, no more. It's a thinking exercise, not a build-a-whole-app test. Any language and any tools, AI included. Here's the case: https://www.systeric.com/careers/product-engineer-test Reply with three things: a brief (about a page) on the thinking, a small prototype of the core (one script, not an app), and proof it works (tests, a recording, or logged runs). If you can get it back within a week that keeps things moving. Any questions, just reply. Cheers, [your name] Systeric
Invite to the Interview#
Subject: Your take-home stood out, [name] Hi [name], Your take-home stood out, and we found it genuinely interesting. We'd love to dig into it with you. It's one conversation, around 45 to 60 minutes, and it feels more like a working session than an interview. We spend most of it on what you built: you walk us through your thinking, then we get into it together, turning the problem over, trying angles, seeing where it leads. When we challenge an idea, we're not testing you, we're thinking with you, the way we would if we were building this for real. Nothing to prepare. Bring your take-home and your thinking, and we'll figure out the rest together. Reply with a few windows that work for you over the next week [or book a slot here: [link]] and we'll set it up. Any questions, just reply. Cheers, [your name] Systeric
Rejection (Test or Interview)#
Subject: Your Systeric application Hi [name], Thanks for the time you put into this. We've decided not to move forward this time. It's a hard call and not a knock on your potential. We keep the bar high because we commit to growing everyone we bring in, and we can only do that for a few at a time. We'd genuinely welcome you to apply again down the line. Wishing you the best. Best, [your name] Systeric
Acceptance and Offer#
Subject: An offer to join Systeric Hi [name], We'd love to have you join Systeric. Your thinking stood out, and we're excited to grow with you. The offer: - Role: Product Engineer, [level] - Start: [date] - Comp: [details] [Interns: the path is a one-year apprenticeship, intern to a strong mid-level engineer, with us investing in you the whole way.] If it works for you, reply to accept and we'll send the paperwork. Any questions at all, just ask. Welcome aboard, [your name] Systeric
Related: Product Engineer, Internship Program, PE Apprenticeship