WeCP Coding Assessment: Sample Tests, Hidden Cases, and Submission Checks

A green sample result is useful evidence, but it is not a verdict on a WeCP coding assessment. The visible cases establish that one implementation ran successfully against a small, disclosed input set. They do not establish correctness at input limits, across duplicate or negative values, or under the platform's hidden tests. The candidate's job is to turn the problem statement into a contract, attack that contract with a few high-value probes, and verify that the intended final code—not just a successful local run—was submitted.

This guide is for candidates using WeCP, not a prediction of any employer's exact questions or cutoff. WeCP's Run Code versus Submit Code guide says Run Code checks sample cases without hidden-case scoring, while Submit Code runs the broader case set for scoring. The exercises below are original practice material. Evidence boundary: platform behavior comes from WeCP help pages; hidden-case categories, the worked exercise, and preparation rubric are editorial reasoning tools, not leaked tests or employer-specific rules.

What a sample pass proves—and what it does not

A sample test confirms that your code compiled or executed in that environment, accepted the supplied example format, and produced the expected output for the examples the platform exposed. That is a narrow but valuable check. A failure there often points to a syntax error, an unexpected function signature, wrong parsing, a formatting mismatch, or an algorithmic mistake visible on the example. Fix it before exploring harder boundaries.

A pass does not prove that an algorithm has the required complexity. A quadratic loop can pass a three-element sample and time out at the maximum input size. It does not prove that your handling of empty input, repeated values, integer overflow, or multiple test cases matches the specification. Nor does it tell you how many hidden cases will pass. WeCP explicitly separates the sample Run Code path from the broader Submit Code path; do not turn a sample checkmark into an imagined score.

Read the entire prompt before you code. Identify whether the platform asks you to implement a function in provided scaffolding or print a program's output. Record the exact parameter types, return type, indexing convention, constraints, and required behavior when no solution exists. If the prompt is ambiguous, use the examples and any provided template to narrow the contract—but do not silently invent one. A correct algorithm behind the wrong interface is still a wrong submission.

Observation	Supported conclusion	Unsupported leap
Visible example passed	This input and expected output agree	Every valid input is covered
Custom case passed	The case you supplied behaved as expected	The hidden set uses the same distribution
Local benchmark is fast	Your chosen local data size is feasible	Maximum-size tests will fit the time limit
Submit action acknowledged	A submission action was recorded in the interface	Recruiter outcome, cutoff, or final review is known

Build hidden-case probes from the contract

Consider an original exercise: given an array of integers and target k, return the number of contiguous subarrays whose sum is exactly k. Suppose the displayed example is [2, 1, 2] with target 3, returning 2. A sliding-window solution may appear to work. The prompt, however, permits negative numbers. That one word breaks the monotonicity a usual sliding window relies on. The array [1, -1, 1] with target 1 has three matching subarrays: the first singleton 1, the full array, and the last singleton 1. A window that assumes expanding always increases the sum can miss them.

A prefix-sum frequency map gives an O(n) approach for the general integer case. Start with frequency {0: 1} for the empty prefix. After reading a value, update the running prefix sum p; the number of earlier prefixes equal to p - k is the number of subarrays ending here with sum k. Add that count to the answer, then increment the frequency of p. The order matters: checking before incrementing prevents an empty subarray from being counted when k is zero. This is a useful interview answer because its invariant explains the edge cases, not merely its code.

Now probe the contract, one risk at a time. An empty array should return zero if empty input is allowed. [0, 0, 0] with target zero should count six nonempty subarrays; a map storing only one index cannot count all of them. [3] with target three tests the singleton. A large array of zeros tests both runtime and whether the answer type can hold n(n+1)/2; in fixed-width languages, a 32-bit count may overflow even when each element fits. A negative target and all-negative array defeat positive-only assumptions. A target absent from a one-element array tests the no-match result.

This is what “think about hidden cases” means in practice: derive a small adversarial set from stated constraints and from the invariant of your approach. Do not spend the final minute generating random numbers you cannot interpret. Each custom case should answer a question: Does this code preserve the invariant when the data changes this way?

Check parsing and output separately from the algorithm

Many apparent algorithm failures are interface failures. If the editor supplies a function skeleton, retain the expected name, parameters, and return form. If it expects standard input, verify whether the first line is n, whether multiple test cases are included, and whether values may span lines. A parser that assumes one number per line can fail when the grader supplies whitespace-separated values on one line. Likewise, returning a list when the harness expects a scalar, or printing debug statements before the answer, can spoil a correct computation.

Use a tiny “shape test” before performance work: feed the minimum valid input and inspect the exact output. Next use a case with two test cases if the contract allows multiple instances; this exposes state accidentally retained between runs. Remove debugging prints, local file paths, and ad hoc prompts such as “Enter n:”. For a function-style task, avoid renaming a required method to suit your preferred style. A final check of the interface usually has a better payoff than a late speculative optimization.

If custom test cases are available, WeCP describes a Custom Test Case screen for Run Code. Use it for the smallest discriminating inputs above. Keep your expected output independently reasoned; seeing your program output 6 is not a pass unless 6 is actually correct. For complex cases, hand-trace a short example and then use a simple brute-force implementation locally as an oracle if assessment rules allow your own local preparation. During a live test, follow the allowed tools and environment stated by the organizer.

Allocate time by risk, not by the count of examples

An effective time budget has three blocks: understand the contract, implement and test, then submit and verify. The split depends on the actual timer and number of tasks, so do not memorize a universal minute count. One practical rule is to reserve a visible final-review buffer before coding starts. The buffer must be large enough to inspect the editor, run a minimal case, and complete the platform's submission flow without racing the clock.

When a sample fails, identify the first failing layer. Did the code compile? Was input parsed? Is the function called correctly? Is the expected output itself understood? Did the algorithm return the wrong value? Rewriting the whole solution before classifying the failure wastes time. When samples pass, pick the riskiest untested property from the constraints. For the subarray exercise, negatives and duplicates are more revealing than another all-positive example. If the maximum n is large, explain why the proposed complexity fits and look for accidental nested work, such as repeatedly slicing an array inside a loop.

If you have several questions, a partially working solution may be worth submitting before returning to optimize it—but only if the current interface actually allows that and you understand its submission state. WeCP's help article contains conflicting language about whether a submitted answer can later be edited. Do not assume a resubmission policy from this guide; check the live assessment instructions and ask the assessment owner before the session if the rule matters to your strategy.

The final submission state is a separate test

WeCP's candidate test-environment guide describes saved-progress indicators and a Finish Test action. Its test-interface guide also describes finishing a test. Those UI details can change, and an employer may configure an assessment differently. Treat the actual screen and invitation as the controlling instructions. Before the clock runs out, check these states explicitly:

1. The final code is in the required editor, not only in a custom-test pane or a local scratch file.
2. The function name, signature, language, and required output shape match the prompt.
3. A minimal known case still passes after the last edit; no debugging output or temporary bypass remains.
4. The intended question has been submitted or saved using the action the interface identifies for that purpose.
5. The test-level finish action is complete if the interface requires it, and you retain any confirmation the platform provides.

The distinction between “saved,” “run,” “submitted,” and “finished” is operational, not pedantic. A successful Run Code result is not automatically a final answer. Equally, a platform confirmation is evidence of an action, not proof that the hidden tests all passed or that a recruiter will advance you. If the browser disconnects at a critical moment, capture the time, question, visible status, and error message without sharing proprietary test content; contact the organizer through the stated support channel.

Five interview-style follow-ups to rehearse

Practice one task by narrating why each test exists.

Practice question	What to rehearse
Design comprehensive OA test cases	Derive boundaries, duplicates, and expected outputs before submission
Implement Three Assessment Functions	Respect exact signatures and different input shapes
Solve Five OA Coding Tasks	Allocate time across tasks without sacrificing final verification
Debug and Harden a Ticketing Backend API	Separate a failing layer from its visible symptom
Review a JavaScript flatten PR	Find an invariant and a minimal counterexample

For each, ask: what is the smallest input that falsifies the obvious solution? What is the maximum case that challenges complexity? Which output or submission state would make the answer demonstrably complete? Being able to state these checks aloud is a transferable interview skill, regardless of whether the assessment surface is WeCP or another platform.

What remains unknown until your invitation arrives

The employer chooses the assessment content, duration, permitted tools, evaluation thresholds, and how results feed hiring decisions. WeCP's public candidate pages do not establish a universal pass mark or a universal set of hidden cases for your invite. The public sample-test route is useful for becoming familiar with the interface; it is not a preview of the employer's task bank. If a policy is consequential—especially whether you can resubmit—resolve it from the specific invite or organizer before the timed attempt.

The best preparation is therefore modest and repeatable: practice the interface once, rehearse deriving tests from constraints, explain the invariant of your algorithm, and use a written final-state checklist. That converts hidden cases from a source of guesswork into a disciplined attempt to falsify your own solution.

Sources and further reading

• WeCP: Run Code versus Submit Code — official distinction and the conflicting edit/resubmit wording noted above.
• WeCP: mock/sample test — official interface practice route.
• WeCP: understanding the test environment — saved-progress and finish controls.
• WeCP: test interface for candidates — candidate-facing test flow.