Assessment method reviewed September 2026. To vet a remote senior engineer, watch them make and revise decisions in unfamiliar code, then record evidence across system reasoning, implementation, AI use, communication, collaboration and code they can defend. Resume, trivia and polished take-home cannot replace observed work.
Why take-homes select for free time
Take-home exercises select partly for who can donate uninterrupted time, polish presentation and optimize for hidden rubric. They can reveal written code, but they do not show which questions candidate asked, how they reacted to correction or which parts came from outside help. Remote seniority depends on those behaviors.
A strong candidate with caregiving, current job or limited weekend time may submit less polish than candidate able to spend twelve hours on “two-hour” task. Unless environment records real effort, reviewer cannot normalize. Time cap stated in email does not enforce itself.
Take-homes also permit invisible process. Candidate can search, ask another person, use AI or copy prior solution. None is automatically wrong; engineers use tools at work. Problem is lack of observability. Reviewer sees artifact but not whether candidate verified output, recognized risk or understood code.
A company can improve take-home by paying for it, setting hard time box, accepting incomplete work and discussing decisions live. It still remains weak as primary gate when role needs collaboration and production judgment. Use it for portfolio-style evidence only when task format itself matters.
Live pairing offers fairer bounded observation. Candidate and assessor share same two hours, same codebase and same constraints. Candidate may use normal tools, including docs and AI, while assessor watches how evidence changes decisions. Goal is not speed typing; goal is legible reasoning under uncertainty.
Remote format is an advantage when role is remote. Screen share, audio, editor, search and communication resemble real work more than whiteboard. It also exposes setup and explanation habits. Accessibility needs remain: send format ahead, allow preferred editor and separate language fluency from engineering signal.
What a two-hour pairing session reveals
A two-hour pairing session reveals how candidate enters unfamiliar system, chooses what to inspect, forms hypothesis, uses tools, communicates uncertainty and closes loop with verification. It is long enough for initial confidence to meet real constraints, yet bounded enough to compare candidates fairly.
First twenty minutes show orientation. Senior engineer asks about user impact, constraints, current failure and safe test path. They inspect nearby code before proposing architecture. Lack of questions can signal confidence, but often signals unexamined assumptions.
Middle hour shows implementation and recovery. Give task with one genuine edge: partial failure, state boundary, slow list, unsafe migration or missing eval. Watch candidate construct model, create failing evidence and revise. A perfect path reveals less than a reasoned correction.
Final period should include review. Ask candidate to explain risk, what remains, how they would deploy and what they would monitor. Senior work is not complete when code compiles. Rollback, observability, migration order and reviewer context distinguish feature typing from production ownership.
Assessor should intervene like colleague, not silent examiner. Answer domain questions, challenge one decision and offer one ambiguous suggestion. Observe whether candidate accepts authority blindly, argues performatively or tests premise. Collaboration signal appears in how disagreement changes work.
Use role-relevant code. Full-stack assessment should cross schema, API and interface. Platform role should include operational risk. AI role should require evaluation, not prompt theatre. Generic algorithm puzzle measures preparation for puzzle more than work team needs.
Session also validates overlap. Engineers through wepair.works agree four to six hours of overlap with US working hours; pairing confirms audio, communication and live collaboration during that window. It should not grade accent. Clear written and spoken reasoning matters; imitation of US conversational style does not.
Six axes we score
Six axes create consistent verdict without pretending one number captures seniority. Each axis records evidence and limits. Strong system reasoning cannot erase weak collaboration; fast implementation cannot erase unsafe AI use. Role can weight axes differently, but omissions stay visible.
| Axis | Evidence we seek | Common false positive |
|---|
| Systems reasoning | Finds boundary, failure mode and tradeoff | Repeats architecture vocabulary |
| Working session | Tests hypothesis and ships safe change | Types quickly on familiar pattern |
| AI-assisted development | Verifies generated output and owns result | Produces more code |
| Code they defend | Explains past decision and changed view | Tells polished success story |
| Written communication | States problem, risk and next decision | Writes long prose |
| Collaboration signal | Challenges, listens and revises | Agrees with assessor |
Systems reasoning asks what breaks first and why. Candidate should map data, concurrency, dependencies and operations at depth role needs. We care less about naming perfect technology than identifying constraint and consequence.
Working session asks whether person can turn model into evidence. Good pattern is hypothesis, failing check, narrow change and verification. Senior candidate may deliberately avoid completing broad task because safe slice matters more. Score judgment, not feature count.
AI-assisted development asks whether candidate treats output as untrusted contribution. They should choose tasks suitable for AI, read result, test assumptions and explain ownership. Banning AI hides behavior company most needs to inspect.
Code they defend uses real past work. Ask for decision, alternatives, surprise and what they would change now. Senior engineer with no regrets may be protecting story. Changed mind with specific consequence is stronger evidence.
Written communication asks for a brief after session: problem, approach, risk, unresolved question and deployment plan. Remote teams live in durable text. Grammar imperfections matter less than whether reader can act.
Collaboration signal asks how candidate handles disagreement and missing context. Strong candidate can hold position, surface evidence and concede narrower point. Aggression is not conviction; compliance is not teamwork.
What a written verdict must contain
Written verdict must contain recommendation, role context, evidence per axis, what candidate got wrong, what was not tested and how to work with them. Client should see uncertainty before deciding interview, not receive score stripped of reasoning.
Recommendation uses plain language: shortlist, hold or pass. It names caveat that could change decision. “Strong candidate” is not useful if role requires Kafka ownership and candidate has never run Kafka. Verdict ties gap to actual need.
Evidence uses observed actions. “Good communicator” becomes “stated transaction assumption, changed it after counterexample and wrote risk in handoff.” “Strong backend” becomes exact failure mode found, test written and tradeoff defended. Specifics let client disagree.
Wrong answers belong in verdict because correction reveals seniority. Candidate may choose wrong index, trust generated migration or assume idempotency boundary incorrectly. Record whether they discovered error, accepted feedback and repaired model. Hiding misses turns assessment into advertisement.
Untested areas protect scope. Two hours cannot validate incident command, every stack, management or compliance experience. Name gaps. Client can test one in own live interview or decide evidence suffices. Silence invites overclaim.
Work guidance converts assessment into onboarding. Candidate may need written invariants, morning overlap, direct product access or explicit on-call boundary. That is not excuse; it is operational information manager can use.
What the write-up says when someone fails
A failing write-up says no and explains evidence without humiliation. It separates role mismatch from general worth. Candidate can be capable engineer and wrong for requirement. Client should understand gate, and candidate deserves feedback that does not invent certainty.
Failure may be unsafe reasoning: changed data without rollback, ignored partial failure or could not verify output. It may be collaboration: refused constraints, accepted every suggestion or concealed uncertainty. It may be scope: strong frontend engineer interviewed for infrastructure ownership they do not have.
Verdict should not diagnose personality from one session. “Arrogant” becomes observed behavior: interrupted clarification, would not inspect counterexample, persisted after failing evidence. “Not senior” becomes missing decisions relative to role. Concrete language is more defensible and more useful.
wepair.works publishes a sample vetting write-up showing scored axes and misses. Through our Latin American hiring process, founder runs session and client receives write-up before interview. No account manager edits it to improve conversion.
If candidate fails, do not keep them in hidden maybes indefinitely. Close loop, preserve consent around notes and avoid reusing personal evidence beyond purpose. Assessment quality includes treatment of person when answer is no.
Decision: observe real work, score stable axes and publish reasoning to decision-maker. Seniority appears in choices, corrections and communication. Remote vetting works when process makes those behaviors visible rather than rewarding rehearsal.