Systeric / Docs Open App →

Hiring & Internship

Two things, both internal: how we hire, and the intern apprenticeship we grow people through. 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 Product Engineer case below is the worked example; PM and PD run the same loop with their own case (draft: confirm the discipline-specific case per role).


Hiring product engineers

A short take-home, then one interview. The rubric and the non-negotiables we score against live in Hiring.

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: which level does it clear?

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.)

AttributeReject (0)Weak (1)Strong (2)
Product senseBuilt something with no sense of the real problem or who it is forSolved the stated problem, did not really decide what to cutFramed the real problem and the user, picked a sharp slice, said what they left out and why
Critical thinkingTook the input at face valueDid the obvious analysisDug past the surface, found the real driver, questioned whether their own solution is even the right one
Engineering craftDoes not run, or a copy-paste tangleWorks, minimal, readable enoughThe smallest thing that works, clean, sensible tech choices
Delivery & operationsNo metric, no monitoring, no proof it worksNamed a metric and gave some proofNamed the metric to watch and what to instrument, the failure modes and how to catch them, and gave real proof over the messy cases
CommunicationNo brief, or unreadableThe brief states what they didThe brief reads clearly the first time and defends the why
OwnershipAsked for a spec, or built only the literal minimumTook the problem and ran with itOwned 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.

  1. Warm up (5 min). Put them at ease. One question about a project they care about. Listen for ownership and genuine interest.
  2. Walk and extend the take-home (30 to 40 min). The core. Have them walk their brief and build, then push. Restate: “What problem were you actually solving, and who for?” Why: “Why this slice? What did you cut, and how would you know it worked?” Make them re-derive, do not let them recite. Wrong premise: slip one in and see if they catch it. Extend: add a constraint (“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 watch them reason from structure, not memory. Withhold hints: when they stall, give the smallest hint that unblocks them, and note how big it had to be.
  3. 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 (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.

The decision

Score with evidence, not vibes, one concrete moment per dimension, then place and call it with Hiring, the single source for the bar and the call: a failed non-negotiable ends it (critical thinking most of all, recognizing the answer without being able to re-derive it is a no-hire), coachability over polish for the trunk, and no advancing on potential for senior and lead.


The intern program

We also run an intentional apprenticeship. An engineer joins as an intern, grows fast through real work, and after about a year graduates as a capable mid-level engineer. High churn is the design, not a failure. We would rather grow excellent engineers quickly and send them on than hold seats. The team stays sharp, the bar stays high, and we build a network of alumni who learned to build the Systeric way.

About twelve months, two halves, then graduation. The rungs are the same ones in Product Engineer; this is the timeline for climbing them.

PhaseWindowFrom toThe move
ApprenticeMonths 0 to 6Intern to JuniorStop needing every step spelled out. Take a scoped task to done on your own.
BuilderMonths 6 to 12Junior to MidStop needing the problem handed to you. Turn a symptom into a Build-ready definition and ship it.
GraduateAround month 12Mid, and outA capable mid-level engineer who owns a problem end to end, unsupervised.

These are targets, not guarantees. Some move faster, some need longer; the transitions are earned against the Product Engineer bar, not the calendar. But the calendar is the plan, and drifting far past it is a signal to address, not ignore.

Months 0 to 6, Intern to Junior. Go from executing tasks to owning them. Read Core end to end, then Product Engineer, in that order. Do well-scoped tasks with the acceptance criteria spelled out, then scoped stories end to end as judgment builds. Pair often early, because the tight 1:1 cadence is how norms transfer before they have their own sense of what good looks like here. Ready for Junior when they take a scoped task to completion without being told each step, deriving their own acceptance criteria from the definition doc.

Months 6 to 12, Junior to Mid. Go from working inside a defined problem to defining the problem yourself. Own Discover on small problems before the Define session; take a reported symptom and produce the problem statement; own a feature from problem to shipped and measured. Grow the judgment spokes, critical thinking and product sense, plus delivery discipline (flags, instrumentation, mitigate before investigate). In the second half you also start giving back: help the next cohort through their first six months, pairing on their early tasks, answering their questions, reviewing their PRs. This is your first real Leverage, the attribute that carries you from Junior to Mid, and teaching the basics is how you prove you own them. It also builds the social capital that outlasts the internship, so do not keep score. That mentoring is part of why a year here graduates a Mid, not a Junior: an engineer who lifts the people around them is already working above their own tasks. Ready for Mid when they take a symptom, frame the real problem, own the definition, and ship it unsupervised.

Graduation. At around a year, a graduating intern is a mid-level engineer: they own a problem end to end, unblock themselves and others, and ship complex work cleanly without supervision. Graduation is a real send-off, not a quiet exit. We help them land their next role, and they stay part of the network.

How we run it. Manager 1:1s weekly for the first month, then biweekly, plus a daily onboarding-buddy 1:1 early on that tapers as they find their feet (the day-to-day schedule and guardrails are in PE Apprenticeship; see also Leading People). Each intern has a Product Engineer radar, and the growth move is the usual two: feed the spike, clear the one blocker holding them below the next rung. Delegate one rung ahead, then close the gap with review. No surprises: the half-year transitions are discussed continuously, never sprung. If someone is behind at month 5, they have known since month 3.


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

Invite to 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

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)

Rejection
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

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: PE Apprenticeship, Hiring, Product Engineer, Leading People