What to expect
Prepare for Software Engineer interviews at AKQA by connecting technical fundamentals to browser semantics and asynchronous UI state. This guide gives you six focused practice questions, an illustrated design exercise and a study plan with concrete outputs. Use it to build answers you can explain and test, then adjust the emphasis to the actual team and assessment.
AKQA's official company resource provides background on digital experiences and creative technology. That context helps you ask better questions about users and product constraints. It does not establish a required interview language, a fixed sequence of rounds or a promised set of questions.
Explore six guide-only practice questions →
Build a role brief before you study
A useful starting question for this domain is how a team would detect and recover from an older product-search response replacing a newer search result. Write down who is affected, what they should be able to trust and which component owns the accepted state. This is an original practice scenario, not a description of AKQA's internal architecture.
Read the vacancy with three columns in your notes: a stated requirement, an example from your work that demonstrates it, and an uncertainty to ask about. Separate an explicit language or framework requirement from a tool you happen to prefer. If the role is mainly frontend, focus on state, accessibility and browser behavior; if it is infrastructure-oriented, bring deeper evidence about concurrency, failure recovery and operation under load.
Ask the recruiter which assessments apply, whether work is live or take-home, what tools are permitted and how seniority changes the expected depth. Make those answers change your preparation. A timed coding discussion calls for a different rehearsal from a project review or a collaborative debugging session.
Choose your first practice session
Begin with semantic html and accessibility, var, let and const, explain hoisting with a trace. Read each prompt without its answer, state the contract aloud and attempt a solution before checking the approach. The follow-ups are designed to expose assumptions, so write the changed requirement before changing your implementation.
For a coding task, retain one small example with expected output. For a design task, draw the state owner and one failure boundary. For a project question, identify your own decision and the evidence behind it. These artifacts make gaps visible much faster than rereading an explanation you already recognize.
Guide-only practice question bank
These six practice topics are selected from the published third-party guide. PracHub supplies the clarified problem statements, solution approaches and follow-ups. Treat them as preparation material; their inclusion does not independently verify that this employer asked them.
Semantic HTML and accessibility
Practice prompt: What are the benefits of semantic HTML elements over generic containers?
Solution approach:
- Use elements whose meaning matches the action or document structure: a button performs an action, a link navigates, and a main element identifies the principal content. Their built-in semantics make the interface more understandable to assistive technology and other tools.
- Preserve a logical heading order and accessible names. Replacing a clickable div with a button also supplies keyboard behavior that otherwise needs manual implementation. Semantic markup helps but does not automatically fix focus management, contrast or missing labels.
- Test keyboard navigation, visible focus and form error announcements. Inspect the accessibility tree alongside the rendered page. When a custom control is necessary, use a documented interaction pattern and verify every required key rather than adding an ARIA role alone.
Follow-up: How would you make a custom dialog usable with a keyboard and a screen reader?
var, let and const
Practice prompt: Explain how var, let and const differ in scope and reassignment.
Solution approach:
- var is function-scoped in ordinary function code; let and const are block-scoped. const prevents reassignment of its binding, but does not make a referenced object immutable. Give an example where an object property changes while the binding remains constant.
- let and const cannot be accessed before initialization within their scope. Avoid saying that a declaration is literally moved by the engine. Explain the temporal dead zone and distinguish it from a var binding that may be observed as undefined before its assignment.
- Trace a loop that creates callbacks. A let loop binding provides a separate binding for each iteration; a var example can leave all callbacks reading the same final value. Test the example rather than guessing from the printed syntax.
Follow-up: Why does freezing an object not automatically freeze all nested objects?
Explain hoisting with a trace
Practice prompt: What does variable hoisting mean, and where can it produce an error?
Solution approach:
- Separate creating a binding from assigning its value. Reading a var binding before its assignment commonly returns undefined. Reading a let or const binding in its temporal dead zone throws a ReferenceError, even when a same-named binding exists in an outer scope.
- Compare a function declaration with a function expression assigned to a variable. Calling the declaration earlier in its scope can work, while calling an uninitialized expression does not. State the scope and code form rather than treating every function alike.
- Use a tiny example with one outer variable and one shadowing block declaration. Ask which binding each identifier resolves to before predicting output; shadowing can make an apparently harmless early read fail.
Follow-up: How would you refactor an example to eliminate accidental shadowing?
Center content without breaking mobile
Practice prompt: How would you center a div horizontally and vertically?
Solution approach:
- Choose the containing block first. A grid parent with place-items: center or a flex parent with justify-content and align-items can center a child on both axes, provided the parent has the intended dimensions.
- Prefer min-height for a page that may contain long content rather than a fixed height that clips it. Include padding and a bounded content width. Centering horizontally with auto margins alone requires an appropriate width and does not perform vertical centering.
- Test an unusually long label, increased text size and a narrow viewport. If content becomes taller than the screen, users must still reach its beginning and end. Check that centering is a layout decision, not a substitute for a readable document flow.
Follow-up: How would the layout change when the centered card grows taller than the viewport?
Canvas versus SVG
Practice prompt: Compare Canvas and SVG for an interactive graphic.
Solution approach:
- SVG describes vector elements that remain addressable in the document. Canvas exposes a drawing surface whose pixels must be redrawn when the scene changes. Choose based on the number of objects, update frequency and interactions instead of assuming one is always faster.
- With SVG, individual elements can participate in styling and events. With Canvas, plan hit testing, redraws and a separate accessible representation. Neither approach excuses missing labels or keyboard controls.
- Prototype with realistic data and measure frame time and interaction latency. Test resizing and high-density displays. A dense animated plot and a small navigable diagram have different requirements; use the simplest representation that meets both performance and accessibility needs.
Follow-up: How would keyboard users select a data point drawn on Canvas?
Promise sequencing and failures
Practice prompt: Explain how promises work and how you would compose dependent requests.
Solution approach:
- A promise represents an eventual result or failure. Return the next asynchronous operation from a then handler so the chain waits for it. With async functions, await the dependency and handle rejection where a useful recovery decision can be made.
- Distinguish sequential work from independent work that can start together. Promise.all rejects when an input rejects, but it does not automatically cancel other operations. Use cancellation support from the underlying API when it matters.
- Test success, rejection and a response that arrives after a newer request. Do not swallow an error and accidentally turn the chain into a successful undefined result. Ensure loading state ends even when parsing or validation fails.
Follow-up: How would you stop an older search response from replacing newer results?
Worked example: an accessible search that rejects stale results
Build a search interface where the user types a second query before the first network request completes. The second result arrives first. The UI must keep the newest intent on screen, provide meaningful loading feedback and remain usable by keyboard. This is an original exercise connecting the source's HTML, CSS and Promise topics.
Establish the user-facing contract
Give the search field a visible label. Use a form and a native submit button so Enter and keyboard activation work without custom event emulation. Place the result status in an appropriate live region. Keep focus in the search field after results arrive; unexpectedly moving it to a result makes repeated searches harder.
Loading, empty results and failed requests are different states. Show a clear message for each. If you retain previous results while loading, identify that they belong to the previous query instead of making the old list look like a successful new response.
Version asynchronous work
The following JavaScript sketch assumes a same-origin search endpoint returning JSON and UI functions that render text safely. The request counter belongs to one search component instance.
let latestRequest = 0;
async function search(query) {
const request = ++latestRequest;
setStatus('loading');
try {
const response = await fetch(
'/api/search?q=' + encodeURIComponent(query)
);
if (!response.ok) throw new Error('Search failed');
const results = await response.json();
if (request !== latestRequest) return;
renderResults(results);
setStatus(results.length ? 'ready' : 'empty');
} catch (error) {
if (request !== latestRequest) return;
setStatus('error');
}
}
The guard must protect the error path as well as the success path. Otherwise an obsolete request can replace a newer successful response with an error. Notice also that a fulfilled fetch Promise does not imply an HTTP success status: the code checks response.ok before parsing the payload.
The counter solves result ordering within the component. It does not reduce backend work. An AbortController can cancel a superseded client request, while debouncing can reduce how often requests start. Neither replaces authorization, response validation or a server-side workload limit. Component teardown should cancel or invalidate outstanding work so it cannot update an abandoned view.
Connect the layout and graphics decisions
Use Grid or Flexbox to center a compact search panel, but allow its height to grow when results or errors appear. A fixed-height centered box may clip content on a short mobile screen or at increased text size. Test a long translated label, a long result title and visible keyboard focus.
For an accompanying interactive chart, SVG provides individual elements that can participate in the document structure; Canvas requires an explicit accessibility alternative and custom interaction handling. Decide from the number of marks, animation needs and required user interaction, not simply a claim that one format is always faster.
Prove the ordering behavior
Control request completion in a test: start A, start B, resolve B, then resolve A. Only B should be rendered. Repeat with A rejecting after B succeeds. Also check a current request receiving an HTTP error, a valid empty array and a malformed response. These cases turn a generic Promise explanation into a defensible implementation.
Explain your reasoning in the interview
Make the first answer small and correct
Begin with the contract and a simple approach. Explain its cost and limitations, then improve the part that conflicts with a stated constraint. If you propose an optimization, preserve a test that demonstrates the original behavior. In a design discussion, a small system with a clear failure contract is easier to evaluate than a large diagram with unnamed responsibilities.
Handle a changed requirement explicitly
When the interviewer adds concurrency, a larger dataset or a failing dependency, pause and name the assumption that changed. Describe what remains correct and which boundary needs revision. Do not restart the entire answer unless the new requirement invalidates the original model. This makes adaptation visible and gives the interviewer a chance to correct your interpretation early.
Bring a project story with evidence
Prepare an example relevant to browser semantics and asynchronous UI state. Explain the constraint, your personal contribution, an alternative you considered and the outcome you verified. If you lack professional experience in this domain, use a course or personal project honestly and describe what extra controls production work would need. Never invent traffic numbers, savings or responsibility to make the story sound more senior.
A two-week preparation plan
This is a suggested schedule, not AKQA's interview timeline. Move effort toward the confirmed assessment and the topics where your first attempt exposed a gap.
| Session | Concrete output |
|---|---|
| Days 1–2 | A role brief and an attempted answer to semantic html and accessibility. |
| Days 3–4 | A tested answer to var, let and const, including one failure or boundary case. |
| Days 5–6 | Rehearse explain hoisting with a trace and explain a changed requirement. |
| Days 7–8 | Complete center content without breaking mobile and compare your reasoning with its checklist. |
| Days 9–10 | Work through canvas versus svg and promise sequencing and failures. |
| Days 11–12 | Annotate the design diagram with ownership, failure and recovery. |
| Days 13–14 | Run a mock, repair the weakest answer and prepare questions for the team. |
After each session, record what you could not explain without looking at the answer. Turn that uncertainty into a small test, diagram or documented example. Repeating a question is useful when the second attempt demonstrates a specific improvement, such as a clearer invariant or a previously missed edge case.
Questions to ask the team
Ask which user workflow needs the most attention, how the team knows a change is working and where engineers spend time diagnosing failures. For AKQA, use the discussion of browser semantics and asynchronous UI state to make the questions concrete: which system owns the truth, which views may lag and who handles discrepancies between them?
Also ask how code reviews, production support and onboarding work for this specific role. The answers help you assess the work and prepare relevant examples without assuming that every team at one company has the same stack or responsibilities.
Frequently asked questions
Are these confirmed AKQA interview questions?
The six topics are selected from a third-party company guide; the problem clarifications, solution approaches, diagrams and follow-ups are PracHub preparation material. The third-party listing is not independent confirmation that this team asks these questions. Use current recruiter instructions for the actual format.
Do I need to use the language shown in a reference?
Use the language required by the assessment, or your strongest suitable language when there is a choice. Reference documentation helps verify behavior; it does not prove the employer requires that language. Be ready to explain your data structures and test cases without relying on memorized syntax.
What if I have only a weekend?
Complete the first two selected questions, trace the design failure above and prepare one honest project story. Prefer a few answers you can defend over a wide list of topics you cannot explain. For more exercises, use the PracHub Software Engineer question bank.
Sources and further reading
- AKQA: company background — context on digital experiences and creative technology; use the actual vacancy to establish role requirements.
- Dataford: AKQA Software Engineer guide — source of the selected practice topics, with PracHub-authored explanations and follow-ups. Its company-question attribution has not been independently confirmed.
- WAI-ARIA Authoring Practices — Check keyboard interaction and accessible component patterns.
- MDN: let declarations — Check scope and the temporal dead zone.
- MDN web documentation — Look up browser APIs, networking and JavaScript behavior relevant to the selected exercises.
- MDN: using promises — Review chaining, rejection and composition.