ABC Family Software Engineer Interview Guide

The 60-second brief

Candidate reports describe ABC Family as a media business, and the role description they see frames the engineer's work around content delivery. Its examples are streaming media, personalized recommendations, optimizing backend services, secure transactional pathways and user-facing features. The reports name no specific product, team or internal system, so treat any stack detail beyond the listed requirements as something to ask the recruiter. Those requirements mention one major language (Java, Python or JavaScript), SQL, data structures and algorithms, and, as extras, AWS or Azure, microservices, CI/CD tooling and Docker or Kubernetes.

This guide is for candidates interviewing for a Software Engineer position at ABC Family. It covers the four reported rounds, all twenty reported questions (computer science fundamentals, coding, system design and infrastructure, and behavioral) and a seven-day plan. It is a preparation resource built from candidate reports, not a published process, and your own loop may differ by team and seniority.

Candidates report four rounds over roughly 3-5 weeks: a Screening Call, Technical Assessments, a Managerial Interview and Behavioral Interviews. The exact round count is said to vary with team and seniority.

Focus areas

• Kubernetes
• Transaction Security / Secure Transactions
• Infrastructure as Code (Terraform)

Overview

The reported questions are mostly broad and conceptual. Two are concrete coding tasks, finding the second-highest salary in a database table and finding a target sum in an array of integers. The rest ask you to explain or justify: synchronization in a multi-threaded program, transaction integrity across microservices, the components of Kubernetes, REST controller security, CI/CD deployment, when one database schema beats another. The set also includes two front-end items, the difference between for-each loops and iterators in LWC and the bubble and capture phases in JavaScript. Preparing for this loop means being able to give a structured two-minute answer on each of many topics, not grinding one problem type.

Reported topic tags lean toward infrastructure and security: Kubernetes, secure transactions, Infrastructure as Code with Terraform, Docker and data structures. Candidates also describe deep dives into their own projects: why you picked a framework or database, how you broke a complex requirement into tasks, and what you did to improve performance. Because of that, your resume projects are part of the syllabus. For every project you list, be ready to name the stack, the hardest technical hurdle, the alternative you rejected and a result you can measure.

Two of the four rounds are about people and past work: a Managerial Interview and Behavioral Interviews. Reports list prompts about team conflict, competing deadlines, working under pressure, a challenging project, mentoring a junior colleague and disagreeing with a technical decision. Candidates also mention explaining complex technical ideas to non-technical colleagues. Build a small set of stories that each carry a decision, a trade-off and an outcome, then reuse them across prompts.

Use the plan on this page to cover each reported area once, then repeat the weak ones. The stack candidates cite (Java, Python or JavaScript, SQL, Spring Boot, React or Node.js, Docker, Kubernetes, CI/CD) is broad, so pick the language you will code in during the technical rounds and stay with it, and be candid about the tools you have only read about.

The ABC Family interview process

The four rounds below are what candidates describe, in the order they report them. The reports add that the number of rounds can change with the team and the seniority of the role.

Screening Call

Candidates describe a first call about your background and fit for the role. Nothing more is reported about its format, so treat it as the place where your resume gets summarised out loud, and expect follow-up on anything you list. Arrive with a short, specific account of what you have built, the languages and tools you used, and why this media-focused role interests you.

What to demonstrate

• How clearly you summarise your own background and projects
• Fit between your experience and the role's listed skills (a major language, SQL, data structures and algorithms)

How to prepare

• Write a two-minute walkthrough of your resume that names, for each project, the language, the database and the one hard problem you solved.
• List which of Java, Python, JavaScript, SQL, Docker, Kubernetes, CI/CD and AWS or Azure you have used in production, in a side project or only read about, and answer honestly at that level.
• Write a one-sentence reason for wanting this role that points to something in the role description, such as content delivery or secure transactions, rather than generic enthusiasm.
• Prepare two questions about the team's current technical challenges and how the later rounds are organised.

Technical Assessments

Candidates report "various technical evaluations" without naming a format. The reported question types are computer science fundamentals (concurrency, JavaScript and LWC behaviour, microservice transactions, Kubernetes), coding (the second-highest salary and target-sum tasks) and system design and infrastructure (CI/CD, REST security, containers, schema choice). Candidates also say the pace can be quick once the screening is passed. Prepare by saying each answer aloud in a fixed structure, and by writing code in a plain editor with no autocomplete.

What to demonstrate

• Command of core computer science, data structures and database fundamentals
• Ability to turn a problem into working, readable code, moving from a brute-force version to a better one
• Understanding of how services, APIs, deployment and security fit together

How to prepare

• Write the second-highest salary query three ways (subquery with MAX, DENSE_RANK, LIMIT with OFFSET and DISTINCT) and the target-sum solution in your chosen language, then state the complexity of each.
• Explain aloud, without notes, how Kubernetes schedules a pod, how a saga replaces a distributed transaction, and how event capture and bubbling order handlers in the DOM.
• Draw a deployment pipeline from commit to production for a containerised service, naming where tests, image builds, security checks and rollback sit.
• Practise typing and running code in a bare editor, since candidates are told to rehearse that way.

Managerial Interview

Candidates describe an interview with a manager about alignment with team goals and culture. The reports give no technical format for it, so prepare for a conversation about how you work: what you own, how you prioritise, how you communicate and what you would want from the team. Your project stories carry most of the weight here.

What to demonstrate

• Alignment between how you work and the team's goals, as candidates describe the round
• How you describe your ownership of past work and your working relationships

How to prepare

• Choose one project where you owned the feature through requirements, code, testing and deployment, and outline it in five sentences with the outcome.
• Rehearse a prioritisation story with a real list of competing tasks, what you dropped and who you told.
• Prepare to explain a technical choice to a non-technical colleague, using one analogy and one number.
• Write three questions for the manager about team dynamics, current technical challenges and growth opportunities.

Behavioral Interviews

Candidates report discussions about past experiences and behavioral fit, plural, so expect more than one conversation. Reported prompts include team conflict, working under pressure, a challenging project, mentoring a junior colleague and disagreeing with a technical decision. Prepare stories in which you made the decision and can show what changed afterwards.

What to demonstrate

• How you describe handling conflict, ambiguity and changing requirements
• Your role in team and cross-functional work, as reported for the round
• The decisions and outcomes you can recall from past projects

How to prepare

• Write four stories in situation, task, action and result form: a team conflict, a pressure incident, a challenging project and a time you mentored someone.
• Prepare an answer to disagreeing with a technical decision that includes the evidence you brought, the outcome and what you did if you lost the argument.
• Attach one number to each story, such as latency, error rate, build time or deadline slip, and be able to say how you measured it.
• Practise telling each story in about two minutes aloud, cutting the setup so the decision and result take most of the time.

Where candidates lose points

Naming Kubernetes components from memory without being able to trace what happens when you apply a Deployment

Practise the path: the request reaches the API server, state is stored in etcd, the scheduler picks a node, the kubelet starts containers through the runtime, and kube-proxy and Services route traffic. Be able to say which pieces are control plane and which run on every node.

Answering the second-highest salary task with LIMIT 1 OFFSET 1 and stopping

State the edge cases first: duplicate top salaries, a table with fewer than two distinct values, and NULLs. Show a DISTINCT or DENSE_RANK version or a MAX over salaries below the maximum, and say what it returns when no second value exists.

Treating microservice transaction integrity as a plain database transaction, or as two-phase commit only

Explain that each service owns its data, so cross-service consistency uses a saga with compensating actions, an outbox so events are published reliably, and idempotency keys so retries cannot double-apply. Pair this with transport security, authentication and authorisation for the secure-transaction questions.

Listing resume projects you cannot defend, when reports describe deep dives into architecture and technical hurdles

For each project write the stack, why you picked the database and framework, the hardest bug or performance problem and the result. Delete or rehearse anything you cannot discuss for several minutes.

Giving behavioral answers in "we" language, with no decision of yours and no outcome

Open each story with your specific decision, include the alternative you rejected and close with a measured result and one lesson. Rehearse conflict, pressure, prioritisation and a challenging project in this shape.

Questions & practice

Write a function to find the second-highest salary from a database table.

Medium · Coding and Problem Solving

Approach

1. First pin down what second-highest means and what to return when there is none. It is normally the second distinct value (salaries 100, 100, 90 give 90), and the empty case usually returns NULL. ROW_NUMBER is wrong here because it returns 100 again on a tie.
2. The simplest portable query is SELECT MAX(salary) FROM employee WHERE salary < (SELECT MAX(salary) FROM employee). It returns NULL when there are fewer than two distinct values. With an index on salary, each MAX is read from the end of the index instead of scanning the table.
3. For a general Nth version, use DENSE_RANK() OVER (ORDER BY salary DESC) in a subquery and filter to rank N, or SELECT DISTINCT salary ORDER BY salary DESC with LIMIT 1 OFFSET N-1. Both return an empty set rather than NULL, so wrap them in a scalar subquery if the caller expects exactly one row.
4. Handle NULL salaries explicitly. MAX ignores them, but PostgreSQL sorts NULLs first under ORDER BY ... DESC (MySQL sorts them last). The LIMIT/OFFSET and DENSE_RANK versions therefore need WHERE salary IS NOT NULL or NULLS LAST.
5. If the function works on an in-memory list instead, one pass that tracks the largest and second-largest distinct values runs in O(n) time and O(1) space. Skip values equal to the current maximum so duplicates cannot fill both slots.

Follow-up

• How would you return the second-highest salary for every department?
• Wrap this in a function that returns the Nth highest salary. What does it return when N exceeds the number of distinct salaries?
• Which index would you add, and how does the query plan change on a very large table?

Given an array of integers, how would you find the target sum?

Medium · Coding and Problem Solving

Approach

1. First pin down which problem this is: one pair that sums to the target (returning indices or values), every such pair, a contiguous subarray that sums to the target, or any subset. Each has a different best algorithm.
2. Pair version: brute force checks every pair in O(n^2). One pass with a hash map from value to index runs in O(n) time and O(n) space. Look up target - x before inserting x, so an element is never paired with itself and [3, 3] with target 6 still works.
3. If the array is sorted, or may be sorted, move two pointers inward from both ends. That costs O(n log n) for the sort plus O(n) for the scan, with O(1) extra space. Sorting loses the original indices unless you sort (value, index) pairs. Skipping equal neighbours yields only unique pairs.
4. Subarray version: running prefix sums, with a hash map counting earlier prefix values, find target-sum subarrays in O(n) even with negative numbers. A sliding window only works when no value is negative. Subset version: this is subset-sum. A DP over achievable sums takes O(n * target) time, which is pseudo-polynomial, and the general problem is NP-complete.
5. Edge cases to state aloud: empty or one-element input; no solution (agree on an empty result or -1 rather than an exception); duplicates; negative numbers and a target of 0; and int overflow in Java when computing target - x or x + y near Integer.MAX_VALUE.

Follow-up

• How would you extend this to three numbers that sum to the target, and what is the complexity?
• What changes if the array is too large for memory or arrives as a stream?
• How would you count every subarray whose sum equals the target, rather than find one?

Explain the logic behind your approach to a specific coding challenge.

Medium · Coding and Problem Solving

Approach

1. Restate the problem with a small concrete example and the constraints you assumed (input size, value ranges, whether the input is sorted). The constraints are what justify the final complexity.
2. Start from the brute force and its cost. Then name the repeated work it does and the structure that removes it: a hash map for repeated lookups, sorting plus two pointers for pair searches, a heap for repeated min or max, memoisation for overlapping subproblems.
3. State the invariant the solution maintains (for example, the map holds every value seen so far with its index). Use it to argue correctness instead of narrating the code line by line.
4. Dry-run the code on a normal case and on edge cases (empty input, one element, duplicates, negatives, overflow) before calling it done. Then give the final time and space complexity and the trade-off you made, such as extra memory for speed.
5. Close with what you would change under a different constraint: streaming input, data larger than memory, or many repeated queries that justify preprocessing.

Follow-up

• Why is your solution correct for every input, not just the examples you traced?
• Which test cases would you write, and which one is most likely to break the code?
• What would you change if memory, not time, were the binding constraint?

When would you choose a specific database schema over another?

Medium · System Design and Infrastructure

Approach

1. Start from the access patterns rather than the technology: which queries run most, the read-to-write ratio, which data must change together atomically, and how relationships fan out (one-to-many, many-to-many).
2. Use a normalized relational schema (around third normal form) as the default for transactional data with many relationships. Each fact is stored once, so updates cannot leave copies disagreeing, and foreign keys and multi-row transactions protect integrity. The cost is joins on read.
3. Denormalize deliberately when a hot read path is join-heavy and can tolerate duplicated or slightly stale data (a stored count, a materialized view, a copied display name). Say how the duplicate stays in sync.
4. Choose a document store when an aggregate is read and written as a whole and its shape varies. Choose a key-value or wide-column store for very high write volume with keyed lookups. Use a star schema (a fact table plus dimension tables) for analytics, not for OLTP.
5. Name the operational consequences: which indexes follow from the schema, how a migration rolls out without downtime, and, for multi-tenant data, whether to use a tenant_id column, a schema per tenant or a database per tenant.

Follow-up

• When would you store JSON in a relational column instead of adding tables?
• How would you move a large table to a new schema without downtime?
• Your normalized schema makes the main page query join six tables. What do you change first?

Why do you want to join ABC Family, and what value can you bring to our team?

Medium · Behavioral and Cultural Fit

Approach

1. Treat this as a motivation question, not a technical one. Answer in three parts: why this role, what evidence you bring, and what you want to grow into. Keep it short enough to leave room for follow-up questions.
2. Base the why on specifics you can check in the job posting and the screening call, such as the product area and the stack the role lists (Java, Spring Boot, React or Node.js, SQL, microservices, containers). Do not base it on praise of the company.
3. Back the value claim with one project: what you built, a decision you made and a measurable result, tied to a listed requirement. Examples: a service you containerized and deployed through CI/CD, or a slow SQL query you fixed.
4. Avoid the answers that sink it: talking only about what the job gives you, generic lines that would fit any employer, or claims about the company you cannot support. Close by naming what you want to learn in the role.

Follow-up

• What do you know about the team you would join, and where did you learn it?
• Which of your projects is closest to this role's work, and what would you do differently now?
• What would make you leave a role like this?

Can you explain the difference between for-each loops and iterators in LWC?

Medium · Technical Fundamentals and CS Core

Approach

1. Both are LWC template directives for rendering a list. for:each={items} takes for:item and an optional for:index. iterator:it={items} exposes each element as it.value, plus it.index, it.first and it.last.
2. Use iterator when the markup must differ for the first or last row (a divider, a border class, a trailing separator). Templates cannot evaluate expressions like index === 0, so first and last are the built-in way to branch without writing a JavaScript getter.
3. With either directive, the first element inside the loop needs a key attribute set to a stable unique id (item.Id or it.value.Id), not the index. The engine diffs the list by key on re-render, so an index key can reuse the wrong DOM rows after an insert, delete or sort.
4. If each row needs computed values (a formatted date, a selected flag), map the array in a JavaScript getter and iterate the result. The template can only read properties.
5. Contrast both with for...of or Array.prototype.forEach in the component's JavaScript, which run logic but render nothing. The template re-renders when the array field is reassigned. Mutating it in place is only tracked if the field is decorated with @track.

Follow-up

• Why does LWC require a key on iterated elements, and what goes wrong if you use the index?
• How would you render a separator between items but not after the last one?
• How do you make the list re-render when one property of one item in the array changes?

What is the difference between bubble and capture phases in JavaScript?

Medium · Technical Fundamentals and CS Core

Approach

1. A DOM event moves through three phases. In capture it travels from window down through the ancestors to the target's parent. In the target phase it is at the element itself. In bubble it travels from the target back up to window.
2. addEventListener listens in the bubble phase by default. Pass true or { capture: true } as the third argument to listen during capture, so an ancestor handles the event before any descendant handler runs.
3. stopPropagation stops the event reaching further elements in either phase. stopImmediatePropagation also skips the remaining listeners on the current element. preventDefault does something else: it cancels the browser's default action and leaves propagation alone.
4. Bubbling is what makes event delegation work. One listener on a list container handles clicks on rows added later, using event.target.closest(selector) to find the row. event.currentTarget is the element the listener is attached to.
5. Edge cases: focus and blur do not bubble (focusin and focusout do), and neither do mouseenter and mouseleave. In shadow DOM, which LWC uses, events are retargeted at the shadow boundary. A CustomEvent defaults to bubbles: false and composed: false, so it neither bubbles nor leaves the shadow tree unless you set those options.

Follow-up

• How would you build a click-outside-to-close handler, and which phase would you listen in?
• A delegated listener on document never fires for clicks inside one component. What are the likely causes?
• What is the difference between event.target and event.currentTarget during the bubble phase?

How do you manage transaction integrity within a microservices architecture?

Medium · Technical Fundamentals and CS Core

Approach

1. Start from the constraint. With a database per service there is no single ACID transaction, and Spring's @Transactional without a JTA manager only covers the local database. Integrity across services has to be designed explicitly.
2. Explain why two-phase commit is usually avoided. If the coordinator fails, participants block while holding locks. It ties every service's availability together, and most message brokers and many NoSQL stores cannot join an XA transaction.
3. Use a saga: a sequence of local transactions, each with a compensating action (reserve stock, then charge; on failure, refund and release). Choreography has services react to each other's events. An orchestrator holds the state machine explicitly, which is easier to trace and debug.
4. Avoid the dual-write problem with a transactional outbox. Write the business row and an outbox event in the same local transaction, then publish from the outbox with a poller or change data capture. Delivery is at-least-once, so consumers must be idempotent, for example by deduplicating on event id.
5. Cover the isolation gap. Other requests can see a saga's intermediate state, so model it with explicit states such as PENDING. Put the compensatable steps before the step that cannot be undone, and make every step after it retriable until it succeeds. Reconcile periodically to catch drift.

Follow-up

• What do you do when a compensating action itself fails?
• When would you choose an orchestrator over choreography?
• How does a consumer stay correct if it receives the same event twice, or events out of order?

What are the primary components of a Kubernetes architecture?

Medium · Technical Fundamentals and CS Core

Approach

1. Split the cluster into the control plane and worker nodes. Control plane: kube-apiserver (the REST front door and the only component that talks to etcd), etcd (the consistent key-value store for cluster state, replicated with Raft), kube-scheduler (assigns unscheduled Pods to nodes by filtering, then scoring) and kube-controller-manager (reconciliation loops such as the Deployment, ReplicaSet, Node and Job controllers).
2. Each node runs the kubelet, which keeps the containers of its assigned Pods matching their spec and reports status and probe results. It also runs a container runtime such as containerd or CRI-O behind the CRI, and usually kube-proxy, which programs iptables or IPVS rules so Service virtual IPs reach Pod endpoints.
3. Explain the model that ties these together. Desired state is stored through the API server, and controllers keep comparing actual state with desired state and act on the difference. Nodes watch the API server; they are never pushed imperative commands.
4. Walk one change end to end. kubectl apply of a Deployment passes authentication, authorization and admission at the API server and is stored in etcd. The Deployment controller creates a ReplicaSet, which creates Pods. The scheduler binds them to nodes, the kubelet pulls the images and starts the containers, and once the readiness probe passes each Pod joins its Service's endpoints.
5. Name the objects and add-ons around the core: Pod, Deployment, StatefulSet, DaemonSet, Service (ClusterIP, NodePort, LoadBalancer), Ingress, ConfigMap, Secret and namespaces, plus a CNI plugin for Pod networking and CoreDNS for service discovery.

Follow-up

• If etcd loses quorum, what keeps running and what stops working?
• What happens to the Pods on a node that stops reporting to the control plane?
• How do liveness and readiness probes differ, and what goes wrong if you use one where the other belongs?

How do you approach designing a scalable solution for a real-world scenario?

Medium · Coding and Problem Solving

Approach

1. Turn the scenario into numbers first: core use cases, daily users, peak requests per second, read-to-write ratio, data growth and the latency target. A rough estimate decides whether one database is enough or whether partitioning is needed.
2. Sketch the baseline. Clients go through a load balancer to stateless application servers that scale horizontally. A relational database is the source of truth, a cache such as Redis sits in front of hot reads (cache-aside with a TTL), a CDN serves static and media files, and a message queue takes work that does not need to finish within the request.
3. Scale the data tier in order of cost. Fix indexes and queries first, then add read replicas (accepting replication lag on those reads), then caching, then partitioning by a key that spreads load evenly. Name the queries that become cross-partition and expensive.
4. Design for failure: timeouts, retries with exponential backoff and jitter, idempotent writes so retries are safe, rate limiting at the edge, health checks with autoscaling, and metrics, logs and traces to find the real bottleneck.
5. State the trade-offs you made. For example, accept eventual consistency on a feed or a counter in exchange for availability, but require strong consistency on payments or inventory. Say what you would revisit at ten times the load.

Follow-up

• One key, such as a viral item, takes most of the traffic. How do you stop it overloading a single cache node or partition?
• How do you keep the cache consistent with the database after a write?
• How would you add a partition later without downtime?

How do you handle edge cases when implementing a new API endpoint?

Medium · Coding and Problem Solving

Approach

1. Validate input at the boundary: required fields, types, ranges, string lengths, enum values, unknown fields and empty bodies. Reject with 400, or 422 for well-formed but semantically invalid data, using a consistent error body that names each bad field. In Spring Boot that means @Valid with Bean Validation annotations plus a @ControllerAdvice handler.
2. Keep the auth cases separate. Return 401 when the caller is not authenticated and 403 when they are authenticated but lack permission. Consider returning 404 for another user's resource so the API does not reveal that it exists.
3. Make retries safe. GET, PUT and DELETE should be idempotent by design. A POST that creates something can accept an Idempotency-Key, which the server stores with the first result and replays for repeats. Handle concurrent updates with a version column, or an ETag checked with If-Match, and return 409 or 412 on a conflict.
4. Cover the list and size edges: an empty result is 200 with an empty array, page size is capped, and cursor pagination is used when rows can be inserted between pages. Return 413 for oversized payloads, and 429 with Retry-After when a client exceeds its rate limit.
5. Plan for downstream failures. Put a timeout on every outbound call and map failures to 503 or 504 rather than leaking a stack trace. Pin each edge case with a test: boundary values, missing auth, duplicate submit, concurrent update.

Follow-up

• The client times out but the server finished the write. What happens when the client retries?
• How would you change a field's type without breaking existing clients?
• Would you use offset or cursor pagination for this endpoint, and why?

How do you approach the deployment of services within a CI/CD pipeline?

Medium · System Design and Infrastructure

Approach

1. Describe the stages in order. On every pull request: compile, run unit tests, lint and static analysis, and scan dependencies. On merge: build one immutable artifact (a Docker image tagged with the commit SHA, never latest) and push it to a registry.
2. Promote that same image through each environment, injecting configuration and secrets per environment from a secrets manager instead of rebuilding. Run integration and smoke tests against staging before production.
3. Pick a rollout strategy and state its trade-off. A rolling update (a Kubernetes Deployment's maxSurge and maxUnavailable) needs no extra capacity but runs mixed versions for a while. Blue-green switches all traffic at once and rolls back instantly, but needs double capacity. A canary sends a small share of traffic to the new version and is promoted or rolled back based on error rate and latency.
4. Keep database changes backward compatible with expand and contract: add the new column, deploy code that writes both, backfill, switch reads, then drop the old column in a later release. That way old and new versions can run side by side during a rollout.
5. Make rollback a single action (redeploy the previous image tag, or kubectl rollout undo). Manage infrastructure as code with Terraform so a reviewed plan comes before every apply. Gate production on readiness probes and alerting.

Follow-up

• How do you ship a change that renames a database column without downtime?
• Which metrics decide whether a canary is promoted or rolled back?
• A flaky test blocks the pipeline while a hotfix is waiting. What do you do?

What security measures do you implement for REST controllers?

Medium · System Design and Infrastructure

Approach

1. Authenticate every request. For stateless APIs, validate the bearer JWT's signature, issuer, audience and expiry (Spring Security's OAuth2 resource server does this); otherwise use server-side sessions. Never trust a user id sent in the request body.
2. Authorize at two levels: the role or scope required for the endpoint (@PreAuthorize or request matchers), and ownership of each record. Checking only that the user is logged in leaves broken object level authorization, the first item in the OWASP API Security Top 10: changing /orders/123 to /orders/124 returns someone else's order.
3. Treat input as hostile. Use Bean Validation on request DTOs, and parameterised queries or JPA instead of string-built SQL. Keep request DTOs separate from entities so a client cannot set fields such as role or price through mass assignment.
4. Lock down the transport and the browser surface: HTTPS only with HSTS, CORS restricted to known origins instead of *, and CSRF protection whenever authentication uses cookies (it can be disabled for pure bearer-token APIs).
5. Limit the damage of an attack: rate limiting with 429 on login and expensive endpoints, generic error responses without stack traces, security headers, and logging of auth failures that never records tokens, passwords or personal data.

Follow-up

• How do you revoke a JWT before it expires?
• Where should a browser client keep its access token, and which attack does each option expose?
• How would you test that one user cannot read another user's records?

How do you ensure secure transactions across a distributed application?

Medium · System Design and Infrastructure

Approach

1. Split the question into confidentiality, authenticity and integrity. Secure here means nobody can read or forge a transaction, and also that each transaction is applied exactly once and consistently.
2. Encrypt and authenticate every hop: TLS from clients, and mutual TLS between services (often through a service mesh) so each service has a verifiable identity. Encrypt data at rest, with keys held in a KMS or vault and rotated.
3. Propagate identity with scoped tokens. Each downstream call carries a token whose audience is that service and whose scopes are minimal. Every service enforces authorization itself instead of assuming the gateway already checked.
4. Protect money-moving calls against duplicates and replay. Store an idempotency key with each transaction's outcome. Sign webhook and partner requests with HMAC over a timestamp and nonce. Use a saga or outbox so a failure partway through ends in a compensated state, not a half-applied one.
5. Shrink and audit the sensitive surface. Tokenize card data through a payment provider so raw card numbers never reach internal services, keep an append-only audit log of state changes, and reconcile internal ledgers against the provider's records to catch drift.

Follow-up

• A charge succeeds at the provider but the response is lost. How does the system avoid charging twice or losing the record?
• How would you rotate a signing key without rejecting requests already in flight?
• What stops an attacker who compromises one internal service from calling the payment service?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Seven days built around the four reported rounds and the twenty reported questions: infrastructure and security first, then coding and SQL, front-end and concurrency, design and API questions, and finally behavioral stories with a full run-through.

Day 1 — Map the loop and inventory your projects

• Write the four reported rounds (Screening Call, Technical Assessments, Managerial Interview, Behavioral Interviews) on one page and mark which you feel least ready for.
• For each resume project, write the stack, why you chose the framework and database, the hardest technical hurdle and one measurable result.
• Mark each tool in the role's requirements (Java, Python or JavaScript, SQL, Docker, Kubernetes, CI/CD, AWS or Azure) as production, side project or unused.

Deliverable: A one-page loop map plus a project sheet with one row per resume project and a tool-experience list.

Day 2 — Containers, Kubernetes and Terraform

• Write a multi-stage Dockerfile for a small service with a non-root user and a layer order that caches dependencies, then note why each line is there.
• Explain aloud the components of a Kubernetes cluster and trace a Deployment from kubectl apply to a running pod, then describe your own container and orchestration experience in a minute.
• Write a short Terraform configuration for one resource and explain plan, apply and state.
• Work through the practice question on edge instances that grow 400 MB per hour, writing the diagnosis steps you would run.

Deliverable: A Dockerfile with annotations, a one-page Kubernetes request-path diagram, a small Terraform file and a written diagnosis sequence for the memory-growth question.

Day 3 — Secure transactions and microservice integrity

• Outline a saga for an order flow across three services with compensating steps, an outbox table and an idempotency key on each call.
• List the security layers for a REST controller and for a distributed transaction: authentication, authorisation, input validation, TLS, secrets handling and rate limiting.
• Say each answer aloud in two minutes and fix any step where you reached for a buzzword instead of a mechanism.

Deliverable: A saga sequence diagram, a security checklist for REST endpoints and distributed transactions, and three timed spoken answers.

Day 4 — Coding and SQL

• Write the second-highest salary query three ways and test each against duplicates, a single row, an empty table and NULL salaries.
• Solve the array target-sum problem with a brute-force pass and a hash-set version, then state time and space for each.
• Explain your approach to one coding problem you know well, from restatement to complexity, then choose between two database schemas for a given workload and justify it.

Deliverable: Three tested SQL queries, two working target-sum functions with complexity notes and one written schema comparison.

Day 5 — Concurrency, JavaScript and LWC

• Write a racing counter in your language, reproduce the lost updates and fix it with a lock, then with an atomic; add a producer-consumer example with a blocking queue.
• Build a small nested-element page that logs capture and bubble phases, and test stopPropagation and a delegated handler.
• Write a note on LWC for:each versus the iterator directive, including keys and the first and last flags, and answer aloud.

Deliverable: A reproduced and fixed race, a working event-propagation demo and a one-page LWC iteration note.

Day 6 — Design, APIs and delivery pipelines

• Design one service end to end for scale: read and write paths, data store, cache, failure handling, and what breaks at ten times the traffic.
• List the edge cases for a new API endpoint: validation, idempotent retries, pagination, versioning, error codes and authorisation.
• Draw a CI/CD pipeline for a containerised service with test, build, scan, staged rollout and rollback.

Deliverable: A one-page scalable design, an endpoint edge-case checklist and an annotated pipeline diagram.

Day 7 — Behavioral stories and a full run-through

• Write four stories in situation, task, action and result form: conflict, competing deadlines, pressure, and a challenging project, each with one number.
• Prepare the answer to why you want this role and what you would bring, using specifics from the role description and your own record.
• Run the stories and two technical answers aloud in a single sitting and note each place you rambled.

Deliverable: Four written stories with metrics, a written role-motivation answer and a marked-up list of fixes from the run-through.

Behavioral and managerial preparation

Candidates report a Managerial Interview and Behavioral Interviews that center on past experiences, team conflict, adaptability, teamwork and how you handle feedback. For a Software Engineer role, prepare stories that name a technical decision, the alternative you rejected and a result you measured. Reported prompts come first below.

1. How do you handle a situation where you disagree with a technical decision?

How do you handle synchronization in a multi-threaded environment?

Medium · Technical Fundamentals and CS Core

Approach

1. Start from the hazard: shared mutable state. Give the classic example, count++ on two threads, which is read, add, write and loses updates without protection. Say the best fix is often to avoid sharing at all: immutable objects, thread confinement, or passing messages through a queue.
2. Where state must be shared, pick the mechanism by need. A mutex or Java synchronized block or ReentrantLock gives mutual exclusion; AtomicInteger or compare-and-swap handles a single variable without a lock; ConcurrentHashMap and BlockingQueue give ready-made safe structures. Python's GIL does not make compound operations such as x += 1 atomic, so locks are still needed.
3. Cover visibility and ordering as well as exclusion. Without a lock, volatile or an atomic, one thread may never see another's write. A volatile flag works for a stop signal but not for check-then-act sequences, which need a lock or atomic update.
4. Name the failure modes and their prevention: deadlock (take locks in one global order, use tryLock with a timeout, hold locks briefly), livelock, starvation, and holding a lock across I/O. Keep critical sections small, and use wait/notify or condition variables, or a blocking queue, for producer-consumer hand-off.
5. Close with how you verify: stress tests with many threads, ThreadSanitizer or a similar race detector, and thread dumps to find a deadlock.

Follow-up

• What are the conditions for deadlock, and which one do you break with lock ordering?
• When is volatile enough, and when do you need synchronized or an atomic class?
• How would you make a counter or cache safe for many readers and few writers?

Explain your experience with container orchestration and Dockerfile creation.

Medium · System Design and Infrastructure

Approach

1. Answer with real experience at the level you have, and say so: Docker on a laptop, Docker Compose, or a Kubernetes cluster you operated. Overstating orchestration experience is easy to expose, so name the exact commands, manifests and failures you handled.
2. For Dockerfile creation, show decisions: pinned base image and a slim variant, a multi-stage build so compilers stay out of the runtime image, copying dependency manifests before source so the layer cache survives code changes, a .dockerignore, a non-root USER, no secrets baked in, and a HEALTHCHECK or exposed port that matches the app.
3. For orchestration, name the objects you used: Deployment with a rolling update, Service, ConfigMap and Secret, readiness and liveness probes, resource requests and limits, and perhaps a HorizontalPodAutoscaler or Helm chart. Explain one choice, such as why readiness gates traffic while liveness restarts a stuck process.
4. Tell it as a story with a measurable result: image shrank from some size to another, build time dropped, or a bad deploy was rolled back cleanly. Say what you personally changed and what the team decided jointly.

Follow-up

• A pod is in CrashLoopBackOff. What do you run, and in what order?
• How would you cut the size and build time of this image?
• What is the difference between a liveness and a readiness probe, and what goes wrong if you confuse them?

Tell me about a time you handled a conflict within your team.

Medium · Behavioral and Cultural Fit

Approach

1. Choose a conflict with substance, such as a disagreement over an API design, a review standard or who owned a deadline slip, not a personality clash with no work content. Give the situation in two sentences, then say what each person wanted and why both positions were reasonable.
2. Show your actions in order: you spoke with the person directly first, tried to understand their constraint, then moved the argument to evidence such as a prototype, a benchmark or a short written comparison. Escalate only when that stalls, and say how.
3. State the resolution and the result: what was decided, what shipped and how the working relationship stood afterwards. If you conceded, say what convinced you; if they did, say what you offered.
4. Avoid the stories that sink this answer: blaming the other person, casting yourself as the only reasonable one, or ending with "we agreed to disagree" and no outcome. Finish with one thing you now do earlier to prevent the same conflict.

Follow-up

• What would you have done if the other person had been more senior than you?
• What if your manager had sided against you?
• How did you rebuild trust with that colleague afterwards?

How do you prioritize tasks when faced with competing deadlines?

Medium · Behavioral and Cultural Fit

Approach

1. Give your method before the story: list every task, mark the real deadline and who owns it, estimate size, and rank by impact and cost of delay, not by who is loudest. Separate hard dates (a release, a customer commitment) from soft ones.
2. Tell one concrete case with real items, for example a production bug, a feature due Friday and a code review backlog. Say what you did first, what you postponed, and what you cut or renegotiated, such as shipping a narrower scope.
3. Show communication: you told each stakeholder the trade-off and the new date before the deadline, rather than quietly missing it. Name who agreed and what they accepted.
4. Say how you protected quality, for instance keeping tests and review in place for the item you shipped. The answer that fails is "I work longer and do everything", because it shows no judgement and no trade-off.

Follow-up

• Two managers each call their task the top priority. What do you do?
• A new urgent task arrives mid-sprint. How do you decide what moves?
• What did you drop in that story, and was it the right call in hindsight?

Describe a time you had to solve a problem under pressure.

Medium · Behavioral and Cultural Fit

Approach

1. Pick an incident where you carried responsibility, such as a failed deploy, a production outage or a deadline that suddenly moved, and say what made it pressured: users affected, time left, who was waiting.
2. Walk through the order you worked in: first stabilise (rollback, feature flag, scale up, disable the failing path), then diagnose from evidence (logs, metrics, the last change), then fix properly. Explain why you chose rollback over a forward fix, or the reverse.
3. Show communication under stress: who you updated, how often and what you said, including how you put the issue to non-technical stakeholders. Say who you pulled in and why.
4. Finish with the aftermath: the root cause, the follow-up fix and the guard you added, such as an alert, a test or a deploy check. If you caused the problem, say so plainly; hiding it is the quickest way to lose the answer.

Follow-up

• How did you decide between rolling back and fixing forward?
• What did you change afterwards so it could not happen again?
• How did you keep the team calm and informed while it was happening?

Tell me about a challenging project you worked on and how you contributed to its success.

Medium · Behavioral and Cultural Fit

Approach

1. Choose the project you can defend at depth, preferably one on your resume that uses a listed technology such as Spring Boot, React, Node.js, SQL, Docker or Kubernetes. Open with the goal and why it was hard in two sentences, for example scale, a deadline, an unclear requirement or a messy legacy component.
2. Spend most of the answer on your own contribution and the reasoning: the options you weighed (framework, database, schema, sync or async), why you chose one, and the specific hurdle you overcame. Use "I" for your decisions and "we" only for team outcomes.
3. Cover non-functional work: how you tested it, secured it and checked its performance, since reports list optimization and security among the deep-dive areas. Name the metric that moved.
4. End with what you would redesign today. A project told as a flat feature list, or as the team's work with no personal decision, leaves the follow-up questions with nothing to hold.

Follow-up

• Why did you choose that framework or database over the alternatives?
• How did you make it secure and able to scale, and how did you check?
• What part of the design would you change if you rebuilt it now?