Articles
Canditech Assessment for Technical Candidates: Coding, SQL, and Project Tasks
Prepare for Canditech coding, SQL, and project tasks by reading your invitation, checking output rules, and practicing testable submissions.
A Canditech invitation does not identify one standard coding exam. Your assessment may ask for a function, a SQL result, or changes across a project, and those tasks reward different preparation. Start by identifying the assigned format, then practice producing the exact deliverable it requires. Solving more algorithm puzzles will not fix an unordered SQL result or a project that cannot start from its README.
This guide separates official platform documentation, a limited candidate invitation report, and original practice exercises. It does not claim a universal Canditech duration, cutoff, or question set.
Identify the task before choosing your practice
Official platform facts: Canditech's technical-hiring overview, dated August 10, 2026, distinguishes live coding interviews, multi-file coding projects, and dedicated Code and SQL questions. Code questions ask candidates to implement functions; SQL questions assess query output. A live collaborative session and an independently completed project are separate formats. These capabilities do not establish which ones your employer selected.
Read the invitation and any pre-start instructions for task types, supported language or stack, time limits, navigation rules, allowed resources, and submission requirements. If those details are absent, send the recruiter one compact clarification before starting: “Does this assessment contain function coding, SQL, a project, or a live session, and what tools and submission format are permitted?” The useful answer is the one tied to your invitation.
| Invitation clue | Practice deliverable | First thing to verify |
|---|---|---|
| Function signature and examples | A function with the required return type | Inputs, output shape, and mutation rules |
| Tables and expected columns | A query producing the required rows | Grain, nulls, rounding, and ordering |
| Starter repository or full IDE | A runnable change across project files | Setup command, tests, and submission boundary |
| Scheduled collaborative session | A solution explained while working | Session tools and communication expectations |
This is an editorial preparation matrix, not an official assessment menu. Use it to allocate effort. If SQL is confirmed, build small tables and check results by hand. If the invitation specifies an unfamiliar framework, spend time running a small project in that stack. If the format remains unknown, prepare one short exercise in each likely area instead of assuming all three will appear.
What a candidate invitation can—and cannot—tell you
One Reddit poster describing a Deloitte AI Engineer invitation reported roughly three hours, a midpoint break, sequential timed sections, and Python, classical ML, and GenAI topics. This is an unverified invitation report, not a completed-assessment account. It establishes what that person said their email contained; it does not prove a standard Canditech format or reveal the questions they received.
That distinction changes how to use candidate discussions. Extract the employer, role, location, recruiting cycle, and whether the author actually completed the test. A post asking “what should I expect?” is evidence of uncertainty, not evidence of the answer. Do not import its timer, navigation restrictions, or topic mix into your own plan unless your instructions agree. This guide did not find two independent same-cycle reports establishing one common technical assessment, so it stays at the platform-and-preparation level.
Coding practice: obey the contract before optimizing
Original exercise: Given job-status events, return the latest valid status for each job. Each event has job_id, integer sequence, and status. Accept only queued, running, and done; ignore unknown statuses. Larger sequences win, and a later input event wins a sequence tie. Return results sorted by job ID. These rules are invented for practice, not taken from a Canditech question.
Use four events: (A, 2, running), (A, 1, queued), (B, 4, unknown), and (A, 2, done). The result contains only job A with status done. The unknown B event contributes nothing. A common mistake is to take the last event for every job without checking sequence; another is to retain the first event on a tie. Both can pass a friendly example and fail the stated contract.
Write tests for empty input, one job, multiple jobs, reversed sequence order, a tie, and all-invalid statuses. Decide whether the input may be mutated; if the prompt forbids mutation, avoid sorting the supplied list in place. Explain a straightforward map-based solution before discussing optimization: inspect each event once, replace the stored winner when appropriate, then sort the output IDs. Separate the cost of scanning events from the cost of ordering distinct jobs.
In an actual assessment, preserve the supplied function name, parameter types, and return shape. A correct internal calculation can still be an unusable submission if it prints when it must return, changes the wrapper, or includes extra explanatory text in the output. During preparation, rehearse running the function through its expected interface rather than testing only an isolated helper.
SQL practice: make wrong answers visible with tiny tables
Official scoring detail: Canditech's question-and-scoring documentation, dated August 5, 2026, says SQL setup can specify numeric rounding and whether row order matters. Code questions have example and scored test cases. Code Project questions are labeled Beta and use hidden tests after submission; optional AI scoring can assess additional criteria. These are configurable platform mechanisms, not your employer's disclosed rubric or passing score.
Original SQL exercise: Return every customer's paid total and the count of paid orders whose amount is missing. Sort by paid total descending, then customer ID ascending. Unknown amounts contribute nothing to the total but must remain visible in the missing-amount count. This avoids silently treating incomplete data as fully known.
| Customer | Order amounts and statuses | Expected paid total | Missing paid amounts |
|---|---|---|---|
| 1 | 20 paid; 10 paid | 30 | 0 |
| 2 | 30 paid; 99 canceled | 30 | 0 |
| 3 | 50 with null status; null paid | 0 | 1 |
| 4 | No orders | 0 | 0 |
A possible query for this fixture is:
SELECT c.id,
COALESCE(SUM(CASE WHEN o.status = 'paid'
THEN o.amount END), 0) AS paid_total,
SUM(CASE WHEN o.status = 'paid' AND o.amount IS NULL
THEN 1 ELSE 0 END) AS missing_paid_amounts
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id
ORDER BY paid_total DESC, c.id ASC;
The fixture catches three mistakes. Moving the paid filter into WHERE can remove customers without paid orders. Omitting the second sort key leaves the tie between customers 1 and 2 unresolved. Summing every amount incorrectly includes the canceled order and the row with unknown status. Check all three before adding more sophisticated SQL.
Also read the requested row grain. “One row per customer” and “one row per paid order” require different outputs even if both use the same tables. List the expected columns, work out a few rows manually, and compare the result—including duplicates and nulls—with that list. If the actual environment uses a particular dialect, adapt syntax to that dialect; the local fixture is a reasoning aid, not proof of Canditech's database engine.
Project tasks: produce a change another engineer can run
Official product description: Canditech's coding-project page describes a browser-based VS Code environment with multiple files and embedded AI tools. It says employers can configure the AI usage policy and review AI interactions. Treat this as the vendor's description of the product, not permission to use every tool in every assessment. Follow the policy attached to your task.
For preparation, use an original inventory-service repair. A service reserves an item when stock is positive, but a repeated request deducts stock again. Your practice change should recognize a repeated request ID and return the earlier result without another deduction. Define what happens if the same request ID arrives with a different item or quantity; do not let a convenient cache hide a mismatched request.
Keep the scope small enough to inspect. First reproduce the duplicate deduction. Add one regression test, make the minimal repair, and run the existing tests. Then add the changed-payload case. If you store request results only in memory, state that the guarantee ends at process restart. Do not describe a single-process map as durable exactly-once execution. The value of this exercise is explaining the boundary of the fix.
A useful handoff contains the run command, test command, changed behavior, assumptions, and known limitations. Reopen the project in a clean directory or environment before declaring it runnable. Check that a required fixture is committed, paths are portable, and setup does not depend on a private local file. If the actual task uses an embedded workspace, verify that the intended files are present there; a correct change left only on your laptop is not the requested artifact.
If AI is permitted, review its output as your code
An AI assistant can propose a test, explain unfamiliar code, or draft a helper. Your responsibility is to verify what you retain. For the inventory exercise, a suggestion to “retry failed reservations automatically” may duplicate a side effect unless the request identity and persistence behavior are understood. Ask what invariant the proposed change preserves, then create a test that would fail if the suggestion were wrong.
Keep a short decision note: the problem you asked about, the suggestion you accepted or rejected, and the evidence behind that decision. You do not need a theatrical transcript. “Rejected automatic retry because the result may have committed before the timeout; added a repeated-request test” is more informative than “used AI to improve reliability.” This is editorial preparation advice, not a claim that Canditech requires this exact note or scores it with a published weight.
If AI is not permitted, practice with it beforehand only in ways consistent with the rules, then complete the assessment independently. The platform's ability to host an assistant and the employer's permission to use it are separate facts. Resolve an unclear policy before the clock starts.
Timing, submission, and interpreting results
Make a plan from the actual timing controls. If sections lock after submission, reserve a final check before advancing. If navigation is allowed, use it deliberately. For a function, that check is interface plus edge cases; for SQL, columns plus output rows; for a project, saved files plus startup and tests. Do not infer that you can pause, revisit a section, or recover an unfinished upload from another candidate's account.
If the environment fails, record the visible error, time, and affected task, then use the provided support channel. Avoid repeatedly submitting different artifacts without knowing which one was accepted. After submission, distinguish a confirmation of receipt from a score, and a score from a hiring decision. Ask the employer about result availability and next steps rather than treating a forum percentage as a cutoff.
For practice review, classify each failure before repeating the exercise. Was it misunderstanding the contract, a coding defect, a SQL-grain error, an environment problem, or a weak explanation? Repeat the smallest exercise that addresses that failure. This makes preparation more useful than retaking an entire mock and merely noticing that the final score changed.