SHL Automata Front End Assessment: Practice HTML, CSS, and JavaScript in One Workspace

The SHL Automata Front End assessment is a simulation for building a front-end result with HTML, CSS, and JavaScript. SHL describes three separate coding sections and an output area where you can see the result. The useful preparation is therefore not three disconnected syntax quizzes: it is a short, complete interface whose structure, appearance, and behavior you can inspect together.

This guide gives you a practice workspace, a worked mini-project, and a failure-isolation routine. It does not claim to know your employer's prompt, scoring rubric, editor controls, or permitted resources. Read your own invitation before using any timed plan here.

What SHL actually documents

SHL's Automata Front End product description calls this a simulation of front-end development capability using HTML, CSS, and JavaScript. The candidate has separate areas for those three languages and another section to view the output. SHL says the simulation is manually scored. Its public product page gives an approximate 30-minute completion time.

A 2022 product fact sheet gives more specific historical product details, including a 30-minute allowed time and up to two questions. A product fact sheet is not an employer invitation. An employer can choose a particular assessment configuration, and published product details can change. Use the sheet to understand the shape of the task, then treat the instructions in your own session as authoritative for time, submission, and allowed tools.

The official description does not promise a React project, a particular starter template, auto-complete, a console, or an automatic test suite. It also does not disclose a detailed marking rubric. The preparation below deliberately works with basic browser primitives, so it remains useful even if a platform feature you expected is absent.

Practice one integrated workspace, not three isolated files

Set up a local rehearsal with an index.html, styles.css, and app.js, plus a browser preview. If a single-file editor is easier, keep three clearly marked sections. The point is to rehearse the dependency chain: HTML creates the target element; CSS selects and lays it out; JavaScript finds it and changes its state; the browser renders the result.

Give yourself one small specification rather than a large portfolio project. For example, make a filterable list of three tasks. A text field accepts a query; a button applies it; the list shows matching tasks; a status line reports the visible count. This exercise makes each language necessary, yet it is small enough to finish and verify in a short sitting. It is an original practice prompt, not a reported SHL question.

Before coding, write a tiny contract: input is a trimmed case-insensitive string; an empty query shows all tasks; the result count equals the number of visible rows. That contract gives you testable behavior. Without it, a polished layout can conceal a broken filter, while a working filter can conceal unusable controls.

Worked practice task: a filterable task list

Start with semantic markup. Use a label so the input has a programmatic name, a button for the action, and a status region for the result. Give the JavaScript stable IDs only where it needs them; avoid selecting by styling class when that class may change.

<main class="panel">
  <h2>Find a task</h2>
  <label for="query">Search tasks</label>
  <div class="controls">
    <input id="query" type="search" />
    <button id="apply" type="button">Filter</button>
  </div>
  <p id="status" role="status"></p>
  <ul id="tasks"></ul>
</main>

In the CSS section, solve layout first, decoration second. The controls need to remain usable on a narrow screen. A flexible row that wraps is more resilient than fixed widths. Use visible focus styles; do not remove the browser outline unless you replace it with an equally clear indication.

.panel { max-width: 34rem; margin: 2rem auto; padding: 1rem; }
.controls { display: flex; gap: .75rem; flex-wrap: wrap; }
.controls input { flex: 1 1 14rem; min-width: 0; }
button:focus-visible, input:focus-visible { outline: 3px solid #215b46; }
li { padding: .5rem 0; border-bottom: 1px solid #d8dfd8; }

The JavaScript should render from one source array instead of editing each existing <li> in place. That makes empty-query and no-result behavior easier to reason about. For a small, fixed rehearsal array, rebuilding the list is appropriate; a production app with large data or preserved child state may need a different approach.

const tasks = ["Review design", "Write tests", "Fix layout"];
const query = document.querySelector("#query");
const list = document.querySelector("#tasks");
const status = document.querySelector("#status");

function render(raw) {
  const needle = raw.trim().toLocaleLowerCase();
  const visible = tasks.filter((task) =>
    task.toLocaleLowerCase().includes(needle)
  );
  list.replaceChildren();
  for (const task of visible) {
    const item = document.createElement("li");
    item.textContent = task;
    list.append(item);
  }
  status.textContent = `${visible.length} task${visible.length === 1 ? "" : "s"} shown`;
}

document.querySelector("#apply").addEventListener("click", () => render(query.value));
render("");

Notice the deliberate use of textContent: task names are data, not HTML. If the problem supplies user-controlled labels, interpreting them as markup would add a safety problem unrelated to the UI objective. Notice also that render("") establishes a useful initial state rather than leaving a blank page until the first click.

Verify the output in layers

The output pane is not a victory screen; it is evidence. Look at the result after each layer instead of writing all three sections and hoping they combine correctly. First confirm the heading, label, input, button, and three list items appear. Then check spacing and narrow-width wrapping. Finally click Filter with several queries and observe both the list and status line.

Use this compact probe set: an empty query should show three items; test should show one; LAYOUT should also show one; a nonsense query should show zero and an empty list. The third case tests trimming and case handling. The fourth tests the absence state, where many hurried interfaces fail because the count updates but old items remain on screen.

When a check fails, identify the first broken boundary. If the elements are absent, inspect markup and IDs. If the elements exist but overflow, inspect layout CSS before changing JavaScript. If clicking does nothing, confirm the button ID, listener attachment, and script load order. If the click fires but rows are wrong, trace the normalized query and filtered array. This sequence is faster than changing multiple sections at once.

A triage matrix for the last minutes

What you see	First question	Smallest useful check
Blank output	Did the HTML parse and script load?	Temporarily remove JavaScript; confirm static markup appears.
Controls appear, layout breaks	Is a width or flex item forcing overflow?	Narrow the preview; inspect min-width and fixed dimensions.
Button does nothing	Is the listener attached to the intended element?	Check selector spelling and when the script runs.
Wrong results after click	Was the query normalized before filtering?	Log or display the needle and matching count in a local rehearsal.
Count and rows disagree	Are both derived from the same filtered array?	Re-render both from visible, not separate calculations.

This is a preparation matrix, not a claim about debugging tools available inside SHL. During an actual assessment, use only the controls and resources the platform and employer permit. If there is no console, you can still reason from the observed output and add a temporary visible indicator only if the task rules allow code changes of that kind.

Decide what to build first when time is tight

Choose a vertical slice. Build the HTML that exposes the required controls and output. Add only enough CSS to make the state legible. Wire one correct interaction. Then verify empty, normal, and no-result cases. After that, refine spacing, colors, and extra behaviors. This order leaves you with a coherent artifact if the clock ends earlier than expected.

If a visual reference is provided, extract a few observable requirements before coding: content order, grouping, approximate width, spacing rhythm, and visible states. Do not chase an exact pixel value before the controls work. Conversely, do not treat functional correctness as permission to ignore the requested visual hierarchy: a manually reviewed simulation can expose an interface whose state is technically correct but confusing to use.

Write down assumptions that are not in the prompt. Does pressing Enter submit? Should leading spaces be ignored? Is the input case-sensitive? You can make a reasonable choice in a practice project, but in the actual session prefer the explicit requirement. If the assessment's instructions are silent and clarification is impossible, make the smallest consistent choice and keep the code easy to adjust.

Common mistakes in a three-language exercise

One mistake is coding in a familiar framework even though the workspace only asks for HTML, CSS, and JavaScript. A local React rehearsal can train component skills, but it does not rehearse the same DOM and stylesheet boundaries as this SHL product description. Practice at least once without build tooling so you can locate an element, attach an event listener, and update text directly.

Another mistake is making CSS selectors and JavaScript selectors accidentally depend on the same class. Renaming .task for styling can then break event code. Prefer a small set of stable IDs for unique controls and separate classes for visual states. Also avoid innerHTML when plain text will do. It may seem faster, but it invites malformed markup and data-as-code confusion.

Finally, candidates often inspect only the happy path. A filter that works for one exact lowercase word may fail on spaces, capitalization, no matches, or an empty initial state. Build a four-case test card before you start. The cases should take seconds to run, and each should identify one distinct failure mode rather than repeat the same successful click.

Final check before you submit

Re-read the actual prompt and compare every requested behavior with something visible or testable. Check that the output pane displays the current version of your code. Run one ordinary case and one boundary case. Confirm that the status, labels, and interaction still work after your last CSS edit. If the platform has a separate Run, Save, or Submit action, follow its own instructions and wait for its confirmation; a preview alone may not record a final submission.

SHL Automata Front End preparation works best when you rehearse integration: one small interface, three language sections, and a deliberate output check. Use the Frontend Engineer question collection to pick one relevant UI task, then redo it under your own short timer with a written four-case verification card. Your invitation remains the source of truth for the actual assessment.

Sources and Further Reading

• SHL Automata Front End product description
• SHL Automata Frontend assessment fact sheet (2022)

Research note: Official product information and linked practice destinations were checked September 27, 2026. Product details can change; your employer invitation governs your assessment.