Skip to content
Evalzo

REQ-1042 · Full Stack Engineer

Open

Job description

Required skills

    Role details

    Scores use only assessments linked to REQ-1042 ·
    Designer notes Assumptions, open product decisions and two alternative layouts · prototype only

    Scoring assumptions

    • Illustrative formula: rollup = weighted mean of every scored assessment linked to this requisition, /10. Weights are HR-controlled per requisition (board column header → weight chip). The editor is a draft: values you type are Fixed (lock), Adjust remaining splits the rest of 100% equally among unfixed ones with integer rounding so the total is exactly 100, Reset to equal weights clears all locks, and nothing re-scores until Apply (enabled only at 100%). Validation: fixed values over 100% are never changed silently, and an all-fixed total that is not 100% asks you to edit or unlock. 0% assessments never contribute: a candidate whose only scored assessments carry 0% shows "No weighted score yet" rather than an unweighted average or zero (try Written screening 0 · Technical interview 100 · Interview: 02 0 and look at Nila Das). A candidate's missing assessments are left out and the remaining weights re-proportioned. Example sequence with four assessments: type 10 → Adjust → 10/30/30/30; type 50 on the second → Adjust → 10/50/20/20. Open for product: whether weight changes should re-score candidates who already have a recorded decision, and whether weight history needs an audit trail. The production rollup formula needs confirmation; existing screens show different score labels and values (for example "Rollup score 4.9").
    • Overall assessment score is not role match and not AI confidence. Those are separate measures and are not shown here.
    • No completion target. There is no fixed number of assessments per requisition, so the page never shows "n of N complete". Each rollup score carries the number of assessments behind it (for example "9.1 · 1 assessment") so reviewers can weigh a single-assessment score against a three-assessment one. Missing assessments are never counted as 0.
    • Score sort ranks every candidate with a rollup score; candidates with no score sit at the bottom in both sort directions. Equal scores simply sit next to each other. Open point for product: whether a score backed by one assessment should rank above one backed by three, or be visually de-emphasised.
    • Only assessments linked to REQ-1042 contribute. Draft assessments have no results and are not counted.
    • No "final" assessment and no "rounds". Evalzo does not define how many interviews a candidate will have; assessments are added per person, and the product has no concept of rounds, so the word is not used anywhere on the page. The prototype therefore never labels an assessment "final": the third linked assessment is simply "Interview: 02" and activity text says "Latest interview scored". The "Completed x/3" column and the provisional grouping were removed for the same reason.

    Lifecycle decisions to confirm

    • Candidate status follows the attached status flow: Invited → In progress → In review (or Not attended), then a recruiter decision of Shortlisted or Not selected, which needs at least one in-review attempt. Status is computed per candidate and requisition from attempts, so there is no "Added" state: adding candidates and their first invitation happen together.
    • Interviews block closure. Mark as filled first checks for scheduled (video · Invited) or live (video · In progress) interviews. If any exist, a blocking dialog lists candidate, assessment, time and state with Review interviews and Back to requisition; there is no "fill anyway". Scheduled interviews are cancelled from the interviews list with an explicit confirmation naming candidate and round, a notification preview, a notify toggle and a simulated delivery status (or a simulated failure that leaves everything unchanged). A live round is never ended, cancelled or completed by closing the requisition; the prototype offers a clearly labelled "Simulate call ended" button (illustrative score) so the successful path can be walked through. Demo: open Mark as filled (blocked by Nila live + Kabir scheduled) → Review interviews → Cancel Kabir's (try Simulate failure first) → Simulate Nila's call ended → Mark as filled proceeds.
    • Once interviews are resolved, Mark as filled is never blocked: the goal of a requisition is to fill its openings, and a hire may happen outside Evalzo. The dialog warns when nobody is shortlisted (offering to shortlist first) or when fewer are shortlisted than there are openings, lets the recruiter record how many openings were filled, and requires a reason whenever nobody is shortlisted or not every opening is filled; the reason is shown on the filled requisition. Confirming marks every undecided candidate Not selected and every ongoing assessment Completed (reopening reverts those assessments to ongoing). Earlier wording: shortlisted candidates and linked assessments are unchanged; The dialog names who is affected and asks for acknowledgement. Requisition states are Draft → Open (internally "ongoing") → Filled or Archived; any invitation or attempt moves Draft to Open automatically.
    • Filled requisitions keep full history; add, invite and decision actions are disabled with an explanation and reports stay readable.
    • Rebuild from a JD inside Edit. The edit dialog opens with an upload-or-paste block that mirrors the create-requisition flow: the document (or pasted text) is parsed into title, department, location, work arrangement, employment type, required skills and description; a field-by-field preview shows current vs extracted with per-field opt-out; Apply only refills the form and Save commits. Openings are never read from a document. Because editing is only possible before any candidate activity (rule below), a rebuilt JD cannot invalidate existing scores. Open for product: whether to keep the previous JD as a version for audit.
    • Editing the role is frozen once anything has progressed. Title, job description, required skills and role details can be edited only while every linked assessment is still a draft and no candidate has been invited or assessed. After that the Edit button and the Edit requisition menu item are disabled, and hovering Edit explains why with the current counts (for example, 12 candidates have been invited or assessed and 3 linked assessments are ongoing). Reports, scores and invitations already reference the role, so a change would invalidate them. Open for product: whether a narrow set of fields (owner, openings, hiring manager) should stay editable, since they do not affect scoring.
    • Draft, Open and Archive. Draft means nothing is linked at all: no assessments, no candidates. Linking an assessment moves the requisition to Open even before anyone is invited. Archive is available until candidate activity begins: a bare draft archives with a plain confirmation; an open requisition with linked assessments shows which assessments are reserved by it and requires a reason, shown on the archived requisition. Once candidates are invited it is closed with Mark as filled, never archived. Archived is fully read-only and shows no candidates; Unarchive returns it to Draft or Open depending on what is linked. The "Empty requisition" prototype state is an Open requisition with assessments linked and no candidates.
    • The invite picker infers the assessment sequence from this requisition's own history (the order in which candidates completed assessments) and suggests the next step for the selected candidates. It is a heuristic, not a configured pipeline: with few candidates or mixed orders it may suggest nothing, in which case the list simply shows what has been used. Organisation-wide assessments are listed last and are linked on send.
    • Assessment setup is where the requisition's assessment set grows: link an existing organisation assessment or create a new video interview, without inviting anyone yet. Unlink is only offered while no candidate has a record, so history is never silently dropped.
    • AI comparison summary (prompt design). The card above the Overall table is regenerated whenever the compared set changes (add, swap, remove), with a short loading state so the change is visible. Prototype text is rule-generated from the same evidence the real prompt would receive. Inputs the prompt must get: requisition title, job description and required skills; the current rollup weights; for each compared candidate only the assessments linked to this requisition — per-assessment score, criteria scores, result date, status (in review / invited / in progress / not attended / not assessed), the report's strengths and open questions with their source references (assessment · question); and the candidate's requisition status. Hard constraints in the system prompt: compare only on the evidence provided and never on name, background or anything outside the reports; never recommend hiring, shortlisting or rejecting, and never use "best" or rank language beyond what the rollup rule already states; name the assessment and criterion behind every difference; say explicitly when evidence is not comparable (fewer assessments in review, missing or pending results) instead of filling the gap; cite each claim with its source reference; at most 120 words, in the fixed order headline → where they differ → evidence gaps → open questions → suggested next step; the next step is a review action, not a decision; plain, measured Evalzo voice. Output: structured JSON (headline, differences[], gaps[], open_questions[], next_step, citations[]) rendered by the UI, so the layout never depends on free text. Operational: cache by the set of candidate ids + weights hash; show "based on N reports" and generation time; Regenerate re-runs with the same inputs; Helpful / Not helpful feedback is stored with the inputs for prompt tuning; refuse to summarise when fewer than two candidates have a report. Open for product: whether criteria scores or recency should carry weight, and whether the summary may quote candidate answers verbatim.
    • Comparison recommendation is deliberately quiet. A small teal check on the avatar marks one candidate; hovering it explains why. Rule: among the compared candidates with the most assessments in review, the highest rollup wins; a lead under 0.05 is a tie and nobody is marked; a candidate with fewer assessments in review is never recommended on a higher partial score (Nila Das on one assessment is named in the tooltip as not yet comparable). Wording keeps the decision with the hiring team. Open for product: whether the recommendation should also weigh criteria scores or recency.
    • Invite follows the assessment page's own flow. For a video assessment the dialog schedules one slot per candidate (date, time, shared duration defaulting to the assessment's, time zone), names the interviewer whose calendar sends the invite, lets you pick the meeting provider (Google Meet via Google Calendar is the default; Outlook is an open integration question; Zoom is a pasted link), always adds the listening agent as a guest, and includes the assessment's candidate instructions. Edge cases handled: no candidate instructions (blocked until added), unpublished or Completed assessment (blocked), slot in the past, interviewer already booked at that time (Kabir Jain · Interview: 02 on Mon 13 Oct 15:00), two slots in one batch overlapping, outside 09:00–18:00 or weekend (flagged, allowed), reminders re-send the existing event with no new slot, "Same slot for all" helper, slots kept while switching assessments. For a written assessment the dialog sets an availability window (opens / closes / time zone) capped by the assessment's own closing date, a 48-hour reminder, and explains the invite-only personal link and proctoring. The real send happens in the recruiter's calendar in production; the prototype simulates it.
    • One invitation rule everywhere. The board's rule (a candidate with an active invitation or an assessment in progress cannot be invited to another assessment in this requisition; recorded decisions and already-taken assessments also block) now governs the invite dialog from the row menu, the bulk bar and the board. Recipients are split into Eligible and Blocked with a reason per person; the Send button counts only eligible people and separates reminders (already invited to the chosen assessment) from new invitations; nothing can be sent when nobody is eligible. Demo: select Nila Das alone and choose Interview: 02 (entirely blocked: Technical interview is still active); select Nila Das and Tara Roy and choose Interview: 02 (mixed: Tara eligible, Nila blocked) or Technical interview (Tara new invitation, Nila reminder).
    • Invite lists only this requisition's assessments (an assessment belongs to exactly one requisition and cannot exist unlinked), suggested next step first, then the rest in the order candidates take them. Creating a new assessment is a secondary hand-off to Create assessment, after which it appears in the list. Earlier version: Invite could create a new video interview on the spot (for example moving one candidate into a further interview while others stay at two). It is deliberately limited to video interviews; written assessments keep their authoring flow on the Assessments page. Whether the new interview should reuse a question set by default is open.
    • Share reports (bulk bar) generates one public profile link per selected candidate using the existing share-from-profile feature and its visibility toggles, then lists the links for copying or an email draft. No combined public report and no new permission model. Two things to confirm with product: whether a public profile link should be scoped to this requisition's activity only (today the profile shows every requisition), and whether links should expire or only be revoked manually.
    • Openings filled is tracked separately from Shortlisted. The header shows "0 filled" until a hire is recorded.

    Alternative layouts to consider

    A · Compact report-style rowsEach candidate row becomes a two-line report card: name and status on line one, three small assessment scores inline on line two (e.g. 9.0 · 8.7 · 8.7). Removes the evidence drawer for the common case, at the cost of a taller table. Best if reviewers mostly scan round-level detail.
    B · Stronger progress overviewAdd a stacked funnel bar (Added → Invited → In progress → In review → Decided) plus a per-assessment completion chart between the job description and the table. Better for pipeline health; weaker for the "who is best" question. An earlier version used four count tiles that doubled as view filters; that was removed in favour of a single candidate list grouped by score availability.

    Visual assumptions

    • Row action is "View latest report": it opens the most recent scored report in the right drawer, with "Back to [name]" returning to the candidate's evidence view. Clicking the name or avatar opens the candidate profile page (separate screen, simulated here). The score itself still opens the evidence view.
    • Matches the live app seen in the walkthrough: floating top nav, breadcrumb, rounded status pills, teal primary button, white cards on a light canvas.
    • Content column capped at 1400px so the comparison table stays aligned on large monitors. No new application sidebar.
    • The job description sits under the header as a clamped card with a "Show full description" toggle, so the role stays in view without a separate tab and without pushing the candidate table down.
    • Status labels are the six from the flow: Invited, In progress, In review, Not attended, Shortlisted, Not selected. Video attempts map to the same labels (scheduled → Invited, recording → In progress, done → In review, failed or cancelled → Not attended).
    • All people, emails and scores are fictional; emails use example.com.
    Prototype states · v68