Interview guides · Avetta

Avetta Software Engineer Interview Guide

Avetta Software Engineer interview guide: reported rounds, vanilla JavaScript live coding, integration design questions and a 7-day prep plan.

The 60-second brief

Avetta sells a SaaS platform for supply chain risk management. Client organisations use it to track the safety, compliance and sustainability standing of the contractors and suppliers they work with, in industries from construction to telecommunications. Software Engineers there work on three kinds of things: integrations with third-party systems, the user interfaces clients work in, and the backend services behind both. That work involves large datasets and analytics views. Some candidates interview for a specialised track, such as Integration Developer or front-end work.

This guide is for engineers interviewing for a Software Engineer role at Avetta, on either the integration side or the front-end side. Candidates describe these requirements: strong JavaScript (TypeScript is a plus), a modern framework such as React or Angular, HTML5/CSS3, building or consuming RESTful APIs, and handling asynchronous data flows. Experience with AWS or Azure, CI/CD, Java or Node.js, and supply chain or compliance domain knowledge are listed as nice to have, and roughly 3+ years of professional experience is typical. The guide covers the reported rounds, every reported question with a worked approach, the mistakes that cost candidates points on these question types, and a 7-day plan.

Candidates report three rounds over roughly 3-5 weeks: an introductory video call with a recruiter or HR representative, technical video interviews built around live coding, and a final technical panel with harder coding, system design and time with senior leadership such as the CTO.

Focus areas

JavaScript
Front-End Development
HTML

Overview

Avetta's product helps companies manage risk across their contractor and supplier networks: safety records, compliance status and sustainability data. On the engineering side, that means pulling data in from outside systems, transforming it and showing it in dashboards that client users rely on. The reported questions follow those three areas: browser code that fetches and renders data, design questions about calling unreliable outside services, and questions about keeping data-heavy screens fast.

The reported coding questions are practical browser tasks, not algorithm puzzles: debounce a search input, fetch from a mock API and render a list on a button click, flatten a nested array without the built-in method, explain let/const/var with a closure, and build a counter in plain JavaScript, HTML and CSS. Candidates report the tested topics as JavaScript, front-end development, HTML, CSS and asynchronous programming with callbacks. Prepare by building each one from a blank file, without a framework, and talk through your choices as you type. Other reported scenarios are good practice too: toggling element visibility on click, filtering and sorting objects by several keys, blocking duplicate submits while a request is in flight, rewriting callbacks as async/await, and waiting on three independent requests before rendering.

The design questions are mostly about integration and front-end architecture. They cover a retry strategy for an unreliable third-party API, state management in a large single-page app, protecting sensitive data between a client and an external service, speeding up a data-heavy dashboard, and walking through the most complex system you have built. Related scenarios candidates mention include integrating with a vendor's legacy SOAP API, keeping records consistent when syncing two databases, and speeding up a slow query or endpoint. For each one, have the failure modes, the trade-off and a measurement ready.

Candidates report that the first call includes a presentation on Avetta's business model, methodology and team practices, and that the final stage can include senior leadership such as the CTO. That makes product understanding part of the preparation. Be ready to explain in plain words what the platform does for its clients, why the domain interests you, and how your past architecture decisions affected the business. One candidate review argues that building for maintainability costs less over time than repeatedly fighting fires. Expect the question about balancing shipping speed and code quality to come up, and answer it with a concrete example.

The Avetta interview process

Candidates describe three stages over roughly 3-5 weeks. Stages can vary slightly by track (integration or front-end), and some final stages are held onsite depending on location.

Introductory Video Call

Candidates report a video call with a recruiter or HR representative that includes a slideshow on Avetta's business model, methodology and team practices, with room for discussion. Treat it as a two-way conversation. Have a short background story that maps your experience to integration or front-end work. Listen for details about how clients use the platform, and come with questions that show you followed the presentation. This is also the natural place for the question about why you want to work in supply chain risk management and why Avetta.

What to demonstrate

How clearly you connect your background to the Software Engineer role and its track
Engagement with the business-model presentation, shown through the questions you ask
Motivation for the supply chain risk and compliance domain

How to prepare

Write a short background pitch covering one integration or data-heavy UI project and the stack you used (JavaScript/TypeScript, React or Angular, REST APIs)
Prepare your answer to why supply chain risk management and why Avetta, built on a plain-language description of what the platform does for clients
Write three questions about the business model or team practices that you can adjust based on what the presentation covers
Decide which track you are aiming for (integration or front-end) and say so

Technical Video Interviews

Candidates describe one or more technical video sessions on domain expertise with live coding. You write practical functions, build UI elements and make them interactive, usually while sharing your screen. The reported coding questions belong to this format: small browser builds in plain JavaScript, HTML and CSS, plus async data handling. Have a blank HTML/JS/CSS environment ready to go, state your assumptions before you type, and test in the browser as you build instead of at the end.

What to demonstrate

Working vanilla JavaScript written live: DOM manipulation, event handling, array methods
Asynchronous code: callbacks, promises, async/await, error handling
Explaining your choices and debugging out loud when something does not run

How to prepare

Set up a reusable CodeSandbox or local index.html/script.js/styles.css template and rehearse screen-sharing while you narrate
From a blank file and without a framework, build the reported tasks: debounced search, fetch-and-render list, nested array flatten, counter component
Rehearse the async scenarios: rewrite a callback fetch as async/await, use Promise.all for three independent requests, block double submits
Write a multi-key filter-and-sort over an array of objects and a click handler that toggles visibility

Final Technical Panel

Candidates report a final technical panel, or an onsite visit depending on location. It has more advanced live coding, system design discussion, and conversations with senior leadership such as the CTO. Prepare for two things: harder builds in the same practical style, and design conversations about integrations, front-end architecture and performance. With leadership, connect technical decisions to business impact and long-term engineering direction.

What to demonstrate

Harder live coding in the same practical, browser-based style
System design reasoning: integrations, data flow, failure handling, performance
How you discuss architecture and business impact with senior technical leaders

How to prepare

Rehearse the reported design questions end to end: third-party retry strategy, SPA state management, securing data to an external service, dashboard load time
Prepare one architecture story about your most complex system, with a diagram you can sketch, the bottleneck you found and the numbers before and after
Sketch an integration with a legacy SOAP vendor API and a two-database record sync, naming the consistency and failure trade-offs
Prepare questions for leadership about engineering direction, technical debt and how integrations are prioritised

Where candidates lose points

Using a framework or a built-in shortcut when the task asks for plain JavaScript, such as calling arr.flat() in the flatten question or setting up React for the counter

Practise the reported builds with the DOM API only: querySelector, createElement, addEventListener, textContent, classList and dataset. Write flatten, debounce and multi-key sort by hand at least twice before the technical rounds.

Treating fetch as if it rejects on HTTP errors, and rendering API data with innerHTML and no loading, empty or error state

Check response.ok every time, wrap the call in try/catch/finally, disable the trigger while the request runs, render with textContent, and handle the empty-list case. Make this your default fetch-and-render pattern so it shows up without thinking.

Retry designs that retry every error immediately, including 4xx responses and non-idempotent POSTs that then create duplicate records on the vendor's side

Start the retry answer by classifying errors, then cover exponential backoff with jitter, attempt caps, idempotency keys or lookup by external id, dead-letter handling and a circuit breaker. Rehearse it once against the legacy SOAP and two-database sync scenarios as well.

An unready screen-share setup, or long silences while coding live

Keep an HTML/JS/CSS template ready in CodeSandbox or locally, test screen-sharing beforehand, and practise narrating your choices as you type. When you are stuck, say what you are checking (a console.log, the network tab, the event target).

Treating the introductory call as a formality, with no questions after the business-model presentation and a generic answer to why Avetta

Before the call, write a plain explanation of what the platform does for clients and three questions about it. Afterwards, refine your answer to why supply chain risk management and why Avetta using what you heard.

Questions & practice

Implement a JavaScript function that debounces a search input field.

Medium · Core JavaScript and Live Coding

Approach

Return a wrapper function that closes over a timer id. Each call runs clearTimeout(timer) and then timer = setTimeout(() => fn.apply(this, args), wait). Use a regular function plus rest args so this and the arguments reach the original handler.
Wire it to the input event, not keyup, so paste and IME input also trigger it. Trim the query, and for an empty string clear the results instead of calling the API.
Debouncing cuts the number of calls but does not keep responses in order. Abort the previous fetch with an AbortController, or tag each request with a counter and drop any response that is not the latest.
Each call is O(1). Mention trailing-edge (the default) versus leading-edge firing, and add cancel() and flush() methods so a component can clean up on unmount.
Contrast it with throttle: debounce waits for a pause, throttle fires at most once per interval (better for scroll or resize).

Follow-up

Implement throttle, or add a leading-edge option and a maxWait to your debounce.
How would you unit-test it without real waiting (fake timers such as jest.useFakeTimers)?
The user types fast and an older response arrives after a newer one. What does your code display?

Write a function that flattens a deeply nested array without using built-in array flattening methods.

Medium · Core JavaScript and Live Coding

Approach

Recursive version: function flatten(arr, out = []) { for (const item of arr) Array.isArray(item) ? flatten(item, out) : out.push(item); return out; }. Pushing into one shared output array keeps it O(n) over all elements. Repeated concat or spread copies arrays and can go quadratic.
Iterative version for very deep nesting, where recursion can overflow the call stack: use an explicit stack. Push items in reverse order, pop, and expand arrays as they come up so the original left-to-right order holds.
Add an optional depth parameter that mirrors Array.prototype.flat(depth): recurse only while depth > 0.
Edge cases: empty nested arrays disappear, strings and array-like objects are not flattened (use Array.isArray, not an iterable check), sparse holes are skipped by the built-in flat, and circular references need a Set of arrays already seen so the function throws instead of looping forever.

Follow-up

Write a generator version using function* and yield* so a caller can consume it lazily.
Flatten a nested object into dot-path keys such as {"a.b.c": 1}.
What happens with your recursive version at a nesting depth of 100,000?

Explain the difference between `let`, `const`, and `var`, and demonstrate closure in a short code snippet.

Medium · Core JavaScript and Live Coding

Approach

var is function-scoped, hoisted and initialised to undefined, can be redeclared, and at the top level of a script it becomes a property of the global object. let and const are block-scoped and hoisted into the temporal dead zone, so reading them before the declaration throws a ReferenceError.
const stops reassignment of the binding, not changes to the value: a const object or array can still be modified, and Object.freeze only freezes one level deep.
A closure is a function that keeps access to its outer scope's variables after the outer function returns. Show function makeCounter() { let count = 0; return { inc: () => ++count, get: () => count }; }, where count is private state.
The loop example: for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)) logs 3, 3, 3 because every callback shares one i. With let, each iteration gets a new binding and it logs 0, 1, 2. The pre-ES6 fix is an IIFE.
Link it to real code: debounce, memoize and module-style private state all rely on closures. A closure can also keep detached DOM nodes alive if its listener is never removed.

Follow-up

What does typeof return for a variable in the temporal dead zone, compared with one that was never declared?
How does this differ between an arrow function and a regular function inside a closure?
Implement once(fn) so that fn runs only on the first call.

Build a simple counter component using pure JavaScript, HTML, and CSS.

Medium · Core JavaScript and Live Coding

Approach

Markup: decrement, reset and increment buttons with type="button", plus an <output> or a span with aria-live="polite" for the value. CSS: a flex row, a visible :focus-visible style and a disabled style.
Keep the state in one variable and write a single render() that sets textContent and the disabled flags at min and max. Handlers only change state and then call render(), so data flows one way and the DOM never becomes the source of truth.
Use event delegation: one click listener on the container reads event.target.closest('[data-action]').dataset.action instead of three separate listeners.
Make it reusable with a factory such as createCounter(root, { min, max, step, initial }) that only touches elements inside root. Then two counters on one page do not clash over global ids.
Mention optional extras and their cost: saving to localStorage, handling non-numeric step input, and how the same component looks in React (useState) or Angular.

Follow-up

Turn it into a Web Component (a custom element) with attributes for min and max.
Keep the value across page reloads and across two open tabs (the storage event).
How would you test the bounds and the disabled states?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Create a basic HTML layout with a button, and write a JS script that fetches data from a mock API and displays

Medium · Core JavaScript and Live Coding

Create a basic HTML layout with a button, and write a JS script that fetches data from a mock API and displays it in a list when clicked.

Approach

Markup: a <button type="button">, an empty <ul>, and a status element with aria-live="polite" for loading and error text. In the script, attach the listener with addEventListener('click', async () => {...}).
fetch only rejects on network failure, so check response.ok and throw on a 4xx or 5xx before calling await response.json(). Wrap the whole thing in try/catch/finally.
Render safely and in one pass: create <li> elements, set textContent (never innerHTML with API data, because of XSS), append them to a DocumentFragment, then call list.replaceChildren(fragment) so a second click does not duplicate items.
Handle every state: disable the button and show loading while the request runs, show a message for an empty array and for errors, and re-enable the button in finally. This also blocks double clicks.
For the mock API, use a public test endpoint or a function that returns a Promise resolving after setTimeout. Say how you would switch it for the real endpoint.

Follow-up

Add a 'load more' button that appends the next page without re-rendering existing items.
The endpoint returns 10,000 rows. What changes (pagination, chunked rendering, virtualisation)?
How would you test this click-fetch-render flow?