Applied Intuition Coding: What to Expect

Applied Intuition's coding bar sits in the medium-to-hard range, and the base problems are recognizable data structures and algorithms. Two layers on top make it feel like Applied Intuition. First, the problems are often painted in the company's own domain: a lane split into segments, sensor coordinates to cluster, a message stream to reassemble, agents driving across a plane until two collide. Second, the difficulty rarely comes from the algorithm alone. It comes from a twist bolted onto a problem you half-recognize, and from a systems-engineering register where clean C++ and object-oriented design carry real weight. The costume is the autonomy stack, and the finish is closer to production code than a race for a green checkmark.

Picture the surface by the shapes that recur. Merging overlapping or collinear line segments and reasoning about lane geometry. Grouping scattered coordinates into clusters, which is union-find or a grid flood fill in disguise. Reassembling a type-length-value message from a byte stream, or evaluating a small formula or chain of dependent assignments (a parser and interpreter in a config file). Simulating agents that move by a unicycle kinematic step and detecting when paths cross, or building a transactional key-value store with nested begin, commit and rollback. The work is hearing the domain story, naming the ordinary structure underneath, and finishing a correct, tested, readable solution in the time box.

The Applied Intuition angle

Expect the constraint to move, and drill each base pattern until you can bend it on demand. Candidates repeatedly describe the same experience: the prompt looks like a medium they've seen, and then a constraint moves. Partitioning a bag into groups of equal values becomes groups of exactly five consecutive values. A merge-intervals scan gains a rule about collinear segments. A dictionary of latest positions gains a bounded history window, which turns it into a question about lists versus deques. Interviewers watch how you adapt when the shape shifts, so rehearse three plausible twists on each canonical pattern before the day.

The AI-tooling split

Applied Intuition splits the loop across a deliberate line, and it shapes how you practice. The phone screen is AI-free: no Copilot, no chat assistant, one live medium-to-hard problem with an engineer. It establishes that you can produce correct, working code unaided. That's where the twist muscle and clean implementation under time matter most, because you have only your own fluency. Treat it as the baseline gate it's designed to be.

The onsite, as the company has described its more recent format, goes the other way. It includes a roughly two-hour prototyping sprint where you may use any AI model or framework, then a panel demo and a walkthrough of your decisions. A system-design discussion on problems the company has solved runs alongside it. The stated reasoning is that raw code production has gotten easier, so the onsite weights judgment, technical decision-making, communication, and how you drive a build. The format is new and still evolving, and candidates have met different versions, so hold the details loosely. Prove you can code cold on the screen, then prove you can steer tools and defend choices onsite.

Autonomy and simulation-flavored problems

The first signature flavor is the domain skin. Problems come dressed as miniatures of the tooling Applied Intuition builds: simulators, sensor pipelines and map geometry. A lane becomes segments to merge and intersect, and a sensor sweep becomes coordinates to group into connected regions. A telemetry feed becomes a byte stream you parse into typed records. A scene becomes agents stepping forward on a simple kinematic model until two occupy the same place. Each story front-loads a translation step: strip the driving vocabulary and name the graph, grid, interval or state machine inside before you write a line.

The multi-agent collision simulator is the sharpest example. You get a handful of agents, each with a position and a heading, and a rule for how they advance each tick. You step the simulation forward, update every agent, and report the first moment two paths cross. Underneath, it's an ordinary loop over state with a pairwise or spatial overlap check. The craft is a clean step, sensible data for positions and headings, and the edge cases at the world's boundary. Model the scene first in your own words, and let the kinematics fall out as a setup detail.

The Applied Intuition angle

Read the scene, name the structure, then code. Use that order on every domain-skinned prompt. The failure mode is coding from the surface story. Someone hears "collision" and models velocity vectors when the task wanted a comparison and an overlap check. Someone hears "sensor stream" and reaches for a heavyweight framework when a small state machine over bytes would do. Practice the reduction out loud: say the underlying pattern before you touch the keyboard. Lane geometry collapses to intervals, coordinate grouping to union-find, and the message stream to a parser you already know how to write.

The C++ and low-level-design bar

The second signature flavor is register. Across the loop, C++ with clean object-oriented design is emphasized, and the low-level-design problems reward memory reasoning and structure over clever one-liners. The canonical example is a transactional key-value store with nested transactions: get and set, plus begin, commit and rollback that can stack. The clean model is a stack of overlay maps. Each transaction pushes a layer that shadows the ones below, commit folds a layer into its parent, and rollback discards it. Interviewers care how you name your types, where you put state, and how the pieces compose.

class TransactionalStore {
  std::unordered_map<std::string, std::string> base;
  std::vector<std::unordered_map<std::string, std::string>> layers;
public:
  void begin() { layers.emplace_back(); }
  void set(const std::string& key, const std::string& value) {
    if (layers.empty()) base[key] = value;
    else layers.back()[key] = value;
  }
  // read from the newest layer down to the committed base
  std::optional<std::string> get(const std::string& key) const {
    for (auto it = layers.rbegin(); it != layers.rend(); ++it) {
      auto found = it->find(key);
      if (found != it->end()) return found->second;
    }
    auto found = base.find(key);
    if (found != base.end()) return found->second;
    return std::nullopt;
  }
  bool rollback() {
    if (layers.empty()) return false;
    layers.pop_back();
    return true;
  }
  bool commit() {
    if (layers.empty()) return false;
    auto top = std::move(layers.back());
    layers.pop_back();
    auto& parent = layers.empty() ? base : layers.back();
    for (auto& kv : top) parent[kv.first] = std::move(kv.second);
    return true;
  }
};

The same register shows up in the mini interpreter and formula-evaluation problems: parse an arithmetic expression or a chain of dependent assignments, resolve the evaluation order, and produce a value. These blend parsing, a little graph reasoning for dependency order, and disciplined object design. Vendor summaries overstate one thing. C++ is emphasized, but it isn't universally mandatory. Some candidates use another language on the screen, and the strongest C++ signal concentrates in the onsite low-level-design rounds. Prepare C++ fluency as a genuine advantage, especially for systems-leaning teams.

How it is graded

The bar is a finished, working solution; a described approach doesn't clear it. Correctness, edge cases, testing and clarity are all scored, and a clever fragment at time-out reads worse than a plain solution that compiles and handles its boundaries. The ceiling is solid medium-to-hard. The pressure comes from breadth and adaptability: the twist that moves mid-problem, the domain translation you do first, the object design the low-level rounds expect. Interviewers are direct and will push back on your choices, so justifying a data-structure decision matters as much as reaching it.

The Applied Intuition angle

Finish code you can defend as the problem moves. Three habits map to how Applied Intuition grades. First, get to a running, tested solution and narrate your reasoning, since both the AI-free screen and the onsite weight communication. Second, rehearse the reduction until a driving story reliably collapses into an interval, grid, parser or state machine. Third, drill clean object-oriented C++ until a transactional store or a small interpreter comes out structured on the first pass. Own the ordinary patterns cold and stay flexible when constraints shift.

The lessons in this section

This section splits the coding loop along the two flavors that decide your prep. The simulation and autonomy problems are the domain-skinned surface nearly every candidate meets, so they come first, with the reduction method worked in full. The C++ systems and low-level-design track goes deep on object design and memory reasoning. Start with whichever matches your role, and work through both for a systems-leaning team.

Common questions