Automation Anywhere Software Engineer Interview Guide

The 60-second brief

Automation Anywhere builds Robotic Process Automation (RPA) and Conversational AI products that let organizations hand repetitive, rule-driven work to software. Candidates describe the engineering work as backend services, API integrations with other enterprise systems, and the frameworks behind automation features, with unit and integration tests written alongside. Engineers are described as working with product managers, QA engineers and Forward Deployed Engineers, who see how customers run the platform, and as owning a feature from build through deployment, including some client-facing production issues.

This guide is for candidates interviewing for a Software Engineer position at Automation Anywhere, most often on a Java backend team and, for certain teams, a C#/.NET one. It covers the five reported rounds, preparation for all eighteen reported questions (string and linked-list coding, Java internals and Spring, service and database design, project and release stories), and a seven-day plan. Candidates also report that the job title shifts the emphasis: Forward Deployed Engineer or Sales Engineer postings lean toward client-facing communication, while Staff postings lean toward backend system design.

Candidates report five rounds: Recruiter Screen, Online Assessment, Technical Interviews (two to three video rounds), Hiring Manager Round and HR Discussion. Reports of the total length range from two to six weeks, so confirm the schedule with your recruiter.

Focus areas

• Java
• Data Structures & Algorithms (DSA)
• Object-Oriented Programming (OOP)

Overview

The reported work is backend-heavy: designing and maintaining services, building API integrations, writing automation features and covering them with unit and integration tests. That explains the shape of the reported questions. Coding questions are small and fundamental (palindrome check, string reversal, in-place duplicate removal, a stack-and-queue problem, a linked-list manipulation). The language questions go into the runtime (garbage collection, multithreading, Spring patterns, a global exception handler, asynchronous execution). The design questions cover a movie ticket booking system, communication between microservices, an aggregating SQL query and the architecture of your own project at ten times the scale.

Candidates also tag these loops with Java, data structures and algorithms, object-oriented programming, Selenium-style automation frameworks and RPA. Java is described as the most common language, with C#/.NET for some teams, so pick one primary language and be ready to explain how its runtime works, not just its syntax. Familiarity with UiPath or BluePrism, cloud platforms (AWS, GCP, Azure), Docker and Kubernetes, and Rest Assured or Selenium appears under nice-to-have skills; the must-have list is an object-oriented language, data structures and algorithms, a backend framework such as Spring Boot or ASP.NET, database design with SQL, and clear communication with non-technical people.

The last two stages shift from code to experience. The Hiring Manager Round is reported to blend technical architecture with behavioral scenarios about past project impact, and the HR Discussion covers culture fit, career aspirations and compensation expectations. Production bugs, release pressure, SDLC and Agile, and explaining a technical decision to a non-technical person are the reported themes, and the project-architecture question belongs to both worlds. Build one project you can draw and defend, plus a handful of short stories; the plan at the bottom of this guide gives each its own day.

The Automation Anywhere interview process

These five stages are as candidates describe them; team and seniority change the details, including how many technical rounds you get. Treat the question types under each stage as practice targets rather than a promise of what you will be asked.

Recruiter Screen

Candidates describe the Recruiter Screen as a first conversation to line up your background, what you are looking for and whether the role fits. It is the stage where the job title matters: reports say Forward Deployed Engineer or Sales Engineer postings emphasise client-facing work, while Staff Software Engineer postings emphasise backend design. Prepare a short, specific account of your experience rather than a CV recital.

What to demonstrate

• Fit between your background and the specific role you applied for
• Whether your expectations and the role line up
• How clearly you summarise your experience

How to prepare

• Write a short career summary that ends on backend or integration work in Java or C#/.NET and why automation software interests you.
• Read the posting for your exact title and note whether it leans toward client-facing work or backend design, then match your examples to it.
• Prepare the logistics you may be asked about: notice period, location, work authorisation and preferred language for coding.
• Ask the recruiter which platform the online assessment uses and how many technical rounds your team runs.

Online Assessment

The Online Assessment is reported as a coding and algorithmic problem-solving test run on platforms such as HackerEarth or Glider. The reported coding question types, which suit this format, are string handling (palindrome check, reversal, in-place duplicate removal), a stack-and-queue problem and linked-list manipulation. The preparation is working code against test cases, so edge cases and complexity matter more than explanation.

What to demonstrate

• Correct, working code on algorithmic problems
• Choice of data structure and time and space complexity
• Handling of edge cases such as empty input, a single element or all-duplicate input

How to prepare

• Practise strings in a plain browser editor in your language, without IDE help, until palindrome, reversal and in-place duplicate removal are routine.
• Write a queue from two stacks and a stack from two queues, then a short problem that needs both, such as a level-by-level traversal that reverses each level.
• Write list reversal (iterative and recursive), cycle detection and merging two sorted lists, each with a stated Big-O.
• Read the input format first and practise reading from standard input in your language; format mistakes can fail every test case.

Technical Interviews

Candidates report two to three Technical Interviews over video conference covering coding, language-specific knowledge and system design, with code written live while sharing a screen. This is where the Java or .NET internals questions (memory management and garbage collection, concurrency, HashMap internals, Spring patterns) and the design questions (a movie ticket booking system, microservice communication, an aggregating SQL query) are practised, alongside the coding types from the assessment.

What to demonstrate

• Live coding quality and the ability to talk through a solution as you write it
• Understanding of how your language and runtime work: memory, threads, collections
• Service and database design and the trade-offs between performance, scalability and maintainability

How to prepare

• Rehearse out loud: state the brute-force approach in a sentence, then the optimised one, then write it, then test it on a small input.
• Be able to explain heap generations, reachability, common leak causes, thread lifecycle, a race condition and its fix, and what happens inside a HashMap on a collision.
• Practise the ticket-booking design with seat holds and double-booking prevention, and a microservice communication answer that names sync and async options.
• Write one aggregating SQL query across three tables and explain which join could multiply rows.

Hiring Manager Round

The Hiring Manager Round is reported as a mix of technical architecture and behavioral scenarios, centred on the impact of your past projects and leadership qualities. Candidates describe questions on the architecture of a recent project, production bugs and release pressure. Preparation is a project you can draw from memory, with your own contribution, decisions and results stated plainly.

What to demonstrate

• Depth of ownership in your most recent project: architecture, your contribution, the challenges
• Judgment under production and release pressure
• How you collaborate with product, QA and other teams, and how you lead

How to prepare

• Draw the architecture of your most recent project on one page and mark what you personally built, decided or fixed.
• Prepare the answer to scaling that project ten times: where it breaks first, what you would partition, cache or queue, and what you would measure.
• Write a production-bug story and a release-pressure testing story using the same structure: situation, action, result, what changed afterwards.
• Prepare one story about a disagreement with a product manager or teammate and how evidence settled it.

HR Discussion

Candidates describe the HR Discussion as covering culture fit, career aspirations and compensation expectations. Reports describe cultural alignment and clear communication about your project experience as mattering even after strong technical rounds, so prepare for this conversation instead of treating it as a formality.

What to demonstrate

• Motivation for this company and for automation and RPA work
• Where you want your career to go and whether this role fits it
• Alignment on compensation expectations

How to prepare

• Write a two-sentence answer on why Automation Anywhere and why a software engineering role in automation, tied to something you have built.
• Decide your career direction for the next few years (deeper backend, architecture, client-facing work) and be ready to connect it to the role.
• Research pay for your level and location from sources you trust and settle on a range and a response before the conversation.
• Keep your stakeholder-communication story ready, since it also shows how you work with non-engineers.

Where candidates lose points

Solving the string questions with a library call or extra buffer and stopping there

Calling StringBuilder.reverse(), or building a second string or a set for the duplicate question, answers a different question from in-place work. Be able to convert to a char array, swap with two pointers for reversal and the palindrome check, and compact duplicates with a write index, stating that Java strings are immutable and what the extra memory is.

Describing the garbage collector as "it frees unused memory"

Explain reachability from GC roots, young and old generations and why most objects die young, and when a collection pauses the application. Then name real leak causes in a managed language (static collections that only grow, unremoved listeners, ThreadLocal values on pooled threads) and how a heap dump finds them.

Listing concurrency keywords without showing a race and its fix

Write the unsynchronised counter that loses updates, then fix it three ways (synchronized, AtomicInteger, a ConcurrentHashMap or executor-based design) and say which you would use. Be able to describe thread states and how a deadlock forms and is broken by lock ordering.

Designing the ticket-booking system without handling two people choosing the same seat

Separate browsing (read-heavy, cacheable) from booking (write path). Put a short-lived seat hold in front of payment, enforce uniqueness on the seat and show in the database so a race loses cleanly, and release holds on expiry or failure.

Giving a project walkthrough with no numbers, no personal ownership and no answer for ten times the scale

Prepare one architecture diagram with traffic, data size and latency figures from your own system, mark what you built and decided, and name the first component that would break at ten times and the change you would make. Use "I" for your decisions and name your teammates for theirs.

Questions & practice

Write a program to check if a string is a palindrome.

Medium · Coding and Algorithms

Approach

1. Ask the rules first: is the check case-sensitive, and should spaces and punctuation count? 'A man, a plan, a canal: Panama' passes only if you skip non-alphanumerics and compare case-insensitively.
2. Use two pointers: i at 0 and j at length-1. Skip characters that do not count (Character.isLetterOrDigit), compare Character.toLowerCase of each side, and move both pointers inward. That is O(n) time and O(1) extra space.
3. Say why you are not comparing against a reversed copy: it is correct but costs O(n) extra memory and always scans the whole string, while two pointers can stop at the first mismatch.
4. Edge cases: the empty string and a single character are palindromes, and the loop condition i < j covers both odd and even lengths. Java chars are UTF-16 code units, so text with surrogate pairs (emoji) needs a comparison by code points.

Follow-up

• Can the string become a palindrome by deleting at most one character? At the first mismatch, try skipping the left character or the right one; that stays O(n).
• How would you find the longest palindromic substring? Expand around each of the 2n-1 centres for O(n^2), or use Manacher's algorithm for O(n).
• How do you check whether a singly linked list is a palindrome in O(1) extra space?

Write a function to reverse a string in your desired language.

Medium · Coding and Algorithms

Approach

1. In Java, String is immutable, so every solution builds a new string. The idiomatic one-liner is new StringBuilder(s).reverse().toString(). It runs in O(n), and its documentation says surrogate pairs are reversed as single characters.
2. To write it by hand: call toCharArray, swap chars[i] and chars[n-1-i] with two pointers until they meet, then return new String(chars). That is O(n) time and O(n) space for the copy, which is unavoidable with immutable strings.
3. Name the traps. Writing result = c + result in a loop copies the string on every iteration and costs O(n^2). A recursive version uses O(n) stack depth and can throw StackOverflowError on long input.
4. Edge cases: null input (decide whether to throw or return null), the empty string, and Unicode. A naive char swap splits surrogate pairs, and even code-point reversal moves combining accents onto the wrong letter.

Follow-up

• Reverse the order of the words in a sentence, handling repeated spaces. One option: reverse the whole string, then reverse each word.
• How would you reverse in place in a language with mutable strings, such as a C char array?
• Reverse only the vowels, or only the letters, and leave everything else where it is.

Remove duplicates in-place from a given String.

Medium · Coding and Algorithms

Approach

1. Clarify which duplicates go. Is it every repeat, keeping the first occurrence ('banana' -> 'ban'), or only adjacent repeats ('aabbcc' -> 'abc')? Is the check case-sensitive? Because Java strings are immutable, 'in-place' means working on a char[].
2. For first-occurrence dedupe, use read and write pointers over the char[] plus a boolean[] seen array sized to the alphabet (128 for ASCII). When a character is unseen, copy it to chars[write++]. Return new String(chars, 0, write). That is O(n) time and O(1) extra space for a fixed alphabet.
3. For adjacent duplicates, drop the seen array and compare each character with chars[write-1]. This also dedupes a sorted string.
4. If no extra memory is allowed at all, scan chars[0..write) for each character: O(n^2) time, O(1) space. Sorting first gives O(n log n) but loses the original order, so say which trade-off you are making. Test the empty string, a single character and an all-same string.

Follow-up

• Remove adjacent duplicate pairs repeatedly until none are left ('abbaca' -> 'ca'). Use the write index as a stack for O(n).
• Keep at most k copies of each character instead of one.
• Return the lexicographically smallest subsequence that contains every distinct character exactly once, using a monotonic stack.

Solve a problem requiring the combined use of a stack and a queue.

Medium · Coding and Algorithms

Approach

1. The prompt is open-ended, so pin down the problem first. Common versions: build a queue from two stacks, build a stack from queues, check a palindrome by pushing each character onto a stack and a queue and comparing pop() with poll(), or reverse the first k elements of a queue using a stack.
2. For a queue from two stacks: push onto an in-stack, and pop from an out-stack. Move everything from in to out only when out is empty. Each element moves at most once, so every operation is amortized O(1), even though a single dequeue can cost O(n) in the worst case.
3. For a stack from one queue: after each offer, rotate the previous size-1 elements to the back. Push becomes O(n) and pop O(1). Say which operation you made expensive and why.
4. In Java, use ArrayDeque for both structures instead of the legacy Stack class, which extends synchronized Vector. ArrayDeque rejects null elements. Handle empty structures explicitly: pop throws NoSuchElementException, while poll returns null.

Follow-up

• Add getMin() to the queue (or the stack) in O(1).
• Compute the maximum of every sliding window of size k in O(n) using a monotonic deque.
• How would you make the two-stack queue safe for concurrent producers and consumers?

Given a linked list, write an optimized solution to manipulate it and explain your time and space complexity.

Medium · Coding and Algorithms

Approach

1. Ask which manipulation is wanted. Candidates report reversal, cycle detection and merging for linked lists, so have all three ready, plus finding the middle and removing the nth node from the end.
2. For iterative reversal, keep prev, curr and next. Save curr.next before you rewire, point curr.next at prev, then advance. That is O(n) time and O(1) space. The recursive version is also O(n) time but uses O(n) stack and can overflow on long lists.
3. For cycles, use Floyd's algorithm: slow moves one step and fast moves two, and if they meet there is a cycle. To find where the cycle starts, reset one pointer to head and advance both one step at a time; they meet at the start of the cycle. O(n) time, O(1) space.
4. For merging two sorted lists, use a dummy head and a tail pointer, splice the smaller node each time, and append the leftover list at the end: O(m+n) time, O(1) extra space. Trace the null list, the single-node list and the two-node list before you call the code done.

Follow-up

• Reverse the nodes in groups of k, leaving a short final group as it is.
• Reverse only the sublist between positions m and n in one pass.
• Find the node where two singly linked lists intersect, without extra memory.

Explain Java memory management and the role of the Garbage Collector.

Medium · Core Java and Frameworks

Approach

1. Lay out the memory areas. Each thread has its own stack of frames holding local primitives and references. Objects live on the shared heap. Class metadata lives in Metaspace, which replaced PermGen in Java 8 and uses native memory.
2. Explain reachability. The collector traces from GC roots (thread stack locals, static fields, JNI references), and anything unreachable is garbage. This is not reference counting, so cycles of objects that point only at each other are still collected.
3. Explain the generational model. New objects go to Eden. A minor GC copies survivors between the two survivor spaces and promotes objects that pass the tenuring threshold to the old generation. Name the collectors: Serial, Parallel, G1 (the default since JDK 9, region-based, with a pause-time target set by -XX:MaxGCPauseMillis), and the low-pause concurrent ZGC and Shenandoah.
4. A Java memory leak is an object that is still reachable but no longer needed. Typical causes: static collections that only grow, unbounded caches, listeners that are never removed, and ThreadLocal values left on pooled threads. To diagnose one, enable -XX:+HeapDumpOnOutOfMemoryError or take a dump with jmap or jcmd, open it in Eclipse MAT's dominator tree, and read the GC logs (-Xlog:gc*).

Follow-up

• What is the difference between OutOfMemoryError: Java heap space, Metaspace, and GC overhead limit exceeded?
• When would you use a WeakReference or SoftReference, and what does WeakHashMap do with its keys?
• Why is calling System.gc() only a hint, and why is finalize() deprecated?

How do you handle multithreading and concurrency in Java?

Medium · Core Java and Frameworks

Approach

1. Start with how threads are run. Use an ExecutorService or a ThreadPoolExecutor with a bounded queue and an explicit rejection policy rather than raw new Thread(). Compose results with CompletableFuture, and shut pools down cleanly.
2. Match the tool to the shared state. synchronized gives mutual exclusion plus visibility through happens-before. volatile gives visibility and ordering, but count++ on it is still a race. AtomicInteger or LongAdder use CAS for counters. ReentrantLock adds tryLock with a timeout, fairness and Condition objects.
3. Use concurrent collections. In ConcurrentHashMap, compute, merge and computeIfAbsent are atomic per key, and the map rejects null keys and values. CopyOnWriteArrayList suits lists that are mostly read. BlockingQueue implementations such as ArrayBlockingQueue handle producer-consumer handoff.
4. Deadlock needs all four Coffman conditions. Prevent it with a consistent lock order or tryLock with a timeout, and find it with a thread dump (jstack or jcmd Thread.print), which reports Java-level deadlocks. The cheapest way to stay safe is immutable objects and confining state to one thread.

Follow-up

• Why is 'if (!map.containsKey(k)) map.put(k, v)' wrong on a ConcurrentHashMap, and what do you use instead?
• Why does double-checked locking for a lazy singleton need the field to be volatile?
• When do virtual threads help, and why do they not speed up CPU-bound work?

Write an optimized SQL query to fetch and aggregate data from multiple tables.

Medium · System Design and Architecture

Approach

1. Start from the grain of the result, for example one row per customer per month. Ask about the keys and whether each join is one-to-one or one-to-many before writing anything.
2. Prevent fan-out. If a customer joins to both orders and payments, each order row repeats once per payment and the SUMs inflate. Aggregate each many-side table in its own CTE or subquery down to the result grain, then join those aggregates. COUNT(DISTINCT) only patches counts and does nothing for SUMs.
3. Handle the rows with no match. LEFT JOIN keeps entities with no activity, and COALESCE(SUM(x), 0) turns their NULLs into zeros. Under a LEFT JOIN, COUNT(*) counts the null-extended row as 1, so use COUNT(o.id). A filter on the right-hand table belongs in ON, because putting it in WHERE turns the LEFT JOIN into an inner join.
4. Make it fast. Index the join keys and filter columns, for example a composite index on (customer_id, order_date). Keep predicates sargable by writing order_date >= '2026-01-01' AND order_date < '2026-02-01' rather than wrapping the column in a function. Filter rows in WHERE before grouping, and use HAVING only for conditions on aggregates. Read EXPLAIN ANALYZE for sequential scans and row-estimate errors.

Follow-up

• Return the top 3 products by revenue in each category using ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...). How do you handle ties?
• Why does NOT IN return no rows when the subquery contains a NULL, and why is NOT EXISTS safer?
• The query is still slow on a much larger table. What do you check in the plan, and when would you precompute the aggregate?

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

1. 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.
2. 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.
3. 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.
4. 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?

What are the differences between various Spring design patterns?

Medium · Core Java and Frameworks

Approach

1. Singleton: Spring beans are singleton-scoped by default, but that means one instance per ApplicationContext, not the GoF one-per-classloader. Because one instance serves every request thread, beans must be stateless or thread-safe. Prototype scope creates a new instance for each lookup or injection.
2. Factory and IoC: BeanFactory and ApplicationContext create and wire beans, and a FactoryBean wraps complex construction. Dependency injection (constructor injection preferred) replaces the object finding its own dependencies.
3. Proxy: @Transactional, @Async and @Cacheable work through AOP proxies, either JDK dynamic proxies (interface-based) or CGLIB subclasses (Spring Boot defaults to class-based proxies). A self-invocation inside the same class bypasses the proxy, so the annotation does nothing there. CGLIB cannot proxy final classes or methods.
4. Template Method: JdbcTemplate and RestTemplate own resource handling and call back into your code. Observer: ApplicationEvent with @EventListener. Front Controller: Spring MVC's DispatcherServlet. Adapter: HandlerAdapter. Strategy: several implementations of one interface chosen with @Qualifier or by injecting a List or Map of them. Give one example from your own code for each pattern you name.

Follow-up

• Why does @Transactional have no effect when the method is called from another method in the same class, and how do you fix it?
• What happens when you inject a prototype bean into a singleton, and how do ObjectProvider or @Lookup change that?
• What is the difference between a JDK dynamic proxy and a CGLIB proxy?

How do you implement a Global Exception Handler in your backend framework?

Medium · Core Java and Frameworks

Approach

1. In Spring, write a @RestControllerAdvice class (@ControllerAdvice plus @ResponseBody) with @ExceptionHandler methods per exception type. When several handlers match, the one closest in the exception hierarchy wins. In ASP.NET Core, the equivalent is UseExceptionHandler middleware or an IExceptionHandler (.NET 8 and later) returning ProblemDetails.
2. Define one error contract: a stable error code, a message safe to show users, a correlation or trace id, and field errors for validation. Spring 6 and Boot 3 support ProblemDetail (RFC 9457, which replaced RFC 7807), and extending ResponseEntityExceptionHandler covers built-in exceptions such as MethodArgumentNotValidException.
3. Map exceptions to status codes on purpose: validation errors to 400, not found to 404, conflicts to 409, auth failures to 401/403. Add a catch-all Exception handler that returns 500, logs the stack trace with the correlation id, and never puts the stack trace in the response.
4. Know the limits. Controller advice only sees exceptions thrown while a handler method runs. Exceptions from servlet filters, including Spring Security's, go to an AuthenticationEntryPoint or AccessDeniedHandler. Exceptions from void @Async methods go to an AsyncUncaughtExceptionHandler.

Follow-up

• How would you handle an exception thrown inside a servlet filter so it uses the same error format?
• How do you test the handler, for example with MockMvc or WebTestClient?
• How do you keep error codes stable for API clients as the exception classes change?

Explain the concepts of asynchronous execution and integration in your current tech stack.

Medium · Core Java and Frameworks

Approach

1. Separate in-process asynchrony from asynchronous integration between systems. Then pick the one your current stack uses and explain it end to end with one real flow.
2. In-process Java: CompletableFuture.supplyAsync uses ForkJoinPool.commonPool by default, so pass your own executor for blocking I/O. Chain with thenApply and thenCompose, fan in with allOf, and handle failures with exceptionally or handle. Spring's @Async needs @EnableAsync and a configured TaskExecutor, and self-invocation bypasses it. One reported variant asks about asynchronous Apex; if your stack is Salesforce, know when to use @future, Queueable and Batch Apex.
3. Integration through a broker (Kafka, RabbitMQ, SQS): delivery is usually at-least-once, so consumers must be idempotent, for example by deduplicating on a message id. Use the transactional outbox pattern so a database write and its event cannot diverge.
4. Failure handling: set a timeout on every remote call, retry only idempotent operations with exponential backoff and jitter, send poison messages to a dead-letter queue, and add a circuit breaker such as Resilience4j. Remember that MDC trace ids and the security context do not follow work onto another thread automatically.

Follow-up

• A consumer processed a message, then crashed before committing the offset. What happens, and how does your design cope?
• How do you propagate a trace id across thread pools and message hops?
• When would you choose a synchronous REST call over a queue for an integration?

Design a highly scalable movie ticket booking system.

Medium · System Design and Architecture

Approach

1. Scope it first. Functional: browse movies and shows by city, view the seat map, hold seats, pay, and get confirmation. Non-functional: never sell one seat twice, handle heavy read traffic on listings, and survive spikes when a popular film opens. Then estimate reads per second against bookings per second.
2. Data model: Theatre, Screen, Seat, Show, and ShowSeat(show_id, seat_id, status, held_by, hold_expires_at, version), plus Booking and Payment. ShowSeat is the contended table, so partition by show_id. All contention for a seat stays inside one show.
3. Hold seats atomically. In one transaction, run an UPDATE that sets status to HELD only WHERE the seat is AVAILABLE or its hold has expired, then check that the affected row count equals the number of seats requested, and roll back if it does not. Alternatives: SELECT ... FOR UPDATE, optimistic locking on version, or Redis SET NX with a TTL per seat. Expired holds release seats when a payment is abandoned.
4. Payment: create the booking as PENDING with an idempotency key, confirm it from the gateway callback, and make the callback handler idempotent. If payment succeeds after the hold has expired and the seat has been resold, refund automatically.
5. Scale the read path separately. Cache listings and show times, serve static assets from a CDN, and use a search index for discovery. The seat map can be slightly stale, but the hold write is always authoritative. For a release spike, put a virtual waiting room in front of the hold service.

Follow-up

• The payment succeeds after the seat hold has expired. What does the system do?
• How do you show seat availability in near real time to thousands of users viewing the same show?
• Bookings for one blockbuster opening overload a single partition. What do you change?

Walk me through the architecture of your most recent project. What would you change if you had to scale it 10x

Medium · System Design and Architecture

Walk me through the architecture of your most recent project. What would you change if you had to scale it 10x?

Approach

1. Open with one sentence on what the system does and who uses it. Then walk through the components in the order a request touches them: client, API or gateway, services, data stores, queues, third-party integrations. Say clearly which parts you built or owned.
2. Trace one core request end to end, and give the numbers you know: requests per second, data size, p95 latency, peak versus average load. Without a baseline, '10x' has no concrete meaning.
3. Find the first bottleneck from evidence such as load tests, profiles or dashboards. Common ones are database write throughput, connection-pool limits, a stateful single instance, or synchronous calls to a slow dependency.
4. Match the fix to that bottleneck: stateless services behind a load balancer with autoscaling; read replicas and caching with a clear invalidation rule for read-heavy paths; partitioning for write-heavy tables; queues for slow work; rate limits on external callers.
5. State the trade-off and what you would leave alone. Replicas bring replication lag and read-your-writes problems, caches bring staleness, and splitting a monolith adds network failure modes. Say why a part that already scales horizontally stays as it is.

Follow-up

• How would you prove which component fails first at 10x before changing anything?
• After you add a read replica, a user cannot see the record they just saved. How do you fix it?
• If you rebuilt this project from scratch, which decision would you reverse first, and why?

One customer endpoint stalls deliveries to every other destination

Medium · bulkhead · timeouts · saturation

The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.

Approach

1. Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
2. Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
3. Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
4. Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.

Follow-up

• The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
• Where should the 10-second timeout number actually come from?

Suggested practice checklist

Each day targets one of the reported question groups, from in-place string coding through Java runtime, Spring, SQL and system design, ending with the project and release stories used in the manager and HR stages.

Day 1 — Strings: palindrome, reversal, in-place duplicates

• Write the palindrome check with two pointers and decide how to treat case and punctuation; state what you would ask first.
• Write string reversal on a char array by swapping from both ends, then state why Java strings need that array.
• Write in-place duplicate removal with a write index for a sorted input, then the unsorted version using a boolean array or set, and note the extra space.
• Test each on empty, single-character, all-identical and already-clean input.

Deliverable: Three working solutions (palindrome, reversal, duplicate removal) with their complexity and a list of the edge-case inputs you ran on each.

Day 2 — Stack, queue and linked list

• Build a queue from two stacks and a stack from two queues, and state the amortised cost of each operation.
• Write one problem that needs both structures, such as reversing each level of a breadth-first traversal.
• Write iterative and recursive linked-list reversal, Floyd cycle detection and merging two sorted lists, with time and space stated.
• Do each once in a plain editor to match the online assessment setting.

Deliverable: Working code for both structure conversions, the combined problem and three linked-list operations, each with its Big-O written next to it.

Day 3 — Java runtime: memory, garbage collection and concurrency

• Write a one-page sheet on stack versus heap, young and old generations, reachability and how a collector pause happens, plus three leak causes.
• Write a counter shared by several threads that loses updates, then fix it with synchronized, AtomicInteger and a ConcurrentHashMap or executor.
• Explain HashMap internals: bucket index, collision handling, resizing and the effect of a bad hashCode.
• Say your answers aloud as if to a listener, once each.

Deliverable: A one-page memory and concurrency sheet plus a runnable race demo with all three fixes.

Day 4 — Spring patterns, global exception handling and async

• List the patterns visible in Spring (singleton scope, factory through the bean container, proxy for transactions and AOP, template classes, observer through application events) and what each solves.
• Build a small Spring Boot or ASP.NET endpoint with a global exception handler (a @ControllerAdvice class with @ExceptionHandler methods in Spring) that returns one consistent error body and status codes.
• Add an asynchronous call (@Async or CompletableFuture) and write what happens to exceptions raised on another thread.

Deliverable: A small running service with a global handler and one async call, plus a half-page comparing the Spring patterns by problem solved.

Day 5 — SQL aggregation and microservice communication

• Write an aggregating query across three tables, naming the grain first and checking each join for row multiplication before you aggregate.
• Work the practice SQL exercise on fan-out joins to rehearse the one-to-many trap.
• Write a decision table for service communication: synchronous REST or gRPC versus broker-based events, covering timeouts, retries, idempotency, the outbox pattern and sagas.

Deliverable: A tested multi-table aggregate query with the index it would use, and a one-page communication decision table with an example from your own project in each row.

Day 6 — System design: ticket booking and your project at 10x

• Design the movie ticket booking system: separate browse and booking paths, seat holds with expiry, uniqueness on seat and show, payment failure handling, and what you cache.
• Draw your most recent project on one page, mark what you built, and write the first three things that would break at ten times the load and the change for each.
• Say both designs aloud, starting with the questions you would ask about scale and consistency.

Deliverable: One booking-system diagram with the double-booking strategy written beside it, and one annotated architecture page of your own project with a ten-times plan.

Day 7 — Production, release and stakeholder stories, then a full run

• Write the production-bug story: symptom, containment, diagnosis path, root cause, fix, prevention.
• Write the release-pressure testing story and the stakeholder story, each with the decision you made and the result.
• Prepare a spoken answer on SDLC and Agile from your team's real practice.
• Rehearse the practice debugging exercise aloud, then run the five rounds back to back: a short recruiter pitch, a coding problem, a Java question, a design question and the three stories.

Deliverable: Four story outlines (production bug, release pressure, SDLC and Agile, stakeholder) and a recorded or written run of the full sequence with the weakest answer marked.

Project, release-pressure and stakeholder stories

Candidates report that the Hiring Manager Round blends architecture with behavioral scenarios about past project impact and leadership, and that the HR Discussion covers culture fit and career aspirations. The reported themes are production bugs, release pressure, SDLC and Agile practice, working with product and QA teams, and explaining technical decisions to non-technical people. Prepare each story with the same skeleton: the situation in two sentences, the decision you owned, the evidence you used and the measured result.

1. Explain the architecture of your current project and why you chose a particular technical approach.
2. How would you go about creatively and systematically testing a physical object, like a pen?

How do you handle communication between different microservices?

Medium · System Design and Architecture

Approach

1. Although this question is filed under behavioral, it is a technical one: answer it with real systems. Split on whether the caller needs the answer now. Request/response over REST or gRPC fits queries and commands where the caller waits; a message broker (Kafka, RabbitMQ, SQS) fits work that can finish later or must fan out to several consumers. Name one real call from a system you built for each style.
2. For synchronous calls, say what happens when the callee is slow or down: a timeout on every call, retries with exponential backoff and jitter only on idempotent operations, a circuit breaker so a failing dependency is not hammered, and a fallback or a clear error. Unbounded retries across several hops multiply load.
3. For asynchronous messaging, state the delivery guarantee. Brokers are usually at-least-once, so consumers must be idempotent (dedupe on a message id or a natural key). Use the outbox pattern when a service must update its database and publish an event, so the two cannot disagree, and add a dead-letter queue for poison messages and a partition key where per-entity ordering matters.
4. For a business flow that spans services, avoid distributed transactions. Use a saga with compensating actions, orchestrated by a coordinator or choreographed through events, and say what the user sees while it is in flight.
5. Cover the cross-cutting parts: an API gateway at the external edge, service discovery, versioned contracts with additive-only changes plus consumer contract tests, and a correlation id carried through every call and message so one request can be traced.

Follow-up

• A consumer receives the same event twice after a rebalance. What breaks, and how do you make it safe?
• How do you add a required field to an event without breaking consumers that have not upgraded?
• When would you choose gRPC over REST between two internal services?

Walk me through a challenging bug you faced in production and how you resolved it.

Medium · Behavioral and Project Experience

Approach

1. Choose a bug whose cause was not obvious and where you drove the diagnosis. Open with symptom and impact in two sentences: what users or downstream systems saw, how it was detected (an alert or a customer report) and how widely it hit.
2. Separate containment from the cause. Say what you did first to stop the damage (rollback, feature flag off, scaling out, pausing a job) and why that was safe, before you describe root-cause work.
3. Narrate the diagnosis as hypotheses and the evidence that eliminated each: logs and metrics around the first failure, a deploy or configuration diff, a reproduction in a test environment, and for a Java service a thread dump (deadlock, exhausted pool) or a heap dump (leak). Name the actual root cause, not the symptom.
4. Close with the fix and what changed so the class of bug cannot return: a regression test, an alert, a review checklist item or a runbook entry. Give a concrete result, such as the error rate back at baseline, with a number if you have one.
5. Use "I" for your own actions and name teammates where they helped. A story told only in the plural hides your contribution, and one where you only escalated gives nothing technical to discuss.

Follow-up

• How did you confirm the root cause rather than a change that merely correlated with it?
• What would have caught this before it reached production?
• Was there a moment you considered rolling back, and what decided it?

How do you prioritize test cases when facing strict release pressure?

Medium · Behavioral and Project Experience

Approach

1. Frame it as risk-based testing: rank cases by the business impact if they fail, multiplied by the likelihood that they fail. Take likelihood from what changed in this release: modules in the diff, recent defect history, new integrations.
2. State the tiers. First a smoke set over the core user and API paths, then regression for the changed and adjacent components, then low-risk and cosmetic cases last. Say what runs automatically (for example a Selenium and TestNG UI suite, Rest Assured checks against service APIs) and what needs manual exploration because the feature is new.
3. Show you can cut scope without hiding it: record which cases were deferred and why, and tell the product owner or release manager the remaining risk in plain terms, so shipping is a decision made with the facts.
4. Anchor it in a real release: what you kept, what you cut, what you found, and the outcome afterwards (escaped defects, a hotfix or none). Add what you would change next time, such as fixing flaky tests or running the suite in parallel.

Follow-up

• How do you decide whether a known low-severity defect blocks the release?
• The regression suite turns flaky the night before release. What do you do?
• What would you automate first if you inherited a manual-only test plan?

Explain your understanding of the Software Development Life Cycle (SDLC) and Agile methodologies.

Medium · Behavioral and Project Experience

Approach

1. Walk the SDLC stages in order (requirements, design, implementation, testing, deployment, maintenance) and attach one concrete thing you did at each stage in a recent project, instead of reciting definitions.
2. Contrast the models briefly. Waterfall suits fixed, well-understood scope with heavy sign-off; Agile suits scope that shifts, delivered in short iterations with feedback. Say which your team used and why.
3. Describe Scrum as you have lived it: backlog refinement, sprint planning, daily stand-up, sprint review and retrospective; the product owner, scrum master and developer roles; how you estimate; and your team's definition of done (code review, unit and integration tests passing, deployed to a test environment).
4. Connect Agile to engineering practice: a pipeline that runs tests on every merge, code review, short-lived branches, and QA working with developers inside the sprint instead of after it.
5. Finish with one example where process changed an outcome, such as a retrospective action that cut rework or a mid-sprint change you handled by renegotiating scope.

Follow-up

• What does your team do when a requirement changes in the middle of a sprint?
• Where did an Agile ceremony not help your team, and what did you adjust?
• How do you handle testing and release when stories finish late in the sprint?

Tell me about a time you had to explain a technical decision to a non-technical stakeholder.

Medium · Behavioral and Project Experience

Approach

1. Pick a decision with a real trade-off that affected the stakeholder: delaying a feature to fix a data-model problem, buying a managed service instead of building one, or refusing a shortcut that raised outage risk. A purely internal tooling choice gives you little to show.
2. Set the context in two sentences: who the stakeholder was (a product manager, a client-facing engineer, a customer), what they cared about and what they asked of you.
3. Show the translation. Open with the outcome and the options in their terms (cost, delivery date, risk to customers), use one analogy or a simple diagram instead of jargon, and give a recommendation with its downside stated.
4. Show you checked understanding, for example by asking them to restate the trade-off or by following up in writing, and say what they decided and what happened after.
5. The mistake that sinks it is a story where you only simplified the language, presented no options, and the other person simply agreed. Include their pushback and how you answered it.

Follow-up

• What did the stakeholder push back on, and how did you respond?
• What would you have done if they chose the option you advised against?
• How did you confirm they understood the risk you described?