ABC Education Software Engineer Interview Guide

The 60-second brief

Candidate write-ups describe the role as building educational tools and digital environments for students, educators and administrators. Engineers in this role work on the stack behind them, which candidates describe as RESTful APIs, microservices, user interfaces and deployment automation with Docker and Kubernetes. The requirements candidates describe list Java, Python, JavaScript, TypeScript or C++, frameworks such as Spring Boot, Node.js, ReactJS or Salesforce LWC, relational SQL with NoSQL familiarity, Terraform, CI pipelines and Git. Experience with AWS, GCP or Azure, Kafka or Socket.io, and education software is listed as a plus.

This guide is for engineers interviewing for the Software Engineer role at ABC Education, from early-career candidates to mid and senior engineers. It covers the three reported stages, the 24 questions candidates report (coding, backend and microservices, frontend, databases and cloud, behavioral) and a seven-day plan. Candidates report that early-career loops lean on data structures and framework basics, while mid and senior loops add architecture, security and infrastructure.

Candidates report three stages over roughly three to five weeks: a Recruiter Phone Screen, a Technical Screen in a shared coding environment, and an Onsite Interview Loop of several virtual rounds covering coding, system design and behavioral questions. Reports of the total timeline vary, so confirm the schedule with the recruiter.

Focus areas

• Programming (general coding ability)
• Problem Solving / Coding interviews
• Microservices architecture

Overview

The reported questions cover more ground than a typical algorithms loop. Five are classic coding problems: string-to-integer conversion, unique pairs that reach a target sum, reversing a linked list, a maximum-subarray dynamic programming problem and level-order traversal. Fifteen more cover backend concurrency and transactions, REST design and security, microservices, JavaScript and component frameworks, SQL, Kubernetes, Docker, Terraform and CI/CD. Four are behavioral prompts. Preparing only for the coding problems leaves most of the list untouched.

The stack candidates describe is a web-service stack: Java, Python, JavaScript, TypeScript or C++; Spring Boot or Node.js on the server; ReactJS or Salesforce LWC on the client; SQL first and NoSQL second; Docker, Kubernetes, Terraform and CI. Several questions are worded around specific tools (controller annotations, Lightning Data Service, Socket.io, the Kubernetes API server and etcd), so vocabulary matters. For each topic, prepare the mechanism rather than the definition: what happens on the wire, in the database or in the cluster, and what goes wrong.

Level changes the mix. Candidates report that early-career loops lean on data structures, syntax and framework basics, while mid and senior loops add microservice boundaries, API security, containers, infrastructure provisioning and project walk-throughs. At any level, plan to write code live in a shared environment, so the algorithm questions are the floor, not the ceiling.

Two reported questions are tied to Salesforce tooling (LWC iterators and Lightning Data Service), and the requirements list Salesforce LWC as one framework option among several. If it is not on your resume, learn what each term means and be ready to say which framework you are answering from, since one question is worded around LWC or modern frontend frameworks.

The ABC Education interview process

These are the stages candidates describe. Which question appears in which round is not reported, so the questions below are grouped by topic. Candidates also mention resume screening before the first call and a managerial and HR conversation at the end, about project accomplishments and team collaboration.

Recruiter Phone Screen

The first call is described as a conversation about your experience, what you want next and what the job involves, with a talent acquisition specialist or a hiring manager after resume screening. Treat it as the stage where your history gets matched to the stack the role lists: Java, Python, JavaScript, TypeScript or C++, Spring Boot or Node.js, ReactJS or LWC, SQL, Docker, Kubernetes and Terraform. Arrive with a tight story and with questions about what the rest of the loop looks like.

What to demonstrate

• How your background lines up with the languages, frameworks and cloud tooling the role lists
• Your career goals and what you want from the role

How to prepare

• Write a short spoken version of your resume ordered by the role's stack. Name the language you would code in and one project each for backend, frontend and infrastructure that you can speak to.
• Pick two projects you can walk through line by line: architecture, the choices you made and the hardest problem. Candidates report project walk-throughs in later rounds, so this work is reused.
• Prepare questions: which team or domain, whether the Technical Screen is an online assessment or a live shared editor, and which areas the loop emphasises at your level.
• Have the logistics ready: notice period, location constraints and your position on compensation, which candidates report comes up during the process.

Technical Screen

The reported screen is a live coding exercise in a shared editor on an algorithm or data-handling task. Write-ups also mention online coding challenges or aptitude tests on logic, CS fundamentals and basic programming earlier in the process. The coding questions reported across the loop are string-to-integer conversion, unique pairs that sum to a target, reversing a linked list, a maximum-subarray dynamic programming problem and level-order traversal of a binary tree; the reported SQL question asks for the second highest salary. This is the stage to rehearse them as live, runnable code.

What to demonstrate

• Working code on an algorithm or data-handling task in a shared editor
• Time and space complexity of the approach you choose
• Edge-case handling, such as empty input, duplicates, sign characters and overflow

How to prepare

• Practise in a plain editor with no autocomplete, in the language you will use, and run your own tests before saying you are done. Clarify input limits and edge cases before you type.
• Do the reported coding problems cold, each with a stated brute-force version, an improved version and its complexity: Kadane's scan for maximum subarray, a hash set or sort plus two pointers for unique pairs, a queue with a per-level snapshot for level order.
• Write the string-to-integer function against a checklist: whitespace, sign, non-digit characters, empty string, and an overflow check before each multiply-add.
• Write the second-highest-salary query in two portable forms (a subquery on MAX, and a distinct-count form) and say what each returns when fewer than two distinct salaries exist.

Onsite Interview Loop

Candidates describe several virtual rounds covering coding, system design and behavioral questions, with senior engineers and engineering leads in the technical conversations. Reports describe those technical conversations as coding-heavy, with mid and senior candidates also asked about architecture, containers and past projects. A managerial and HR conversation is described as closing the process. This is the broadest stage, so the backend, frontend, infrastructure and behavioral topics in this guide are the ones to rehearse for it.

What to demonstrate

• Coding in a live setting, since the multi-round format includes it
• System design and architecture, including microservice boundaries and API security, at mid and senior level
• Backend, database and API knowledge: concurrency, transactions, REST and authentication
• Behavioral answers about teamwork and project accomplishments

How to prepare

• Backend set: thread pools, synchronization and deadlock avoidance; isolation levels and connection pooling; REST controller annotations with global exception handling; JWT and OAuth2 on public endpoints. Say what each does under load.
• Architecture set: microservice communication (synchronous calls versus messaging), service discovery, and fault tolerance with timeouts, retries and circuit breakers. Add how to keep data consistent across service databases without tight coupling.
• Frontend and infrastructure set: event bubbling versus capturing, React state and re-rendering, LDS and Socket.io; the Kubernetes control plane, a multi-stage Dockerfile, a Terraform layout and a CI/CD pipeline with blue-green deployment.
• Rehearse four STAR stories aloud (disagreement, competing priorities, a pressured diagnosis, working with non-technical stakeholders) plus one project walk-through.

Where candidates lose points

Converting a string to an integer without handling sign, whitespace, bad characters or overflow

List the cases before coding: initial whitespace, a + or - sign, an empty string, a non-digit character and values beyond the integer range. Build the number digit by digit (digit = character minus '0') and test for overflow before each multiply: it overflows when result > MAX/10, or when result == MAX/10 and digit > MAX%10 (the (INT_MAX - digit) / 10 comparison covers both), so overflow is caught instead of wrapping. Run those cases before you say you are finished.

Returning duplicate pairs, or settling for the nested loop, on the target-sum problem

Ask whether a pair means values or indices and whether (a, b) is the same as (b, a). Say the O(n^2) loop, then give a hash-set pass or a sorted two-pointer pass that skips repeated values: O(n) with a set, O(n log n) with the sort. Test with repeated numbers and with a target that needs the same value twice.

Reciting definitions of JWT, OAuth2, isolation levels or Kubernetes components with no mechanism

For each topic prepare the mechanism and the failure. For JWT: signature, expiry and audience checks, the algorithm fixed on the server, and what happens when a token leaks. For isolation levels: which anomaly each one permits. For Kubernetes: what the API server persists in etcd and how the kubelet reconciles. A definition with no failure mode leaves you nothing to build on when the follow-up arrives.

Telling every behavioral story as 'we' with no decision of your own

In the disagreement, prioritisation, pressured-diagnosis and stakeholder stories, name the decision you made, the alternative you rejected and the result you measured. Use a number or an observable outcome you actually have, and be able to say what you would do differently.

Giving a Dockerfile or Terraform answer that only works on a laptop

Write both from scratch once. A Dockerfile needs a pinned base image, a multi-stage build that copies only the built artifact into a small final stage, dependency files copied before source for layer caching, a non-root user and CMD in exec form. For Terraform, say where state lives (a remote backend with locking, not a local file) and how variables and provider versions are pinned.

Questions & practice

Write a program to convert a given string representation into a numerical format without using built-in conver

Medium · Data Structures & Algorithms

Write a program to convert a given string representation into a numerical format without using built-in conversion functions.

Approach

1. Scan once, left to right: skip initial whitespace, read an optional '+' or '-', then turn each character into its value with ch - '0' (ord(ch) - ord('0') in Python) and accumulate result = result * 10 + digit.
2. Agree the contract before coding: stop at the first non-digit or reject the whole string, and clamp on overflow or raise an error. Both choices are defensible, so say which one you picked.
3. Check for overflow before the multiply. For a 32-bit target, if result > (INT_MAX - digit) / 10, the next step overflows. Accumulating as a negative number also handles INT_MIN, whose magnitude is one larger than INT_MAX.
4. Cost is O(n) time and O(1) extra space. Edge cases to test aloud: empty string, a sign with no digits, "+-5", zeros at the front, trailing letters, and exactly INT_MAX and INT_MIN.

Follow-up

• How would you extend this to parse decimals and an exponent such as "-1.5e3"?
• How does the code change for a hexadecimal or arbitrary base input?
• Should a value that overflows return an error or a clamped value, and who decides?

Given an array of integers, find all unique pairs that sum up to a target value in optimal time complexity.

Medium · Data Structures & Algorithms

Approach

1. Clarify what "unique" means: unique by value, so (2,4) and (4,2) count once and duplicates in the input do not create repeat pairs. Also ask whether one element may pair with itself.
2. Hash approach: walk the array with a set of seen values. If target - x is in seen, add (min, max) to a result set, then add x to seen. This takes O(n) expected time and O(n) space. Checking before inserting means x + x = target only matches when x really appears twice.
3. Sort plus two pointers: sort, then move lo and hi inward based on the sum. After a match, skip runs of equal values on both sides. This takes O(n log n) time and O(1) extra space beyond the sort, and it returns pairs in order.
4. Mention the brute-force nested loop at O(n^2) only to rule it out. Test with negative numbers, all-equal arrays, no valid pair, and an empty or single-element array.

Follow-up

• How would you count pairs by index, including duplicates, instead of unique value pairs?
• How does this extend to three numbers that sum to the target, and what is the complexity?
• If the array is already sorted and too large for memory, which approach still works?

Demonstrate how to reverse a singly linked list both iteratively and recursively, analyzing space and time com

Medium · Data Structures & Algorithms

Demonstrate how to reverse a singly linked list both iteratively and recursively, analyzing space and time complexity for both approaches.

Approach

1. Iterative: keep prev = null and curr = head. In the loop, save next = curr.next, set curr.next = prev, then advance prev = curr and curr = next. Return prev. This is O(n) time and O(1) space.
2. Recursive: if head is null or head.next is null, return head. Otherwise newHead = reverse(head.next), then head.next.next = head and head.next = null, and return newHead. This is O(n) time but O(n) call-stack space.
3. Explain why the stack depth matters. A long list can overflow the stack: CPython's default recursion limit is about 1000 frames, and Java throws StackOverflowError. So the iterative version is the one to ship.
4. Trace the empty list, a single node and two nodes out loud. A recursive version that forgets head.next = null leaves a cycle between the last two nodes.

Follow-up

• How would you reverse only the nodes between positions m and n?
• How would you reverse the list in groups of k nodes?
• How would you use reversal to check whether a linked list is a palindrome in O(1) extra space?

Solve a dynamic programming challenge involving array manipulation and maximum subarray optimization.

Medium · Data Structures & Algorithms

Approach

1. Frame it as DP: best[i] is the maximum sum of a subarray that ends at index i, so best[i] = max(a[i], best[i-1] + a[i]). The answer is the maximum over all i.
2. Only the previous value is needed, which gives Kadane's algorithm: cur = max(x, cur + x) and best = max(best, cur). This is O(n) time and O(1) space.
3. Initialise cur and best to the first element, not to 0. Otherwise an all-negative array wrongly returns 0 instead of its largest element.
4. To return the subarray itself, record a candidate start whenever cur restarts at x, and save start and end whenever best improves. Mention the O(n log n) divide-and-conquer version as the alternative you rejected.

Follow-up

• How do you handle a circular array? (The answer is max(Kadane, total minus minimum subarray), with care when every value is negative.)
• How does the recurrence change for maximum product subarray, where a negative can flip the minimum into the maximum?
• How would you find the maximum-sum submatrix of a 2D grid?

Write a program to traverse a binary tree level by level and discuss edge cases for deeply nested or unbalance

Medium · Data Structures & Algorithms

Write a program to traverse a binary tree level by level and discuss edge cases for deeply nested or unbalanced trees.

Approach

1. Use BFS with a queue. Push the root, and on each iteration record size = len(queue). Pop exactly that many nodes into one level list and enqueue their non-null children. The result is a list of levels.
2. In Python use collections.deque and popleft(), which is O(1). list.pop(0) is O(n) and turns the traversal quadratic. In Java use ArrayDeque.
3. Complexity is O(n) time and O(w) space, where w is the widest level. That is up to about n/2 for the last level of a complete tree.
4. Unbalanced or deep trees: BFS is iterative, so depth never threatens the stack. A recursive DFS that passes a depth index uses O(h) stack, and a skewed tree has h = n. Return an empty list for a null root.

Follow-up

• How would you return the levels in zigzag order?
• How would you return only the rightmost node of each level?
• Can you produce the same grouping with DFS, and what does that cost on a skewed tree?

Explain thread execution in backend applications, detailing when to use multi-threading and how synchronizatio

Medium · Backend Systems & Microservices Architec

Explain thread execution in backend applications, detailing when to use multi-threading and how synchronization works to avoid deadlocks.

Approach

1. Separate I/O-bound work (waiting on databases and HTTP calls), where extra threads overlap the waiting, from CPU-bound work, where more threads than cores only adds context switches. In CPython the GIL stops threads running Python bytecode in parallel, so CPU-bound work goes to processes.
2. Use a bounded thread pool (Java ExecutorService with a bounded queue and a rejection policy) rather than a thread per request, so a traffic spike cannot exhaust memory. A common sizing rule is threads ≈ cores × (1 + wait time / compute time).
3. Synchronization covers both mutual exclusion and visibility: synchronized blocks or ReentrantLock for compound actions, volatile or atomics (AtomicInteger) for single variables, and the happens-before rule for why an unsynchronized write may never be seen.
4. Deadlock needs all four conditions: mutual exclusion, hold-and-wait, no preemption and circular wait. Break circular wait with a global lock order, or use tryLock with a timeout. Keep critical sections short and never call unknown code while holding a lock.
5. Diagnose with a thread dump (jstack, or kill -3). The JVM reports Java-level deadlocks and shows which thread holds which monitor.

Follow-up

• Two threads increment a shared counter and the total comes out low: why, and what are the fixes?
• What is the difference between deadlock, livelock and starvation?
• How would you size the pool for a service that mostly waits on a remote API?

Explain database transaction isolation levels and how connection pooling optimizes performance in high-concurr

Medium · Backend Systems & Microservices Architec

Explain database transaction isolation levels and how connection pooling optimizes performance in high-concurrency environments.

Approach

1. Name the anomalies first, then the levels. Read Uncommitted allows dirty reads. Read Committed blocks dirty reads but allows non-repeatable reads. Repeatable Read blocks those, though the SQL standard still allows phantoms. Serializable behaves as if the transactions ran one at a time.
2. Engine specifics: PostgreSQL defaults to Read Committed, its Repeatable Read is snapshot isolation (no phantoms, but write skew is possible), and its Serializable can abort with a serialization failure that the application must retry. MySQL InnoDB defaults to Repeatable Read.
3. Lost updates under Read Committed: either lock with SELECT ... FOR UPDATE, or use optimistic concurrency with a version column and UPDATE ... WHERE version = ?, retrying when zero rows change.
4. Connection pooling: opening a connection costs a TCP and TLS handshake, authentication and, in PostgreSQL, a new backend process. A pool such as HikariCP keeps warm connections and hands them out per transaction.
5. Size the pool small. HikariCP's starting point is about cores × 2 + spindles. Watch for pool exhaustion caused by leaks or long transactions. With PgBouncer in transaction mode, session-level state (SET, advisory locks, some prepared-statement setups) does not survive between transactions.

Follow-up

• Show a write-skew example that Repeatable Read allows but Serializable prevents.
• Requests start timing out waiting for a connection: what do you check first?
• Why can a larger pool make database throughput worse?

Write a SQL query to retrieve the second highest salary from an employee table without relying on vendor-speci

Medium · Databases & Cloud Infrastructure

Write a SQL query to retrieve the second highest salary from an employee table without relying on vendor-specific pagination extensions.

Approach

1. Portable answer: SELECT MAX(salary) FROM employee WHERE salary < (SELECT MAX(salary) FROM employee). It uses no LIMIT, OFFSET or TOP, and it returns NULL when there is no second distinct salary, which is usually the result asked for.
2. Window function version (standard SQL:2003): apply DENSE_RANK() OVER (ORDER BY salary DESC) over every row in a subquery, then SELECT DISTINCT salary where the rank is 2. Ties are where DENSE_RANK matters: employees sharing the top salary all get rank 1, so the next value is rank 2, whereas RANK would jump to 3 and ROW_NUMBER would return a duplicate of the top salary. If you add DISTINCT inside the subquery instead, ROW_NUMBER gives the same answer, so pick one way of handling ties and say why. This version returns no row, rather than NULL, when no second value exists.
3. Generalize to the Nth highest with a correlated subquery: keep a salary when exactly N-1 distinct salaries are greater than it. It is O(n^2) without an index, so it is only worth showing for completeness.
4. Handle NULL salaries. MAX ignores them, but in PostgreSQL ORDER BY salary DESC puts NULLs first, so add WHERE salary IS NOT NULL to the window version. An index on salary turns each MAX into a quick index lookup.

Follow-up

• How do you return the second-highest salary for each department?
• How would you also return the names of every employee who earns that salary?
• How do the answers differ when the top salary is shared by several employees?

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

1. 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.
2. 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.
3. 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.
4. 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 architecture of a microservice ecosystem, including how service communication, discovery, and fau

Medium · Backend Systems & Microservices Architec

Describe the architecture of a microservice ecosystem, including how service communication, discovery, and fault tolerance are implemented.

Approach

1. Lay out the components: clients reach an API gateway (routing, auth, rate limiting), each service owns its own database, and services talk synchronously over REST or gRPC or asynchronously through a message broker for events.
2. Discovery: client-side means services register in a registry such as Eureka and callers pick an instance. Server-side means callers hit a stable name, such as a Kubernetes Service DNS name or a load balancer, that resolves to healthy instances.
3. Fault tolerance: put a timeout on every remote call. Retry with exponential backoff and jitter, and only for idempotent operations. Add circuit breakers (Resilience4j, for example) so a failing dependency is skipped, and bulkheads so one slow dependency cannot take every thread.
4. Data consistency across services: avoid distributed two-phase commit. Use a saga with compensating actions, and the transactional outbox so a database write and its event cannot diverge.
5. Observability: propagate a correlation or trace ID through every hop (OpenTelemetry) and keep centralized logs. Without these, a request that crosses five services cannot be debugged.

Follow-up

• An order spans payment and inventory services and payment fails after inventory was reserved: how does the system end consistent?
• How can aggressive retries turn a small outage into a large one, and what prevents it?
• How do you change a service's API without breaking the services that call it?

What security mechanisms (such as JWT tokens and OAuth2) do you enforce to secure public-facing REST endpoints

Medium · Backend Systems & Microservices Architec

What security mechanisms (such as JWT tokens and OAuth2) do you enforce to secure public-facing REST endpoints?

Approach

1. Start with the baseline: TLS on every endpoint, input validation, rate limiting per client, and CORS restricted to known origins. Then separate authentication (who the caller is) from authorization (what the caller may do).
2. OAuth2 is the authorization framework. Use authorization code with PKCE for browser and mobile clients, and client credentials for service-to-service calls. The resource server only validates the access token it receives.
3. JWT validation on each request: verify the signature against the issuer's published keys (JWKS), pin the allowed algorithms and reject 'none', and check exp, nbf, iss and aud. A token issued for another audience must fail.
4. Authorization goes beyond scopes or roles on the route. Check object-level ownership (can this user read student 42's record?), because a missing ownership check is the most common API flaw (OWASP's broken object-level authorization).
5. Lifetime trade-off: a stateless JWT cannot be revoked before it expires, so keep access tokens short-lived, use rotating refresh tokens, and keep a denylist only if immediate logout is required.

Follow-up

• How do you log a user out immediately when the access token is a stateless JWT?
• When would you sign with RS256 rather than HS256?
• In a single-page app, where do you store the token, and what do you give up against XSS and CSRF?

Explain the difference between event bubbling and event capturing phases in modern JavaScript with practical e

Medium · Frontend & Web Technologies

Explain the difference between event bubbling and event capturing phases in modern JavaScript with practical examples.

Approach

1. A DOM event travels in three phases: capture (window down to the target's parent), target, then bubble (the target's ancestors back up to window). addEventListener listens in the bubble phase by default. Passing {capture: true} or true as the third argument registers for capture.
2. Show it in code: put capture and bubble listeners on both a div and a nested button. A click on the button logs four lines: div-capture, button-capture, button-bubble, div-bubble. Since Chrome 89, listeners on the target itself also fire capture first.
3. Know the controls: event.stopPropagation() stops the event moving on, stopImmediatePropagation() also skips the remaining listeners on the same element, and preventDefault() cancels the browser's default action without touching propagation.
4. Practical use is event delegation: one listener on a list, using event.target.closest('li') to find the item. It covers rows added later and avoids hundreds of listeners. event.currentTarget is the element the listener is on, and event.target is where the event started.
5. Exceptions: focus and blur do not bubble (use focusin and focusout), and neither do mouseenter and mouseleave.

Follow-up

• Where does React attach its event listeners, and how do you listen in the capture phase in React?
• A modal closes on an outside click but also closes when you click inside it: how do you fix that?
• When is a capture-phase listener the right choice?

In LWC (Lightning Web Components) or modern frontend frameworks, what is the key functional difference between

Medium · Frontend & Web Technologies

In LWC (Lightning Web Components) or modern frontend frameworks, what is the key functional difference between a standard forEach loop and an iterator?

Approach

1. In an LWC template, for:each={list} with for:item and for:index renders each element. The iterator:it={list} directive also exposes it.value and it.index, plus it.first and it.last, so you can render a header or footer or style the edges without extra logic.
2. Both directives need a unique key attribute on the first element inside the loop, so the engine can match DOM nodes to items when the list changes. Use a record Id, never the index.
3. In plain JavaScript, Array.prototype.forEach runs a callback for each element. It cannot break or continue, it ignores return values, and it does not wait for async callbacks.
4. for...of uses the iterator protocol (Symbol.iterator, next() returning {value, done}). It supports break and continue, works on any iterable (Map, Set, strings, generators), and runs await inside the loop sequentially. It also visits holes in sparse arrays as undefined, which forEach skips.

Follow-up

• Why does LWC require a key in loops, and what goes wrong if you use the index?
• You need to call an API for each item: when do you use for...of with await, and when Promise.all?
• How would you make a custom object iterable with for...of?

What is Lightning Data Service (LDS), and how does it optimize data caching and network requests on client dev

Medium · Frontend & Web Technologies

What is Lightning Data Service (LDS), and how does it optimize data caching and network requests on client devices?

Approach

1. Lightning Data Service is Salesforce's client-side data layer for LWC and Aura, built on the User Interface API. It keeps one shared cache of records, so components on a page that ask for the same record share a single request and a single copy.
2. When one component updates a record through LDS (updateRecord, or lightning-record-edit-form), every component wired to that record receives the new value without reloading.
3. Access it with the base components lightning-record-form, lightning-record-view-form and lightning-record-edit-form, or with the wire adapters and functions in lightning/uiRecordApi (getRecord, getFieldValue, createRecord, updateRecord, deleteRecord). Using a reactive '$recordId' makes the wire re-fetch when the Id changes.
4. LDS enforces field-level security and sharing for the running user, which is a reason to prefer it over custom Apex for simple single-record reads and writes.
5. Know its limits. For complex queries, aggregates or bulk work, use Apex with @AuraEnabled(cacheable=true), whose results are cached separately. After Apex changes data, call refreshApex and tell LDS with notifyRecordUpdateAvailable (the replacement for getRecordNotifyChange).

Follow-up

• When would you choose an Apex method over LDS?
• An Apex call updates a record but a getRecord-wired component still shows the old value: how do you fix that?
• How does a wire adapter with a reactive parameter decide when to fetch again?

How do you implement real-time bidirectional communication in web applications using protocols like Socket.io?

Medium · Frontend & Web Technologies

Approach

1. WebSocket starts as an HTTP request with Upgrade headers, the server answers 101 Switching Protocols, and the connection then carries full-duplex frames. Socket.IO is a library on top: by default it connects with HTTP long-polling and upgrades to WebSocket. A plain WebSocket client cannot talk to a Socket.IO server.
2. Socket.IO adds automatic reconnection, heartbeats, namespaces, rooms (for example one room per class or document), broadcasts, and acknowledgements, which are callbacks that confirm the other side received a message.
3. Authenticate during the handshake: send a token in the auth payload, verify it in io.use() middleware, and re-check authorization when a socket joins a room.
4. To scale beyond one node, the long-polling transport needs sticky sessions at the load balancer, and broadcasts need an adapter (the Redis adapter, for example) so an event emitted on one node reaches sockets connected to other nodes.
5. Delivery is at-most-once by default. If messages must survive disconnects, give them IDs, persist them, and replay from the client's last-seen ID on reconnect. For server-to-client push only, Server-Sent Events can be simpler.

Follow-up

• How do clients catch up on the messages they missed while disconnected?
• How would you deliver a message to users connected to different server instances?
• When would you pick Server-Sent Events or polling over WebSockets?

Explain how state management and client-side component re-rendering operate in ReactJS.

Medium · Frontend & Web Technologies

Approach

1. State lives in components through useState or useReducer. Calling a setter does not change the value in the current render; it schedules a re-render, and each render sees a snapshot. Use the functional form setCount(c => c + 1) when the new value depends on the old one.
2. A component re-renders when its own state changes, when its parent re-renders (children re-render by default even if their props did not change), or when a context it consumes changes value. React 18 batches multiple updates into one render, including updates inside promises and timeouts.
3. Rendering is split into a render phase and a commit phase. The render phase calls components to build a new element tree and diffs it against the previous tree by element type and key. The commit phase applies only the DOM changes, then effects run.
4. Updates are detected by Object.is comparison. Mutating an array and setting the same reference skips the update, so create new objects. Use stable keys, not array indexes, for lists that reorder.
5. Cut wasted renders with React.memo plus useCallback and useMemo for stable props. Keep state close to where it is used, and split contexts or use a store with selectors (Redux, Zustand), since every consumer re-renders when a context value changes.

Follow-up

• Why can a list keyed by index show the wrong input value after an item is deleted?
• A useEffect keeps reading an old value of state: what is happening, and how do you fix it?
• Why does a component render twice in development under StrictMode?

Describe the core master-worker architecture of Kubernetes, including the responsibilities of the API server,

Medium · Databases & Cloud Infrastructure

Describe the core master-worker architecture of Kubernetes, including the responsibilities of the API server, etcd, scheduler, and kubelet.

Approach

1. Control plane: kube-apiserver is the only entry point. It authenticates, authorizes and runs admission checks on every request, and it is the only component that reads and writes etcd. etcd is a Raft-based key-value store holding all cluster state; run an odd number of members for quorum and back it up.
2. kube-scheduler watches for pods with no node assigned, filters out nodes that cannot fit them (resources, taints, affinity), scores the rest, and binds the pod to the best node. kube-controller-manager runs the reconcile loops: Deployment to ReplicaSet to pods, the node controller, endpoints and so on.
3. Worker nodes: the kubelet watches for pods bound to its node, starts containers through the container runtime (containerd) over CRI, runs liveness and readiness probes, and reports status. kube-proxy programs iptables or IPVS rules so a Service's virtual IP reaches healthy pods.
4. Walk through kubectl apply of a Deployment end to end: API server persists it, controllers create a ReplicaSet and pods, the scheduler binds them, the kubelet runs them. This shows the model: desired state is stored, and components watch it and reconcile.
5. Failure modes: if the API server is down, running pods keep running but nothing can change. If etcd loses quorum, writes stop. If a node dies, its pods are evicted after a timeout and recreated elsewhere by their controllers.

Follow-up

• What happens, step by step, when a worker node loses power?
• What is the difference between a liveness probe and a readiness probe, and what goes wrong if you confuse them?
• How does a request to a Service's ClusterIP reach a specific pod?

Write a sample Dockerfile from scratch, detailing the purpose of base images, multi-stage builds, COPY, and

Medium · Databases & Cloud Infrastructure

Write a sample Dockerfile from scratch, detailing the purpose of base images, multi-stage builds, COPY, and CMD instructions.

Approach

1. Write it in two stages. The build stage starts FROM a full SDK image (for example maven:3.9-eclipse-temurin-21 AS build), copies the dependency manifest, resolves dependencies, then copies the source and builds. The runtime stage starts FROM a slim JRE or distroless image and uses COPY --from=build to take only the artifact.
2. Base images: pin a specific tag, or a digest for reproducibility. Smaller bases (slim, distroless, alpine) cut size and attack surface, though alpine's musl libc can break some native dependencies.
3. Layer caching: COPY pom.xml or package.json and install dependencies before COPY of the source, so a code change does not re-download every dependency. Add a .dockerignore so .git, node_modules and secrets stay out of the build context. Prefer COPY to ADD, which also fetches URLs and unpacks tar files.
4. CMD sets the default command, and arguments to docker run replace it. ENTRYPOINT sets the fixed executable. Use the exec form, CMD ["java", "-jar", "/app/app.jar"], so the app runs as PID 1 and receives SIGTERM. The shell form wraps it in /bin/sh -c, which does not forward signals. Only the last CMD in a file applies.
5. Production details: add a USER instruction so the app does not run as root, EXPOSE the port as documentation, and add a HEALTHCHECK where the orchestrator does not supply one.

Follow-up

• How would you pass a secret to the build without leaving it in an image layer?
• The container takes ten seconds to stop on every deploy: why, and how do you fix it?
• The image is 1.2 GB: what do you change first to shrink it?

Outline the steps to write a Terraform script that provisions scalable cloud infrastructure using providers, v

Medium · Databases & Cloud Infrastructure

Outline the steps to write a Terraform script that provisions scalable cloud infrastructure using providers, variables, and state files.

Approach

1. Structure: a terraform block with required_providers and version constraints, a provider block (region and credentials taken from the environment, never hard-coded), then variables.tf, main.tf and outputs.tf. Repeated pieces such as a network or a service go into modules.
2. Variables: declare a type, an optional default and validation blocks, mark secrets sensitive = true, and supply per-environment values through .tfvars files. Use for_each or count to create repeated resources such as subnets across availability zones.
3. For scalable compute: a launch template plus an autoscaling group with min, max and desired capacity across subnets in several zones, behind a load balancer with health checks. Expose the load balancer DNS name as an output.
4. Workflow: terraform init (downloads providers, configures the backend), fmt and validate, then plan, which compares configuration with state and real resources, and apply only after reading the plan. Run plan in CI on every change.
5. State maps each resource to its real cloud ID. Keep it in a remote backend with locking (S3 with locking, or Terraform Cloud), encrypt it and restrict access because it can hold secrets in plain text, use separate state per environment, and use moved blocks or terraform state mv rather than editing state by hand.

Follow-up

• Two engineers run apply at the same time: what protects the state?
• How do you rename a resource in code without Terraform destroying and recreating it?
• Someone changed a resource by hand in the console: how do you detect and resolve the drift?

How do you structure automated CI/CD pipelines for automated unit testing, containerization, and blue-green de

Medium · Databases & Cloud Infrastructure

How do you structure automated CI/CD pipelines for automated unit testing, containerization, and blue-green deployments?

Approach

1. Pull request stage: lint, unit tests, a build, and dependency and static security scans, all required checks before merge. Keep it fast so it runs on every push.
2. Main-branch stage: build the container image once, tag it with the commit SHA, scan it, and push it to a registry. Every later environment deploys that same image, so what was tested is what ships.
3. Deploy to staging and run integration and end-to-end tests there. Then promote to production behind an approval gate if required, with secrets read from a secret manager rather than stored in the pipeline.
4. Blue-green: run the new version (green) next to the live one (blue), smoke test green, then switch the load balancer or Kubernetes Service selector to it. Rolling back is switching back. The cost is double capacity during the cutover, plus draining long-lived connections.
5. Database migrations must work with both versions, because blue and green share the database. Use expand-and-contract: add columns first, deploy the code, remove old columns in a later release. Compare blue-green with canary, which shifts a small share of traffic and watches error metrics before going further.

Follow-up

• A release needs a column renamed: how do you ship it with blue-green and no downtime?
• Error rates rise ten minutes after the switch: what triggers the rollback, and what state needs cleaning up?
• When would you pick a canary rollout over blue-green?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

1. Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
2. Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
3. Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
4. Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

• The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
• You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

The plan starts with the coding problems every round can reach, then moves through databases, backend and security, microservices and infrastructure, and ends on frontend and behavioral stories. Each day produces something you can check: code, a table, a diagram or a written story.

Day 1 — Map your stack and script the recruiter call

• Write a short spoken version of your resume ordered by the role's stack, and name the language you will code in.
• Build a table of the listed skills (Java, Python, JavaScript, TypeScript, C++; Spring Boot, Node.js, ReactJS, LWC; SQL and NoSQL; Docker, Kubernetes, Terraform, CI/CD; Git) and mark each strong, usable or a gap.
• Write three questions for the recruiter, including what format the Technical Screen takes.

Deliverable: A resume script, a skills table with gaps marked, and a list of three recruiter questions.

Day 2 — Strings, arrays and maximum subarray

• Implement the string-to-integer conversion with whitespace, sign, invalid character and overflow handling, and write at least six test inputs.
• Solve unique pairs to a target twice: with a hash set and with sort plus two pointers. Make both skip duplicates and state the complexity of each.
• Solve maximum subarray with Kadane's scan, then extend it to return the start and end indices.

Deliverable: Three working solutions, each with a test list and a stated time and space complexity.

Day 3 — Linked lists and trees

• Reverse a singly linked list iteratively and recursively, and explain the recursion stack cost of the second version.
• Write level-order traversal with a queue that snapshots the level size, returning values grouped by depth.
• Test the traversal on an empty tree, a single node and a long skewed tree, and note how queue width and recursion depth differ for balanced and skewed shapes.

Deliverable: Two list-reversal implementations and one level-order traversal, with a written note on empty, skewed and wide-tree behaviour.

Day 4 — SQL, isolation levels and connection pooling

• Write the second-highest-salary query three ways (subquery on MAX, distinct-count form, DENSE_RANK) and note how each handles ties and a table with fewer than two distinct salaries.
• Build a table of the four isolation levels against dirty read, non-repeatable read and phantom read.
• Write a short explanation of why a connection pool helps under high concurrency and what goes wrong when it is too small or too large.

Deliverable: Three working queries, an isolation-level anomaly table, a pooling explanation and the completed practice question.

Day 5 — Threads, REST controllers, security and a pressured diagnosis

• Write a two-thread deadlock in your language, then fix it with a fixed lock order, and explain when a thread pool beats a thread per request.
• Write a REST controller with validation plus a global exception handler returning one error shape for 400, 404 and 500.
• Write a checklist for securing a public endpoint with JWT and OAuth2: signature and expiry checks, scopes, token storage, refresh and revocation.

Deliverable: A deadlock example with its fix, a controller with an exception handler, a security checklist, a spoken debugging walk-through and one written diagnosis story.

Day 6 — Microservices and infrastructure

• Sketch a microservice ecosystem on one page: gateway, service-to-service calls, discovery, timeouts, retries, circuit breaker, and how a cross-service transaction is handled without tight coupling.
• Draw the Kubernetes control plane and a worker node, and say what the API server, etcd, scheduler and kubelet each do when a deployment is created.
• Write a multi-stage Dockerfile from memory, then outline a Terraform layout with a provider, variables, a remote state backend and a module.
• Outline a CI/CD pipeline with unit tests, an image build and a blue-green deployment with a rollback step.

Deliverable: An architecture diagram, a control-plane diagram, a Dockerfile, a Terraform file outline and a pipeline outline.

Day 7 — Frontend fundamentals and the behavioral stories

• Explain aloud and with a short code snippet: event bubbling versus capturing, how React state updates trigger re-rendering, and how Socket.io keeps a bidirectional connection open.
• Write one paragraph each on LWC iteration versus forEach and on what Lightning Data Service caches, or state which framework you will answer from instead.
• Write the disagreement, competing-priorities and stakeholder stories in STAR form, each naming your own decision and a measured result.
• Run all stories aloud once, then run a full mixed round of two coding questions, one design question and one story.

Deliverable: A frontend cheat sheet, three written STAR stories and a recorded or timed mixed mock round with notes on what to fix.

Stories to rehearse for the ABC Education loop

Candidates report behavioral questions inside the onsite rounds and a managerial and HR conversation about project accomplishments and team collaboration. The role description lists product managers, UI/UX designers, QA engineers and DevOps specialists as collaborators, so prepare stories that show your own decision, the evidence behind it and the result, using STAR. The first four prompts are reported; the last two are extra prompts to rehearse because candidates report project walk-throughs.

1. Walk me through one project on your resume line by line: the architecture, the choices you made and the hardest problem you solved.
2. Tell me about a code review that changed how you approached a piece of work.

What annotations are required to build a REST controller in your framework of choice, and how do you handle ex

Medium · Backend Systems & Microservices Architec

What annotations are required to build a REST controller in your framework of choice, and how do you handle exception management globally?

Approach

1. Name your framework first. In Spring Boot, @RestController marks the class (it combines @Controller and @ResponseBody), @RequestMapping on the class sets the base path, and @GetMapping, @PostMapping, @PutMapping and @DeleteMapping bind methods to HTTP verbs.
2. Cover the parameter annotations: @PathVariable for the id in the URL, @RequestParam for query values, @RequestBody to deserialize JSON, and @Valid on the body so constraints such as @NotBlank and @Size run before your method does. Return ResponseEntity when you control the status, for example 201 with a Location header on create.
3. For global exception handling, write one class annotated @RestControllerAdvice with an @ExceptionHandler method per exception type: MethodArgumentNotValidException maps to 400 with field-level messages, a domain NotFoundException maps to 404, and a catch-all maps to 500 with a generic message and no stack trace.
4. Keep the layers honest: the service throws domain exceptions, the controller stays thin, and the advice is the only place that turns exceptions into HTTP. Use one error body shape (code, message, details, correlation id), or Spring 6's ProblemDetail, so clients can branch on a stable contract.
5. If your framework is Express, say so: an error-handling middleware with four parameters, registered after the routes, plays the advice role, and async handlers must forward rejections to next (Express 5 does this for returned promises). In Spring the handler for the closest exception type wins; in Express, registration order decides.

Follow-up

• How would you return field-level validation errors so a React client can show them next to the right inputs?
• How do you keep error responses consistent across several microservices without copying the advice class into each one?
• What do you log when you return a 500, and what must never reach the response body?

Tell me about a time you handled a critical technical disagreement or conflict within your engineering team.

Medium · Behavioral & Leadership Scenarios

Approach

1. Choose a disagreement about a technical decision you had a stake in, such as two designs for a service boundary, a framework choice or a schema, rather than a personality clash. Open with two sentences on what was being decided and why both positions could not be adopted.
2. State the other person's position in terms they would call fair. Then show how you moved from opinion to evidence: a small prototype, a benchmark, a failure-mode comparison, or a review of how each option would be operated and rolled back.
3. Say how the decision was made (agreement from the evidence, a tie broken by the tech lead, a time-boxed trial) and what you did when it went against you. Close with the result: what shipped, what you measured, and what the working relationship looked like afterwards.
4. Avoid the two stories that sink this answer: one where you were right and the colleague was careless, and one where you let the conflict sit until someone else settled it. If you turned out to be wrong, say so plainly and say what changed in how you decide.

Follow-up

• What would you have done if the decision had gone the other way?
• How did you make sure the disagreement did not linger after the decision?
• Was there a point where you changed your own mind, and what caused it?

Describe a situation where you had to prioritize competing technical tasks under tight deadlines and changing

Medium · Behavioral & Leadership Scenarios

Describe a situation where you had to prioritize competing technical tasks under tight deadlines and changing product requirements.

Approach

1. Pick a case with real competing demands and a moving requirement, and name the tasks concretely: for example a production bug fix, a feature with a release date and a dependency upgrade. Say who was asking for each and what each cost if it slipped.
2. Show your ordering rule: cost of delay, who is blocked, whether the work is reversible, and effort. Say what you did first and what you deliberately deferred or cut, and that you told the people affected instead of letting items slide quietly.
3. Handle the changing requirement explicitly. You re-checked the order when the requirement moved, split the work into a shippable core and extras, and agreed the cut with the product owner in a ticket or short written message.
4. Finish with the result (what shipped, what slipped, what broke or did not) and one change you made afterwards, such as smaller scope in estimates or a standing priority review. Avoid making 'I worked longer hours' the main action: it shows effort but no prioritisation.

Follow-up

• What did you drop, and how did the person who wanted it respond?
• How did you decide the bug fix outranked the feature?
• What would you do if two senior people each insisted their item came first?

Share an example of a complex technical problem you solved under intense pressure, detailing your diagnostic a

Medium · Behavioral & Leadership Scenarios

Share an example of a complex technical problem you solved under intense pressure, detailing your diagnostic approach.

Approach

1. Pick an incident or bug where you led the diagnosis and the symptom was clear: an error rate, latency, a failing deploy or a data mismatch. Give the stakes and what was already known in a few plain sentences.
2. Walk the diagnostic sequence in order: limit the damage first (roll back, switch off a feature flag, add capacity), then gather signals (logs, metrics, traces, the diff of the last release), then form two or three hypotheses and test the cheapest first, narrowing by bisection or by reproducing the fault in isolation.
3. State how you confirmed the root cause instead of the first plausible one: you reproduced it, or the fix moved the metric you started from. Name the fix, the test that now guards against it, and the follow-up such as an alert or a short written review.
4. If your story touches this loop's topics, make the mechanism concrete: an exhausted connection pool, a deadlock between threads, a slow query missing an index, or a container restart loop. Avoid a story that is only long hours or a lucky last-minute guess.

Follow-up

• How did you decide to roll back instead of fixing forward?
• What did you check first, and what would have made you change that order?
• What did you change afterwards so the same fault is caught earlier?

How do you collaborate with non-technical stakeholders to gather specifications and deliver project deliverabl

Medium · Behavioral & Leadership Scenarios

How do you collaborate with non-technical stakeholders to gather specifications and deliver project deliverables on time?

Approach

1. Describe one project with a non-technical counterpart, such as a product manager, an operations or support lead, or someone speaking for teachers or administrators. Start with how you found out what they needed: you asked what outcome they were after and what they do today, not which feature they wanted.
2. Show how you made the requirement checkable: acceptance criteria in plain language, a short list of what was in and out of scope, and examples or mock-ups. Confirm in writing, so a later disagreement points to a shared record.
3. Show the delivery loop: an early thin slice or demo to catch misunderstandings, regular status stated as user impact and dates, and risks raised early with options and costs rather than a technical explanation.
4. Include a moment of friction, such as a late change or an infeasible request, and how you turned the constraint into a choice they could make (A by the date, or B later). Avoid answers that are only about being agreeable or only about shipping what you were told.

Follow-up

• A stakeholder asks for a change late in the cycle. What do you tell them, and how?
• How do you explain a technical limitation without jargon?
• How did you know the delivered feature matched what they needed?