Interview guides · Andersen

Andersen Software Engineer Interview Guide

Andersen Software Engineer interview guide: two reported rounds, JavaScript closures, async, memory and microservices questions, plus behavioral prep.

The 60-second brief

Candidates describe Andersen as a company that works internationally, with distributed teams. Candidate reports name no specific products, customers or team stacks, so the only technology that shows up concretely is JavaScript, through the closure question. Role descriptions that candidates cite mention sprint planning, code review, bug fixing in existing codebases and work on testing and deployment pipelines.

This guide is for software engineers interviewing at Andersen who want a plan built around what candidates report: a screening stage, a technical stage with definition-style fundamentals (closures, asynchronous code, stack versus heap, memory leaks, microservices versus a monolith) and behavioral questions about projects, disagreements, learning fast and maintainable code. It does not cover pay, and it makes no claim about team-specific stacks.

Candidates report two rounds, Initial Screening and Technical Assessments, spread over roughly two to four weeks, with the technical stage described in more than one format.

Focus areas

Closures (JavaScript)
JavaScript
JavaScript scope/lexical concepts

Overview

The reported question list leans toward fundamentals you must be able to explain, not puzzles you must code. Five questions are technical: closures in JavaScript, managing asynchronous operations in your main language, stack versus heap allocation, handling memory leaks in a long-running application, and microservices versus a monolith. The other five are behavioral. The plan below gives four days to the technical explanations and the last two days to the stories, with a short framing day first.

Candidates also describe some interviews as including rapid-fire, definition-based questioning, and the topics reported for this loop center on closures and JavaScript scope. For each fundamentals question, prepare a short definition, one concrete example you can write or sketch, and one pitfall. A definition alone is easy to recite; the example and the pitfall show you have used the concept in real code.

Reports describe the interviews as mostly remote and the company as international, so spoken English clarity is part of preparation. Practise explaining each concept in short, plain sentences, and ask a clarifying question when a prompt is ambiguous. The behavioral questions (a complex project, a technical disagreement, learning a technology under a deadline, maintainable code, staying current) are best answered with specific stories you have rehearsed aloud.

The role description candidates cite mentions Git, data structures and algorithms, agile delivery, and nice-to-haves such as AWS or Azure and CI/CD tooling. None of these is tied to a specific reported question, so treat them as background: be ready to describe how you use version control and pipelines in your own work if the conversation goes there.

The Andersen interview process

Candidates describe two stages in order: Initial Screening, then Technical Assessments. Reports do not break either stage down further, so the preparation below is organised by the question types candidates report rather than by a fixed round order for each question.

Initial Screening

Candidates describe this as the opening stage, used to assess fit for the role. Nothing more specific is reported, so use it for two things: give a short, clear account of your background and why you want this role, and settle logistics. Reports suggest asking the recruiter about the expected timeline at this point, since the process is said to vary with the hiring team's urgency. Because interviews are reported as mostly remote, this is also a first chance to show that you explain things clearly over video.

What to demonstrate

Fit for the role, as the stage is described by candidates
Clarity of spoken English and concise self-presentation

How to prepare

Write a short walkthrough of your career that ends on the most complex project you have delivered.
Prepare a plain-language one-sentence reason for choosing this company and role, based only on facts you have verified yourself.
List the questions to ask the recruiter: what format the technical stage takes, and how long the remaining steps usually take.
Record yourself explaining your current project and cut jargon until a non-specialist could follow the outline.

Technical Assessments

Candidates report that this stage can take the form of a set of standard questions or a more open discussion of your work, and some mention rapid-fire definition questions. The technical questions candidates report overall are fundamentals: what a closure in JavaScript is, how you manage asynchronous operations, how stack and heap allocation differ, how you would handle memory leaks in a long-running application, and the benefits and drawbacks of microservices versus a monolith. Reports advise explaining your reasoning even when you do not reach a perfect answer. Whatever the format, a useful shape is the same: a crisp definition, a concrete example, a pitfall, then the trade-off.

What to demonstrate

Reported topics: closures, JavaScript scope and asynchronous execution
Reported topics: memory allocation, leaks and architecture trade-offs
Verbal explanation of technical ideas, including quick definitions

How to prepare

Write three closure examples from memory: a counter with private state, the var-versus-let loop callback problem, and a function factory; explain each in terms of the lexical environment.
Compare callbacks, promises and async/await in one table, including error handling and running tasks in parallel versus in sequence.
Draw the memory layout for a small program, showing what lives on the stack and what lives on the heap, and list three ways a long-running service leaks memory.
Prepare a two-column answer on microservices versus a monolith with one situation where each is the better choice, then say every answer aloud as a short definition.

Where candidates lose points

Reciting a closure definition without showing one working in code

For the closure question, pair the definition with a counter or function factory, explain the lexical environment it keeps alive, and mention the var-in-a-loop pitfall. An example you can modify on the spot is worth more than a memorised sentence.

Answering the memory questions with generalities (stack is fast, heap is big) and no leak sources

Name what each region holds, why stack allocation is cheap, and what makes a long-running application leak: growing caches, forgotten listeners or timers, and closures holding large objects. Then give the diagnosis sequence: heap snapshots over time, compare retained objects, fix the owner.

Treating microservices versus a monolith as a verdict instead of a trade-off

List benefits and costs on both sides (independent deployment and scaling versus network failures, data consistency and operational load) and say which team size or product stage would tilt the choice. A one-sided answer is only a slogan.

Telling behavioral stories in which you only observed or in which you were simply right

Use stories where you made the decision, name the alternatives and the cost, and for the disagreement question show how you used evidence and what you adopted from the other view.

Unclear spoken English and jargon-heavy answers in a remote loop

Practise each answer aloud in short sentences, define terms as you use them, and ask a clarifying question if a prompt is ambiguous. Record yourself and trim anything a listener from another country and discipline would not follow.

Questions & practice

What is a closure in JavaScript?

Medium · Technical Fundamentals

Approach

Define it precisely: a closure is a function plus a live reference to the lexical environment it was created in, so an inner function can still read and write the outer function's variables after the outer call has returned. It captures bindings, not copies of values.
Show it with a counter factory: function makeCounter() { let n = 0; return () => ++n; }. Each call to makeCounter creates a fresh environment, so two counters never share n, and n cannot be reached from outside except through the returned function.
Walk through the classic loop case: for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)) prints 3, 3, 3 because var gives one function-scoped binding shared by every callback. Switching to let creates a new binding per iteration and prints 0, 1, 2; the pre-ES6 fix was an IIFE that passed i in as a parameter.
Name the practical uses: private state and the module pattern, partial application and currying, memoize/once/debounce helpers, and event handlers or React hooks that read component state.
Cover the costs: a captured environment stays alive as long as the closure is reachable, so a long-lived listener or timer that closes over a large object keeps it in memory, and a React callback can read a stale value if it closed over an earlier render's state.

Follow-up

What does the var loop with setTimeout print, and give two ways to make it print 0, 1, 2.
What is hoisting, and what happens when you read a var versus a let or const variable before its declaration (the temporal dead zone)?
How does this binding in an arrow function differ from a regular function, and how is that different from lexical scope for variables?

How do you manage asynchronous operations in your primary language?

Medium · Technical Fundamentals

Approach

Name the language and its model first. For JavaScript: one call stack per thread plus an event loop; I/O completes off the main thread (libuv in Node, the browser's APIs) and its callbacks run later as tasks, while promise reactions go on the microtask queue, which is drained completely after each task before the next timer or I/O callback runs.
Explain async/await as syntax over promises: await suspends only that function and returns control to the event loop, it does not block the thread. Handle errors with try/catch around awaits, or .catch on the chain, so rejections are never left unhandled.
Choose the combinator on purpose: independent calls go through Promise.all (it rejects on the first failure, but the other operations keep running because promises are not cancelled), Promise.allSettled when partial results are acceptable, Promise.race or AbortController for timeouts and cancellation. Awaiting inside a for loop runs the calls one after another.
Bound concurrency for large batches with a small worker pool or a limiter instead of firing thousands of requests at once, and keep CPU-heavy work off the event loop with worker_threads or Web Workers, since a long synchronous loop blocks every other callback.
If the primary language is something else, map the same ideas: Python asyncio (single-threaded loop, asyncio.gather, blocking calls moved out with asyncio.to_thread), Java CompletableFuture with an ExecutorService, C# async/await on Task. In each case say where the work actually runs and how errors and cancellation propagate.

Follow-up

In what order do console.log, a setTimeout(0) callback and a Promise.resolve().then callback run, and why?
How would you fetch 1,000 URLs with no more than 10 requests in flight, and handle the ones that fail?
What happens to the remaining operations when one promise passed to Promise.all rejects?

Explain the difference between stack and heap memory allocation.

Medium · Technical Fundamentals

Approach

Stack: each thread has its own stack of frames holding arguments, local variables and return addresses. Allocation and release are a pointer move on call and return, so it is very fast and cache-friendly, and lifetime is tied strictly to the function call.
Heap: a region shared by all threads in the process for data whose size or lifetime is not known at compile time. It is managed by an allocator (malloc/new) and freed manually (free/delete, RAII in C++), by reference counting (CPython, Swift ARC) or by a garbage collector (Java, JavaScript, C#, Go). It costs more per allocation and can fragment.
Name the failure modes on each side: stacks are limited in size (a fixed size per OS thread in most runtimes; Go goroutine stacks start small and grow up to a maximum), so unbounded recursion still ends in a stack overflow; the heap gives leaks, use-after-free and dangling pointers in manual languages, and GC pauses or retained garbage in managed ones. Returning a pointer to a local variable in C is a classic dangling-pointer bug.
Be precise for managed languages: in Java, locals of primitive type and object references sit in the frame while the objects themselves live on the heap, and the JIT's escape analysis can avoid some heap allocations; in JavaScript the engine decides, and objects plus variables captured by closures live on the heap; Go's compiler moves any value that escapes its function to the heap.
Connect it to threading: stack data is private to its thread, so it needs no locking, while heap objects can be reached from several threads and need synchronisation or immutability.

Follow-up

Why does deep recursion crash while allocating a very large array usually does not?
Where does a variable captured by a closure live once the outer function has returned?
What is escape analysis, and how does it change where an object is allocated?

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?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

Describe the benefits and drawbacks of using microservices versus a monolithic architecture.

Medium · Technical Fundamentals

Approach

Define both terms: a monolith is one deployable unit, ideally split into internal modules, sharing one process and usually one database; microservices are independently deployable services built around business capabilities, each owning its own data and talking over the network through APIs or messages.
Microservice benefits: services deploy and scale independently, teams own a service end to end, a failure can be contained to one service (only if timeouts, retries with backoff and circuit breakers are in place), and each service can choose its own stack.
Microservice costs: every call becomes a network call that can be slow or fail partway; there are no cross-service ACID transactions, so consistency needs sagas, the outbox pattern and idempotent consumers; and operations grow with service discovery, a pipeline per service, distributed tracing with correlation ids, versioned API contracts and harder local testing.
Monolith trade-offs: one build and deploy, in-process calls, single-database transactions and easy refactoring and debugging; but every change redeploys everything, the whole app scales as one unit, build and test times grow, and module boundaries erode without discipline.
Give a decision rule: start with a modular monolith with clear boundaries, then extract a service when a concrete need justifies it (a very different scaling profile, an independent release cadence, a separate owning team), migrating piece by piece with the strangler fig pattern. Warn against a distributed monolith: services that share one database or must deploy in lockstep.

Follow-up

You need to split an existing monolith. Which piece do you extract first, and how do you migrate its data?
How do you keep an order and its payment consistent when they live in separate services?
What is a distributed monolith, and what signs tell you a system has become one?

Cache the tenant listing feed with a bounded staleness window

Easy · caching · cache invalidation · keyset pagination

GET /v1/resources returns one tenant's resources ordered by updated_at DESC, 20 per page, at 14k requests/second peak against a 120 ms p99. The table carries the index (tenant_id, status, updated_at DESC, resource_id DESC) and writes land on the primary at 1.2k/second. Design the read path: the pagination contract, the cache key and value, what a write invalidates, and the staleness a user can observe. State the request rate that actually reaches the database, and the one repopulation race that deleting on write does not close.

Approach

Settle the pagination contract first, because it decides what is cacheable. OFFSET makes the database produce and discard the skipped rows, so page 500 costs five hundred pages of work, and rows inserted between two fetches shift across the boundary and are skipped or repeated with nothing in the response to reveal it. The cursor is the row value of the last row returned: WHERE tenant_id = $1 AND status = $2 AND (updated_at, resource_id) < ($3, $4) ORDER BY updated_at DESC, resource_id DESC LIMIT 21. That is a row-value comparison, not updated_at < $3 AND resource_id < $4, which is a different and wrong predicate.
Confirm the index actually serves it: equality on the two leading columns, then a range on the pair that follows in exactly the index's sort order, so the plan is an index scan that touches 21 entries with no sort node. Requesting 21 to return 20 is how has_more is answered without a count. resource_id is not decoration - updated_at is not unique, and without the tie-break two rows sharing a timestamp at a page boundary are the skip that keyset pagination was adopted to remove.
Key the cache on every value the predicate reads: tenant_id, status, cursor and page size. A key that omits tenant_id is a cross-tenant disclosure, and no test running against a single tenant's data will show it.
Be honest that a write does not invalidate one key. An update moves its row to the head of the ordering, so it invalidates the first page and every cursor page whose range spans the row's old and new position, which is not enumerable. Cache the first page per (tenant_id, status) - that is where the traffic is - with a short TTL, invalidate it on write, and serve deep cursor pages uncached from a replica, since each is already a 21-row index scan and they are rare.

Follow-up

The tenant writes and immediately lists. What does it see, and what is the smallest change that makes its own write visible without sending all 14k requests/second to the primary?
A tenant has 4 million resources and a client walks every page nightly. What does that do to the cache hit rate, and should that traffic share this path at all?

How would you handle potential memory leaks in a long-running application?

Medium · Technical Fundamentals

Approach

Confirm it is a leak before fixing anything: graph heap used after garbage collection (and RSS) over hours. A sawtooth that returns to the same floor is normal; a floor that keeps rising under steady load is a leak. Rule out cache warm-up and memory that simply scales with traffic.
Capture evidence: take two or three heap snapshots some time apart (Chrome DevTools via node --inspect or --heapsnapshot-signal in Node, jcmd GC.heap_dump plus Eclipse MAT in Java, tracemalloc snapshot comparison in Python), diff them, and follow the retainer path from the growing objects back to a GC root.
Check the usual causes: unbounded maps or caches keyed by request, user or session id; event listeners and subscriptions that are added but never removed; setInterval timers and closures holding large objects; static or global collections; ThreadLocal values in pooled threads; and unclosed connections, streams or file handles.
Fix the root cause: cap caches with an LRU size limit and a TTL, use WeakMap or WeakRef for metadata keyed by objects, remove listeners and clear timers in cleanup code (a React useEffect cleanup, a dispose method), and close resources with try/finally, try-with-resources or context managers.
Prevent a repeat: alert on memory growth, run a soak test that compares heap after many iterations, and set container or runtime limits (for example --max-old-space-size). A scheduled restart only hides the leak and is a stopgap, not the fix.

Follow-up

How do you tell a real leak apart from a cache that is still warming up?
The JS heap is flat but process RSS keeps growing. Where do you look next?
When does a WeakMap prevent a leak, and when does it not help?

Suggested practice checklist

Seven days built from the two reported rounds: day 1 maps the loop, days 2 to 5 cover the five technical fundamentals, days 6 and 7 cover the five behavioral questions and a full mock.

Day 1 — Map the loop and prepare the screening pitch

Write the reported sequence (Initial Screening, then Technical Assessments) and the question types candidates report, marking the topic you are weakest on.
Write a short spoken walkthrough of your career and a one-sentence reason for this role, then say both aloud twice.
List the questions to ask the recruiter about the technical stage format and the expected timeline.

Deliverable: A one-page loop map, a written career walkthrough, and a list of recruiter questions.

Day 2 — JavaScript closures and lexical scope

Write a counter factory, a private-state module and a loop callback using var, then fix it with let and with a closure.
Explain each example aloud in terms of the lexical environment and scope chain.
Write one closure-based memory pitfall: a function that keeps a large object alive.

Deliverable: Three working closure examples with a spoken explanation of each.

Day 3 — Asynchronous operations

Write the same task with callbacks, promises and async/await, including error handling in each.
If JavaScript is not your primary language, map the same exercise to the one you use most (asyncio.gather in Python, CompletableFuture in Java, Task in C#) and note how errors propagate.
Write a sequential and a parallel version of three independent requests, for example with Promise.all, and note when each is correct.
Write a short spoken answer to how you manage asynchronous operations in your primary language.

Deliverable: One comparison table and a rehearsed answer on managing asynchronous work.

Day 4 — Memory: stack, heap and leaks

Sketch memory for a small program, labelling what lives on the stack and heap, and how references connect them.
List four leak sources in a long-running application and, for each, the symptom and the fix.
Write the diagnosis sequence you would follow: watch memory over time, capture snapshots, compare retained objects, trace to the owner.

Deliverable: A memory diagram and a leak-diagnosis checklist you can speak from.

Day 5 — Microservices versus a monolith

Write benefits and drawbacks on both sides, including deployment, scaling, data consistency, failure handling and operational load.
Pick two example situations and decide which architecture you would choose in each, with reasons.

Deliverable: A two-sided trade-off answer and two decisions with reasoning.

Day 6 — Behavioral stories, part one

Write STAR outlines for the most complex project, a technical disagreement and a time you learned a technology under a deadline.
For each story, write the alternatives you rejected and one measurable result.
Say each story aloud and trim it until the decision, not the background, takes most of the time.

Deliverable: Three rehearsed STAR stories with decisions and results written down.

Day 7 — Maintainability, staying current and a full mock

Prepare the answers for writing maintainable code and for staying current, each with one concrete example.
Run a full mock: five technical definitions, then the five behavioral questions, answering aloud in plain English.
Write down which answers needed the most repair and redo them.

Deliverable: Two prepared answers, a completed mock, and a short list of answers to redo.

Behavioral preparation for Andersen

The behavioral questions candidates report cover your experience and most complex project, technical disagreements, learning on a deadline, maintainable code and staying current. Candidates describe the work as distributed and international and name clear communication as important, so rehearse stories aloud. Prepare stories where you made the decision and can describe alternatives and results.