Articles
Testlify Coding Assessment: Single-File Tasks, Projects, and Scoring Rules
Understand Testlify single-file, SQL, and project tasks, including configurable all-or-nothing versus test-case scoring and manual project review.
Testlify can host very different coding assessments: a single-file function, a multi-file project, a database question, or a live coding session. The format matters because the platform's employer-facing documentation describes different evaluation paths. For a single-file question, an employer can choose whole-question or per-test-case scoring; a project may be manually evaluated. Before you optimize for partial credit, identify the task type and read the exact scoring and navigation instructions in your invitation.
For a separate rehearsal, try Implement Three Assessment Functions.
Which coding task are you facing?
Official Testlify documentation: Its coding-test setup guide distinguishes a single-file programming question, a multi-file project, and a database question. A single-file question can include starter code, test cases, a language, and a scoring method. A multi-file project emphasizes file organization, dependencies, and a larger working artifact. The database configuration supports SQL-style questions. A separate coding and live-coding guide describes multi-file work used in a shared live environment as well as take-home-style assessments.
Your employer chooses the question, difficulty, time allocation, and settings. A Testlify invitation is therefore not evidence that every applicant writes one algorithmic function. Read the welcome screen and the section instructions before starting. The candidate guide says the welcome screen shows the number and types of tests and estimated time; its description of section timing and navigation is especially important if the assessment mixes coding with other question types.
Evidence boundary: We did not verify independent same-cycle candidate reports sufficient to establish a common coding prompt or score threshold. The examples below are original teaching cases. They explain what Testlify's documented options would mean if selected; they do not reveal your employer's private configuration or guarantee how a particular score is used in hiring.
A source-bounded scoring map
Testlify's own pages need to be read together, not flattened into “all coding gives partial credit.” The employer-facing setup article states that single-file coding can use question-level scoring—full marks only when all cases pass—or test-case-level scoring, where passing cases can earn credit. It says database and multi-file questions use question-level scoring. The separate live-coding page says single-file work is automatically scored while multi-file work currently requires manual evaluation. “Question level” in one article describes a scoring unit; “manual” in another describes who evaluates it. Neither implies that a multi-file project uses hidden automatic unit tests in the same way as a single-file function.
| Task type in Testlify's docs | Documented evaluation detail | Candidate implication |
|---|---|---|
| Single-file coding | Employer can select all-or-nothing question-level or partial test-case-level scoring; automatic test runner is available. | Aim for a correct full solution, then use tests to identify boundary failures. |
| Database question | The setup guide says question-level scoring only. | Validate joins, nulls, ordering, and exact requested output; do not assume each query fragment gets points. |
| Multi-file project | Setup guide says question-level scoring; live-coding guide says current evaluation is manual. | Deliver a runnable project and clear handoff; do not infer a per-case progress score. |
| Live coding | The guide describes a shared coding environment with interviewer evaluation. | Explain decisions and verify behavior during the conversation. |
There is an additional documentation tension: a general test-case scoring article speaks broadly about coding questions earning marks per passing case, whereas the more detailed setup guide explicitly gives an employer a choice for single-file questions and limits other types. The narrower configuration statement is safer for planning. If your test does not disclose its scoring mode, do not assume partial credit is available; work toward correctness and use support only for a genuine rule ambiguity.
Worked scoring example: same code, different rule
Hypothetical example: A single-file task has four equally weighted test cases, each worth five points. Your submission passes two cases and fails two. Under a question-level all-or-nothing rule, the result for that question is zero out of twenty because not all cases pass. Under a test-case-level rule, it would be ten out of twenty because the two passing cases contribute five points each. These numbers illustrate the difference; they are not an actual Testlify employer rubric or a promised score display.
Now imagine the failing cases both concern empty input. It is tempting to bolt on if not input and submit. First check the function contract: does empty input require an empty collection, null, or an error? Second, rerun the successful cases after the fix. A patch that fixes two visible tests but breaks the main invariant may be worse under either scoring rule. If hidden tests exist, passing the visible set still cannot prove the full solution. The right habit is to derive edge cases from the specification, not to optimize only for the indicators you can see.
The coding setup guide describes a sample test before the real assessment and controls for running code or test cases. Use a sample opportunity, if your invitation presents it, to learn where input, output, and submission live. The candidate FAQ also says Testlify does not provide standalone personal practice outside an actual invitation. A sample within an invitation is therefore different from an open public question bank.
How to approach a single-file coding task
Original practice case, not a Testlify question: Implement normalizeIntervals for a list of inclusive integer ranges. Return merged ranges sorted by start. Two ranges merge when they overlap or touch: [1,3] and [4,6] become [1,6]. Do not mutate the caller's input. This is a useful rehearsal because it exposes input parsing, sorting, boundary conditions, and a visible test strategy.
Restate the contract before coding. Empty input returns an empty list. Reversed endpoints are either invalid or must be normalized; the synthetic prompt does not specify which, so choose and state a rule. Sort copies of the intervals by start and end, then scan, extending the last output range when the next start is at most the previous end plus one. For n ranges, sorting dominates at O(n log n) time; output and copy storage are O(n). Be careful if the chosen language's integer type can overflow when adding one. A boundary-aware comparison or larger type may be needed in a real task.
Test [], a single interval, an overlap, a touching pair, a gap of one integer that should remain separate, and two ranges with the same start. The synthetic distinction between touching and merely close is the heart of this exercise. A green example test is useful but not a proof of correctness. Work from the input contract to test cases, then run them in the platform's permitted environment. If the question's starter code defines a function signature, preserve it exactly; a correct algorithm with the wrong return type may fail every case.
Use the remaining time to inspect the smallest counterexample to a failed test. Print or trace the sorted sequence if the environment permits. Change one condition and rerun the focused case, then the full visible set. Do not rewrite the entire function under time pressure unless the invariant itself is wrong. This is sound coding practice whether the employer selected all-or-nothing or partial scoring.
For a SQL-style task, make a different checklist. Name the grain of each input table, filter before or after a join only when the intended semantics support it, and compare row counts before and after joining. Test a missing match and a duplicate match. An aggregate can look plausible while double-counting every customer with two events. Because Testlify's setup guide describes database questions as question-level scoring, a correct-looking partial query is not a reliable substitute for checking the requested output end to end. The assessment prompt, not a familiar SQL pattern, defines the answer.
How to approach a multi-file project or live review
A project is a different unit of work. The Testlify documentation describes language templates, multiple files, and manual evaluation for current multi-file coding. A reviewer may need to understand how to run your code, where the main behavior is, and what you tested. Begin by reading the provided README and existing tests. Get the project running before adding a feature. Make one small change that satisfies a complete requirement; then add or run a meaningful test. Document any dependency or setup issue instead of silently working around it.
If you are asked to create a service, pick a narrow vertical slice: route, validation, core logic, response, and one failure case. If you are asked to repair a project, reproduce the bug before touching architecture. For live coding, explain the current hypothesis, the test you will run, and what the result would mean. Because the guide describes interviewer evaluation, communication is part of the observable work. Avoid narrating every keystroke; narrate decisions and corrections.
The setup article offers a typical project duration as advice to employers, but it does not promise that your invitation grants that amount of time. Inspect your own timer and scope accordingly. A 30-minute task calls for a baseline and explicit limitations, while a longer task may justify tests and clearer handoff. Do not assume a project can be paused or resubmitted after the section ends.
Navigation and submission deserve a separate check
The Testlify candidate guide says you cannot return to a question after moving forward, skipped questions count as incorrect, and breaks are allowed between sections rather than within a started section. It says results go to the employer, not directly to the candidate. Those rules mean a coding strategy is incomplete without a navigation strategy: finish a question as well as you can before advancing, inspect the submission state, and do not depend on returning later to fix a small bug.
Before you click the final control, verify the output type, required files, and whether your latest edit was run. Distinguish “Run code,” “Run test cases,” and final submission. After the assessment, save the confirmation message and time. If there is a technical failure, report the visible error promptly through Testlify's candidate support route or the employer contact indicated in the invitation. Avoid repeated invitations or accounts unless support directs you; those are not a substitute for a clear incident record.