I Am Jack’s Failed Test

I got 567 out of 600 on a test I failed.

This is not a metaphor yet.

Solace sent me a CodeSignal assessment called Full-Stack Assessment.

Underneath that name was another name:

AI-Assisted General Coding Assessment.

The instructions required TypeScript and Node.js.

I had sixty minutes.

I used almost all of them.

Near the end, 32 of 34 tests were passing.

Then I improved the code until it stopped compiling.

I thought I had earned zero.

A few minutes later CodeSignal showed me this:

567 / 600.

This is I Am Jack’s Failed Test.

The score is not the failure.

Full stack

I prepared for a full-stack assessment.

This seemed reasonable because the assessment was named Full-Stack Assessment.

I have spent years working in TypeScript, JavaScript, React, Next.js, APIs, services, databases, cloud infrastructure, CI/CD, and the long chain of regrettable decisions by which one browser click becomes somebody else’s incident.

I expected some meaningful subset of that.

There was a frontend.

There was a backend.

There was a TypeScript and Node.js environment.

They were almost entirely irrelevant to what I was being scored on.

The existing application was context around the task. If I had decided that a full-stack assessment obviously required me to improve the frontend or restructure the backend, I would have been doing the wrong work more confidently.

The actual problem was algorithmic.

Half of the tests were substantially about validity.

Half were substantially about optimization.

The entire test suite had to stay under a thirty-second execution constraint. Some cases were deliberately large enough to punish an implementation that was logically correct and computationally stupid.

The language barely mattered.

I had already discovered this by accident in practice.

The day before, I completed a practice assessment in thirteen minutes with a perfect result.

Only afterward did I realize I had been writing C++.

There had been a language dropdown at the top of the screen.

TypeScript was available.

C# was available.

Java was available.

I had somehow selected the language in which every useful data structure appears to have been named by a committee that resented vowels.

It did not matter.

The AI understood the language.

The tests understood the output.

I understood enough to understand whether the machine and the tests were disagreeing.

That turned out to be much closer to the real assessment.

The actual stack

The actual stack was not frontend, backend, database, cloud.

It was:

instructions → me → AI → code → tests → timer

That was the system.

My job was not to personally originate every line in the solution.

The assessment explicitly supplied an AI collaborator.

My job was to operate the loop.

Read the instructions.

Notice the constraints.

Convey them accurately.

Ask the AI to reason about the supplied tests and skeleton before changing anything.

Run what it produced.

Inspect the result.

Give the failure back to the AI with enough context that the next move was better than the previous move.

Reject suggestions that did not fit the objective.

Add evidence where the existing evidence was insufficient.

Repeat.

This is not the same thing as understanding every line of the final algorithm.

I did not.

By the end, the primary solution file was large. The optimization logic had become sufficiently elaborate that I could not have walked to a whiteboard and reconstructed the whole thing from first principles.

I could tell you what the problem was asking.

I could tell you why the naive approaches would fail.

I could tell you which constraints mattered.

I could tell you what the tests were demonstrating.

I could tell you whether the current result was getting better or worse.

I could not give a graduate seminar on the algorithm the AI had eventually produced.

Under an interview that prohibited AI and asked me to derive the algorithm myself, that distinction would be devastating.

Under an AI-assisted assessment, the distinction appeared to be the point.

The machine could generate more code than I could comfortably hold in my head.

I still had to decide what deserved to happen next.

Thirty seconds

The dangerous instruction was thirty seconds.

If the test suite exceeded the overall time limit, performance collapsed in a way that made a merely correct solution insufficient.

So I worked with the AI progressively.

We got correctness first.

Then we found the expensive cases.

Then we optimized.

I added test cases that were useful to me, not merely to the scorer.

I added a cheap diagnostic self-test so I could distinguish kinds of failure without waiting for the entire suite to tell me that something somewhere was unhappy.

That was useful engineering.

It shortened feedback.

It made the hidden shape of the problem easier to inspect.

It gave the AI better evidence.

It gave me better evidence about the AI.

Eventually we reached 32 passing tests out of 34.

Two optimization cases still failed.

I had roughly ten minutes left.

The AI kept trying to solve all 34.

This was reasonable if the objective was perfect completion.

It was less reasonable if partial success had value.

I do not think the AI fully internalized that distinction until I forced it into the conversation.

For about ten minutes, we treated perfection as if it were required to have anything at all.

It was not.

Thirty-two tests were already passing.

There was value on the table.

The problem had changed.

Good enough changes the problem

At 32 out of 34, I said something close to the correct sentence.

I told the AI I did not want better or perfect to become the enemy of good enough.

That should have been the end of the story.

Not necessarily the end of all work.

The end of unbounded work.

Once the artifact had substantial value, every additional change had acquired a new cost.

Before 32 out of 34, a change could earn points.

After 32 out of 34, a change could also destroy points already earned.

The issue type had changed.

This was no longer merely an implementation problem.

It was a preservation problem.

The next change had to justify risking the working state.

I understood this.

Then I continued.

Staff engineer enters the assessment

With about four minutes remaining, I stopped behaving like a test taker.

I became the person I often am in an actual repository.

I looked at a large solution file and thought about the next person.

I asked the AI to create a README explaining what we had done and why.

I wanted the handoff to describe the additional test cases.

I wanted it to explain the diagnostic self-test and how it had helped us isolate the problem.

I wanted it to identify reasonable next steps for optimizing the two remaining failures.

Then I asked the AI to review the TypeScript standards supplied with the assessment and format and document the solution appropriately without materially changing its behavior.

These are all defensible things to do in software engineering.

That sentence is how scope expansion gets dressed for work.

There was no next engineer.

There was no maintenance burden.

There was no production handoff.

There was no ticket asking me to improve documentation.

There were four minutes.

There was working code.

There was a score.

I was not being paid to leave the campsite cleaner than I found it.

I was being tested.

Calling the behavior “Staff-level engineering” flatters the part of me that caused the problem.

A Staff engineer who ignores the actual objective and breaks a successful build four minutes before a deadline has not transcended the test.

He has lost the plot with excellent rationale.

Handoff is not stewardship when there is nobody to hand off to.

It is scope.

The transfer mechanism

There was another warning.

The AI was giving me code and documentation in its conversation pane.

I was moving those changes into the repository by copy and paste.

I noticed, during the assessment, that this was now a failure surface.

A better transfer mechanism would have been obvious in an actual repository: have the AI produce a patch, apply it from the command line, inspect the diff, run the tests.

I also noticed I did not have time to build that mechanism.

My conclusion was approximately:

fuck it.

Copy it.

This sounds like a tooling mistake.

Maybe it even cost me the remaining 33 points.

But “I should have built the patch mechanism” is still too flattering.

There were three available actions.

Build the safe transfer mechanism.

Use the unsafe transfer mechanism.

Do not transfer the optional changes.

The clock had already ruled out the first.

The scope should have ruled out the second.

That left the third.

I had treated the unsafe transfer as a technical problem to tolerate because there was no time to solve it.

It was actually new evidence about whether the work deserved to happen at all.

The risk was no longer hypothetical.

I saw it.

I named it.

Then I continued anyway.

This is the part that makes the three characters less random.

They were not lightning.

They were the failure mode I had already accepted.

Three characters

The AI produced the documentation.

I copied it.

I copied the revised solution.

Somewhere in that operation, I pasted a Markdown divider into the top of the TypeScript file.

---

Three characters.

Run tests.

Syntax error.

The algorithm was still there.

The 32 passing cases were still conceptually there.

The diagnostic work was still there.

The additional tests were still there.

The README explaining all of this was there.

The compiler did not care about my body of work.

It encountered three characters that were not TypeScript and behaved with admirable professionalism.

No.

I did not have enough time to recover before the assessment ended.

I believed I had received zero points.

This seemed fair in the narrowest possible sense.

I had converted a working artifact into a non-working artifact while performing work nobody asked for.

The failure was mine.

567

Then the result appeared.

567 / 600.

I stared at it.

I still do not know exactly how CodeSignal derived that result from the sequence I experienced.

I do not remember explicitly submitting the earlier 32-of-34 state.

I remember running tests.

I remember the final syntax error.

I remember expecting catastrophe.

CodeSignal’s published scoring documentation says its Assessment Score runs from 200 to 600 and is deliberately not a percentage scale. Higher scores represent stronger completion across the assessment’s scored material.

So 567 is not 94.5 percent.

It is also not zero.

The platform knows more about its scoring state than I do.

I am willing to let it have this one.

Getting fucking lucky is still part of the result.

What the test actually assessed

The assessment did not meaningfully test whether I could build a full-stack application.

It did not ask me to design an API boundary.

It did not ask me to model persistent data.

It did not ask me to reason about browser state, authentication, deployment topology, observability, or any of the places full-stack systems traditionally hide their knives.

TypeScript was not the skill.

Node.js was not the skill.

The frontend was scenery.

The backend was scenery.

The algorithm was necessary, but even the algorithm was not entirely the skill because I did not personally derive most of its final machinery.

What did the assessment measure?

It measured whether I could read the fucking instructions.

It measured whether I could tell an AI what those instructions meant without quietly changing them into the problem I preferred to solve.

It measured whether I could use tests as evidence instead of ceremony.

It measured whether I could add better evidence when the supplied tests did not tell me enough.

It measured whether I could consume AI output without confusing volume with understanding.

It measured whether I could challenge the AI when its objective drifted away from mine.

It measured whether I knew enough about the technical problem to steer something I could not have reproduced line by line myself.

It measured time management.

It measured scope discipline.

It measured whether I knew when to hold them, when to fold them, and when to run.

I passed some of those tests.

I failed one of them spectacularly.

Then I got 567.

The broken test

A few days before this happened, I wrote I Am Jack’s Broken Test.

That essay asks what happens when the artifact, instruction, requirement, interface, or authority in front of you does not deserve automatic continuation.

The requirement contradicts the architecture.

The test asserts the wrong thing.

The AI gives a beautiful answer to a malformed question.

Something does not fit.

The useful human act is not reflexive obedience or reflexive rebellion.

It is noticing the discontinuity and restoring judgment.

This assessment gave me the inverse case.

The test was not broken in the way that mattered.

I was.

Not permanently.

Not metaphysically.

Not in the inspirational LinkedIn sense where failure is merely success wearing glasses.

I was the source of the discontinuity.

The task had a clear objective.

The timer was real.

The tests were real.

The partial result was real.

At 32 out of 34, the system was telling me something useful.

You have value. Protect it.

I noticed.

I said it out loud.

Then I acted against it.

The same instinct that can help me notice a broken premise can also become its own automatic continuation.

One more test.

One more proof.

One more cleanup.

One more README.

One more pass for standards.

One more thing that would make the work more complete.

The page does not have to be wrong for continuation to become wrong.

Sometimes the thing that deserves inspection is me.

The useful failure

This would be a weaker essay if the result had actually been zero.

Zero would make the moral too easy.

Do not make unnecessary changes at the end of a timed test.

Thank you for attending senior engineering orientation.

567 is more interesting.

The score says I did very well.

My own account says I made a serious judgment error.

Both can be true.

The score measured enough of the successful work to preserve a strong result.

The experience exposed a behavior the score does not erase.

This is what I wanted from a test in the first place.

Not a number that tells me whether I am a software engineer.

Evidence that makes something visible.

The mislabeled Full-Stack Assessment barely tested my stack.

It showed me something about how I work.

I tend to keep finding value after the required value has already been produced.

Sometimes that is why I make good things.

Sometimes it is why I am tired.

Sometimes it is why a finished assignment becomes temporary infrastructure, a review becomes an investigation, an essay becomes a corpus, a tool becomes a laboratory, and a coding solution becomes a README four minutes before the clock expires.

That tendency is not good or bad in the abstract.

It needs a stop condition.

The stop condition cannot merely be exhaustion.

It cannot be the machine running out of tokens.

It cannot be the compiler finally objecting.

It cannot be catastrophe.

Sometimes the senior judgment is not finding the next improvement.

It is recognizing that the next improvement has not earned the right to endanger what already works.

Sometimes the fact that there is no time to make an optional change safely is not a tooling problem.

It is the answer.

The test was called Full-Stack.

The stack it exposed was mine.

At the bottom was luck.

Above it was AI.

Above that was code.

Above that was judgment.

And above judgment was the part I still have to remember:

good enough is not surrender when continuing is the greater risk.

Receipts

• CodeSignal assessment result, August 15, 2026 — The author’s completed assessment dashboard identifies the Solace assessment as “Full-Stack Assessment,” labels the underlying assessment “AI-Assisted General Coding Assessment,” and reports a result of 567/600. A screenshot is preserved with the source material for this essay.

• Author’s CodeSignal assessment session, August 15, 2026 — The sequence described here is first-person recollection immediately after the assessment: a sixty-minute TypeScript/Node.js environment; 34 tests split substantially between validity and performance concerns; a 30-second aggregate execution constraint; 32 passing tests before final cleanup; author-added diagnostic tests; AI-assisted optimization; recognition during the assessment that manual copy/paste had become an unsafe transfer mechanism, followed by the decision to proceed because there was not time to build a safer one; a final TypeScript syntax error introduced during that transfer; and the author’s initial belief that the result would be zero. These are observations from the author’s session, not an independently reproducible account of CodeSignal’s hidden scoring implementation.

• CodeSignal, “AI-Assisted Coding Assessments” ↗ — CodeSignal describes these assessments as using an integrated AI co-pilot, questions purpose-built for AI assistance, and measurement of how well candidates use AI to get work done. This supports the essay’s treatment of AI collaboration as part of the assessment rather than an external shortcut.

• CodeSignal, “Evaluate test-takers’ AI skills with Cosmo” ↗ — CodeSignal says Cosmo can clarify directions, help debug code, and support reasoning during an assessment; it also says the full candidate conversation is logged for company review. This supports the distinction between merely producing code and exposing how the candidate uses the AI during the evaluation.

• CodeSignal, “Understanding Assessment Score” ↗ — CodeSignal documents an overall score range of 200–600, with higher scores indicating greater successful completion, and explicitly explains that the scale was designed not to carry the intuitive meaning of a percentage or ordinary school grade. This supports the narrow claim made here about what 567/600 does and does not mean.

• CodeSignal, “Product Updates: August 2025” ↗ — CodeSignal describes an AI-assisted advanced coding assessment used for software, backend, and full-stack roles as traditional algorithmic questions made harder for AI-assisted workflows. This supports the observation that an assessment used for a full-stack role can intentionally emphasize algorithmic problem-solving with AI rather than direct implementation of a full-stack application.

• “I Am Jack’s Broken Test” — Companion field test about the opposite failure boundary: the moment an instruction, artifact, requirement, or authority stops deserving automatic continuation and the human has to notice the discontinuity. Failed Test turns that mechanism inward: the artifact can be good enough while the human becomes the source of unnecessary continuation.

• “I Am Jack’s Turning Point” — Earlier essay preserving the author’s recurring “extra credit” behavior: optional proof, deeper review, additional investigation, and continued work after the requested work is substantially complete. The CodeSignal session supplies a cleaner bounded case because the cost of continuation was immediate and measurable.

• AI-assisted composition provenance, August 15, 2026 — The author supplied the assessment experience, score, interpretation, self-criticism, comparison with Broken Test, and the governing instruction to “write the essay as it deserves to be written.” ChatGPT inspected the public and privately preserved Jack’s Colon corpus, researched CodeSignal’s current public documentation, proposed the structure and language, and drafted the essay. The author remains responsible for the published work. This receipt exists because the essay argues that operating the human-AI loop is itself part of the work.