Omnea’s AI coding interview: how to prepare for pair programming

What Omnea says about its interview

Omnea’s May 26, 2026 engineering post permits AI in its pair-programming interview, from autocomplete to full agents. Working without AI is also acceptable. The team describes looking at problem breakdown, product edge cases, communication, tradeoffs, and pragmatic code quality. It discusses planning, review, and useful tests rather than publishing a numeric rubric. Omnea’s engineering account.

The public post does not give the full interview question or a fixed schedule. We did not find an employer-published assignment to reproduce. Ask your recruiter about your environment and timing, then practice with a tool you already know. Learning a new editor on the day makes an otherwise manageable task unnecessarily awkward.

The approval exercise below is our own. Its purpose is to give you something concrete to discuss with a practice partner. You can work through it in a small repository, pause when a requirement is unclear, and compare your reasoning with the code you eventually accept.

Choose a tool you can interrupt and explain

Optional AI use gives you a practical choice. If autocomplete helps you stay in the conversation, use that. If you regularly work with an agent, make sure you know how to stop a run, inspect its changes, and reject part of a patch. The most capable setup on paper is not necessarily the one that makes your thinking easiest to follow.

Try a short rehearsal with a partner watching your screen. Ask the assistant to inspect a function while you explain what you think it does. Then compare the two explanations against the source. Notice whether you can answer a question without waiting for the assistant to finish. That is a better readiness check than memorizing a long opening prompt.

Practice question: repair a purchase approval workflow

Imagine a service that stores purchase requests. Each request has an ID, requester ID, amount in integer cents, and status. A manager can approve a pending request if it is within their spending limit. The current code occasionally approves a request twice and sometimes accepts approval from its requester. Your task is to fix those behaviors while preserving existing callers.

For this exercise, give an approval command its own ID. The first successful command changes the request to approved and appends one audit entry. Repeating that exact command returns the earlier result without adding another entry. Reusing its ID with a different request or actor is a conflict. A different approval command for an already approved request fails.

Keep the first version in memory and single-process. The request amount and manager limit are nonnegative integers; an amount equal to the limit is permitted. A manager cannot approve their own request. Cancelled requests cannot be approved. These are deliberately chosen practice rules, not Omnea’s interview specification.

Start with the cases that change the answer

Before generating code, write down a few requests and their expected outcomes. A request for 10,000 cents is allowed under a 10,000-cent limit, but not a 9,999-cent limit. A manager with a larger limit still cannot approve their own request. An exact retry should succeed without duplicating the audit entry. These examples catch different mistakes, so none can replace the others.

Resolve the order of checks as well. In this exercise, an exact retry returns the stored result before checking whether the request is still pending. Otherwise a successful command becomes an error when it is retried. A mismatched command ID must still be rejected. Sketch that distinction in plain language before asking for an implementation.

Write one input that worries you and ask your practice partner what they expect. If their answer changes the contract, update the examples first. It is cheaper to fix a misunderstanding on three lines of paper than across a generated service, its tests, and its documentation.

Find the write before changing the workflow

Trace the existing approval function from its input to the status update and audit append. Check whether those operations live together or in separate helpers. Run the existing tests and keep their result. You want to know which behavior was already broken before your patch, especially if the repository is unfamiliar.

Ask the assistant to explain where an exact retry could be recognized and where a conflicting reuse of the command ID should fail. Then open the cited functions yourself. A proposal that adds a global set of processed IDs is incomplete if it cannot distinguish a legitimate retry from a different command reusing the same ID.

Trace approveRequest through its state changes and audit writes.
Show how the current code handles an exact command retry.
Compare that with a command ID reused for another request or actor.
Propose the smallest change that preserves the existing public API.
List the behavior that needs a regression test before editing.

Read the result as a sequence of events

After a patch, follow one approval all the way through. Where is the earlier result stored? What is compared on retry? Can validation fail after state has already changed? Does an error leave an audit record that looks successful? Reading each operation in order often reveals a bug that is hard to see in a broad summary of the diff.

Be careful about a repair that merely hides duplicates from the response. The stored audit log should also contain one successful approval. Check the state that future callers will read, not just the returned message. If the assistant changes the meaning of an existing error, inspect the caller that depends on it before accepting the change.

Test the business rule and the retry separately

Use separate tests for permission and repeated delivery. That keeps failures understandable. A self-approval test should fail because the actor is the requester, with enough spending authority and a pending request. If the same test also exceeds the spending limit, it can pass while the self-approval bug remains unfixed.

For a retry test, make one successful call, capture the result, and repeat the same command. Check the returned result, stored status, and audit-entry count. Then change only the actor while keeping the command ID. That second case should be rejected without altering the original result. One changed field makes the test’s purpose easy to explain.

Also check an amount exactly at the limit, one cent above it, a cancelled request, and a new command targeting an already approved request. Keep inputs small enough to understand without a generated explanation. If a test needs several unrelated fixtures to pass, simplify it before adding more assertions.

Keep your partner involved when the code gets ahead

If an agent produces a large patch, pause and read it before requesting another feature. Tell your partner which branch you are checking and why. For example: “This retry check runs after the pending-state check, so a successful retry would be rejected. I’m moving it earlier and keeping the conflict comparison.” That explanation gives them something specific to question.

A good follow-up is concurrent approval from two workers. The in-memory exercise does not solve that problem. Explain why both workers might observe pending status and then write success. Discuss what must become atomic before proposing storage changes. You do not need to turn the rehearsal into a distributed-system implementation to show that you understand its limits.

Two nrml problems that exercise the same decisions

Start with Make Payment Webhooks Idempotent. It gives you practice with retries and conflicting identities, the same distinction used in the approval example. Explain how the implementation recognizes repeated work and which changes would make an apparent retry a conflict. The setting is payments, not a reproduction of Omnea’s assignment.

Then try Stop Double Claims in the Job Scheduler. Use it to explore the concurrency follow-up: who currently owns the work, when ownership expires, and whether an old worker can still change state. Finish each session by showing a test that would fail on the original behavior. That gives your next rehearsal a concrete result to build on.