Most of the reported questions are phrased as "how do you..." or "describe your experience with...", not as puzzles. That shapes preparation: each answer needs a real system behind it, with named components, a number that shows scale or improvement, and the trade-off you accepted. A list of tools you have used, with no decision attached, gives the listener nothing to follow up on. Before the loop, pick three or four systems from your own work that you can describe at the level of request paths, data stores, deployment and failure handling, because the same systems will carry your answers on CI/CD, observability, integrations and incidents.
The reported questions fall into four groups. Delivery and SDLC questions cover post-deployment validation, CI/CD and release management for containers, high availability and observability, technical debt, and database performance tuning. Domain questions go into serverless and container infrastructure, FastAPI and asyncio, state management in React and React Native, authentication with Okta OIDC and JWT, and third-party integrations. Design questions include a multi-tenant, self-hosted AI agent platform, fault tolerance on AWS, vector database selection with retrieval augmentation, an integration you designed, and platform-wide observability standards. The behavioral group covers a project built from scratch, influence without authority, cross-functional disagreement, a failed production deployment and motivation for fintech.
Candidates also list Python, SQL, coding challenges, code explanation and SDLC knowledge as tested topics, and the Technical Assessments stage is reported as coding challenges or asynchronous tasks. Do not let the discussion-heavy question set talk you out of hands-on practice: work timed problems in your main language and a few SQL exercises on indexing and query plans, and practise explaining code you wrote line by line.
The stack candidates describe is concrete enough to prepare against: AWS ECS, Fargate, Lambda, API Gateway and S3; GitLab and Terraform for delivery; Okta OIDC and JWT for identity; FastAPI and asyncio; React, React Native and TypeScript; and, as nice-to-haves, LangGraph, the OpenAI SDK, Autogen, vector databases and ServiceNow. Go deep on your own track and be able to hold a sensible conversation about the other, and build security, audit logging and data privacy into every design you sketch, since the tips candidates pass on stress that for this regulated setting.
Recruiter Screening Call
reportedCandidates describe an opening conversation about their background, their interest in the role and general alignment. Use it to establish which track you are on (Python and AWS backend, React and React Native, or platform integration) and to collect the facts you need for the rest of the loop: which team is hiring, whether the Technical Screen is a technical assessment or a video assessment, what the Technical Assessments look like, and the team's hybrid or on-site arrangement. Have a short summary of your most relevant system ready, and a specific answer to why financial technology and why this company.
What to demonstrate
- Candidates describe the call as covering background, interest in the role and general alignment.
- Your background and interest in the role
How to prepare
- Write a short walk-through of your career that ends on the system closest to this role's stack (AWS containers, FastAPI, React or React Native, enterprise integrations) and rehearse it aloud.
- Prepare the motivation answer covered in the fintech question below, built on two concrete facts about the work rather than general praise.
- List the questions to ask: format of the Technical Screen, format of the Technical Assessments, panel composition, and the team's office arrangement.
Technical Screen
reportedCandidates describe a first technical stage that is either an assessment or a video format with set prompts about their work and how they approach problems. If it is a video assessment, you may not be able to ask clarifying questions, so make each answer self-contained: state the context in a sentence, give the specific action you took with named tools, give the result, and stop. If it is a conversation, the same structure works but leave room for follow-ups. Ask the recruiter which format you will get and practise for that one.
What to demonstrate
- How clearly you explain your own technical work to someone without context
- How you structure your approach to a problem when answering a set prompt
- Your answers to structured prompts about your experience and problem-solving approach
How to prepare
- Record yourself answering the delivery questions in this guide (post-deployment validation, CI/CD for containers, tech debt) and replay each: cut any sentence that names a tool without a decision.
- Prepare one project explanation that covers the request path, data store, deployment and one failure you handled, so it can be reused across prompts.
- For a video assessment, practise answering cold from a written prompt with no restart, so each answer stands on its own.
Technical Assessments
reportedCandidates describe this stage as coding challenges or asynchronous technical tasks. For a coding challenge, the work is producing correct, readable code and explaining it: restate the problem, give the simple solution and its complexity, improve it, then test edge cases. For an asynchronous task, submit it as you would a production change: a short README with assumptions, tests that cover the edge cases, clear module boundaries and notes on what you would do with more time. Ask whether you can choose the language, and use the one you write fastest.
What to demonstrate
- Working, correct code under the format given
- Code that another engineer can read and test
- Your ability to explain the choices in code you wrote
How to prepare
- Work the practice coding problems in this guide (finding the heaviest tenants in a time window under memory pressure, merging partitioned event streams with bounded lateness) under a timer, then explain each solution aloud.
- Practise the two SQL exercises in this guide on soft-deleted accounts and an ignored index, reading the query plan for each.
- Build a small asynchronous-task template you can reuse: project layout, test runner, README sections for assumptions and trade-offs.
Panel Interviews
reportedCandidates report panels with hiring managers, technical leads and peer engineers covering past projects, architecture thinking and system design. Reports say the balance between code deep dives and behavioral or architecture discussion varies by role. Prepare for both: at least two system designs you can draw end to end, and a set of stories that each show your own decision and its result. Be ready to go from architecture level down to specific code or config.
What to demonstrate
- System design and architecture reasoning, including trade-offs
- Depth and ownership in past projects
- Collaboration, influence and handling of incidents and disagreement
How to prepare
- Rehearse two full designs from the reported questions: the multi-tenant AI agent platform and a fault-tolerant service on AWS, each with tenancy, identity, failure handling and audit logging.
- Prepare four stories mapped to the reported behavioral questions: a project built from scratch, influencing without authority, a cross-functional disagreement and a failed deployment.
- For each project you mention, be ready to go one level deeper on demand: the schema, the deployment pipeline, the alert that fired, the code you changed.
PracHub editorial advice for the preparation topics above.
Answering the FastAPI and asyncio question with vocabulary, then describing code that makes blocking calls inside async endpoints.
Be able to explain the event loop, why one blocking call stalls every request on it, how FastAPI treats async def versus def endpoints, and how you bound concurrency and set timeouts. Have one real bottleneck you found and fixed, with the before and after numbers.
Sketching the AI agent platform or an AWS design with no tenant isolation, identity or audit trail, then adding security only when asked.
For every design, include from the start: how a caller is authenticated (Okta OIDC, JWT validation), how authorization is decided per resource, how tenant data is separated, what gets written to an audit log, and how personal data is kept out of logs and prompts. Candidates' tips stress security and compliance in design answers for this regulated setting.
Telling the project, influence and incident stories in "we", so the panel cannot tell what you personally decided or built.
Rewrite each story so the actions are yours ("I chose", "I rolled back", "I wrote the comparison"), keep context to a couple of sentences, and end with a measured result and one thing you would change.
Rambling through the Technical Screen's video assessment prompts because there may be no interviewer to steer you.
Ask the recruiter which format you will get. For a video assessment, practise from written prompts with a fixed structure (context, action with named tools, result) and replay your recordings to cut tool lists that carry no decision.
Skipping coding and SQL practice because most reported questions are discussion questions, then struggling in the Technical Assessments.
Candidates list Python, SQL and coding challenges among tested topics, and report coding challenges or asynchronous tasks in the Technical Assessments. Work timed problems in your main language, read query plans on a few SQL exercises, and practise explaining your code line by line.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
What is your experience with asynchronous programming frameworks like FastAPI and asyncio in Python?
What is your experience with asynchronous programming frameworks like FastAPI and asyncio in Python?
Approach
- Explain the model: asyncio runs one event loop per thread with cooperative scheduling, so any blocking call inside an async function (a synchronous HTTP client, a sync database driver, heavy CPU work) stalls every request on that loop.
- In FastAPI, async def endpoints run on the event loop, while plain def endpoints run in a thread pool. Use async drivers and clients (httpx.AsyncClient, asyncpg) in async endpoints, and move unavoidable sync calls to asyncio.to_thread or run_in_executor.
- For fan-out, use asyncio.gather or a TaskGroup, bound concurrency with a Semaphore so you do not overwhelm a downstream service, and wrap calls in timeouts. CPU-bound work goes to a process pool or a background worker queue.
- Share long-lived resources (HTTP client, DB pool) through the application lifespan instead of creating them per request, and be careful with mutable state across await points, where another task can run in between.
- Back it with an example: a bottleneck you found (for example a blocking call in an async route), how you found it, and the latency or throughput change after fixing it.
Follow-up
- How would you detect a blocking call hiding inside an async endpoint?
- With gather, one of ten calls fails. What happens to the other nine, and what do you want to happen?
- How do you choose the number of worker processes versus concurrency per process?
Identify the heaviest tenants in a five-minute window under memory pressure
The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.
Approach
- Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
- Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
- State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
- Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.
Follow-up
- The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
- Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?
Merge partitioned event streams into one ordered feed with bounded lateness
The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.
Approach
- Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
- Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
- Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
- Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.
Follow-up
- The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
- The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?
Keep soft-deleted accounts from blocking re-registration
app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.
Approach
- Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
- Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
- For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
- State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.
Follow-up
- A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
- How do you honour an erasure request while resource_revision.actor_user_id still references this table?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
What are the different types of frameworks you have worked with, and how do you approach post-deployment valid
What are the different types of frameworks you have worked with, and how do you approach post-deployment validation?
Approach
- Group the frameworks by layer instead of listing them: a web framework (for example FastAPI), a UI framework (React or React Native), test frameworks (pytest, Jest), and infrastructure tooling (Terraform). For each, say one reason you chose it over an alternative.
- Define post-deployment validation as checking the change in the real environment, not repeating CI: automated smoke tests against the deployed service, synthetic checks on the main user journeys, and health or readiness checks on the new tasks.
- Describe progressive release: a canary or blue/green rollout where the new version takes a slice of traffic and you compare error rate and p99 latency against the old version before promoting. Name the rollback trigger in advance.
- Cover the hard cases: database migrations (expand, migrate, then contract so the old version still works during rollout), feature flags to separate deploy from release, and mobile apps that cannot be rolled back, which need staged rollouts and server-side kill switches.
- Close with one example: a release where validation caught a regression, what signal showed it and how fast you rolled back.
Follow-up
- How do you choose the error-rate threshold that triggers an automatic rollback?
- How would you validate a release that includes a schema change?
- A React Native release has a bug and users will not update for weeks. What can you do?
How do you manage technical debt while simultaneously delivering new product features on schedule?
How do you manage technical debt while simultaneously delivering new product features on schedule?
Approach
- Make debt visible and costed: keep it in the same backlog as features, and attach evidence such as incidents caused, hours lost per sprint, or slower lead time on a module.
- Prioritise by interest rate: debt in code that changes often and breaks often is worth paying first; debt in stable code nobody touches can wait.
- Use delivery-friendly mechanisms: fix debt in the code a feature already touches, reserve a fixed share of each sprint for debt, and for legacy systems use a strangler pattern that moves functionality piece by piece behind a stable interface.
- Explain how you negotiated with product: framed debt work in terms the PM cares about (release speed, incident risk, compliance findings) and agreed a trade, not a demand.
- Give one example with numbers: what you paid down, what it cost in sprint capacity, and what improved.
Follow-up
- The PM wants the feature now and the debt is a security risk. What do you do?
- How do you stop new debt from building up while you pay off the old?
- Which piece of debt did you decide to leave alone, and why?
What strategies do you use for performance tuning and database optimization in high-throughput applications?
What strategies do you use for performance tuning and database optimization in high-throughput applications?
Approach
- Start with measurement: identify the slow endpoint from p95 or p99 latency, profile it, and find where time goes (database, network, CPU, lock waits) before changing anything.
- Database level: read the plan with EXPLAIN ANALYZE, add composite indexes whose column order matches the filter and sort, use covering indexes for hot reads, remove N+1 queries by batching or joining, and replace OFFSET pagination with keyset pagination on large tables.
- Connection and concurrency: use a connection pool (or a proxy such as RDS Proxy for serverless callers), keep transactions short, and watch for hot-row lock contention on counters or balances.
- Scale out reads with caching (read-through with TTL and explicit invalidation, plus protection against stampedes) and read replicas, stating that replicas lag so read-after-write paths must go to the primary.
- Name the costs: every index slows writes and uses storage, caches add staleness, and partitioning helps only if queries filter on the partition key.
Follow-up
- A query is fast in staging and slow in production. What do you check?
- A popular cache key expires and the database falls over. What happened and how do you prevent it?
- When would you denormalise a table, and what do you give up?
Can you explain how you design scalable, modular infrastructure using serverless architectures and container o
Can you explain how you design scalable, modular infrastructure using serverless architectures and container orchestration?
Approach
- Choose compute by workload: Lambda for event-driven, bursty, short work (it has a maximum execution time, cold starts and concurrency limits); ECS on Fargate for long-running services, steady traffic, long connections or custom runtimes; API Gateway in front of either for routing, throttling and auth.
- Decouple components with queues and events (for example SQS between an API and its workers) so each part scales and fails independently, and store artifacts and large payloads in S3 rather than passing them through functions.
- Make it modular in Terraform: reusable modules with clear inputs and outputs, separate state per environment with locking, and versioned modules so a change to one team's module does not silently change another's stack.
- Security per component: a dedicated IAM role per function or task with least privilege, private subnets for services, and secrets fetched at runtime.
- Scaling and cost: target-tracking autoscaling on ECS; provisioned concurrency where cold starts hurt, and reserved concurrency to guarantee or cap a function's share of the account limit (for example to protect a database); and know where steady high traffic makes containers cheaper than per-invocation pricing.
Follow-up
- Your Lambdas exhaust the database's connections during a spike. How do you fix it?
- How do you detect and handle drift between Terraform state and what is actually deployed?
- At what traffic pattern would you move a workload from Lambda to Fargate?
How do you approach state management, navigation, and cross-cutting concerns in large-scale React and React Na
How do you approach state management, navigation, and cross-cutting concerns in large-scale React and React Native applications?
Approach
- Separate kinds of state: server state (fetched data) in a caching library such as React Query or RTK Query with explicit invalidation; local UI state in component state; truly global client state (session, feature flags) in a small store such as Redux Toolkit or Zustand. Explain why putting everything in one global store causes needless re-renders.
- Use context for low-frequency values (theme, locale, auth user) and avoid it for fast-changing values, or split contexts so consumers re-render only when their slice changes.
- Navigation: React Navigation on mobile and a router on web, with authenticated and unauthenticated stacks, deep links mapped to routes, and route-level data loading.
- Cross-cutting concerns as shared layers: an API client that attaches and refreshes tokens, error boundaries, analytics and logging hooks, feature flags, accessibility and theming in a shared component library published as a typed package used by both web and native apps.
- Mention performance tools: the React Profiler for re-render problems, memoisation only where measured, and virtualised lists (FlatList) for long data on mobile.
Follow-up
- How much code do you share between the web and React Native apps, and where do you stop?
- How would you support offline use on mobile for a screen that shows account data?
- A screen re-renders on every keystroke elsewhere in the app. How do you find the cause?
Can you walk through how you implement secure authentication and authorization using Okta OIDC, JWT, and fine-
Can you walk through how you implement secure authentication and authorization using Okta OIDC, JWT, and fine-grained policies?
Approach
- Pick the flow: Authorization Code with PKCE for web and mobile clients through Okta, client credentials for service-to-service calls. Distinguish the ID token (who the user is, for the client) from the access token (what the caller may do, for APIs).
- Validate every JWT on the API: verify the signature against the issuer's JWKS (cache keys, refetch on an unknown kid to handle rotation), check iss, aud, exp and nbf, and allow only the expected algorithm.
- Token handling: short-lived access tokens with refresh token rotation; on web, keep tokens out of localStorage, for example with a backend-for-frontend and httpOnly cookies; on mobile, store them in Keychain or Keystore.
- Authorization beyond the token: scopes or group claims for coarse checks, and fine-grained decisions (this user on this account) in a policy layer such as OPA or Cedar that evaluates user, resource and action attributes, deny by default, with every decision logged for audit.
- State the revocation trade-off: JWTs are stateless, so revocation means short lifetimes, token introspection for high-risk operations, or a deny list.
Follow-up
- A user's access is removed. How quickly do they lose it with your design, and how would you make it immediate?
- How do you test authorization rules so a refactor does not open access?
- How does one backend service call another on behalf of a user?
How do you integrate third-party APIs or enterprise systems while maintaining data integrity and system securi
How do you integrate third-party APIs or enterprise systems while maintaining data integrity and system security?
Approach
- Define the boundary first: an adapter layer that owns the vendor's API, validates every inbound and outbound payload against a schema, and maps vendor errors to your own error types, so the rest of the system does not depend on the vendor's shapes.
- Integrity: idempotency keys on writes so retries do not duplicate records, retries with exponential backoff and jitter only for retryable errors, timeouts and a circuit breaker, and the outbox pattern so a database write and the outbound message cannot diverge.
- Add reconciliation: a scheduled job that compares records on both sides (for example a CRM such as Salesforce against your own store) and flags or repairs differences, plus a dead-letter queue for messages that keep failing.
- Security: credentials in a secrets manager with rotation, least-privilege OAuth scopes, TLS everywhere and allowlisting or mTLS where offered, sending only the fields the vendor needs, and audit logs of every data exchange.
- Respect vendor limits: rate limiting and batching on your side, and a plan for when the vendor is down (queue and replay rather than fail the user's request).
Follow-up
- The vendor sends the same webhook three times. What prevents a triple update?
- The vendor changes a field format without notice. How do you find out, and how fast?
- The vendor is down for a full day. What does the user see, and what happens when it recovers?
How would you architect a self-hosted AI agent platform supporting multiple agent frameworks and multi-tenant
How would you architect a self-hosted AI agent platform supporting multiple agent frameworks and multi-tenant scaling?
Approach
- Clarify scope: who the tenants are (internal teams or business units), how many agents and concurrent runs, which frameworks must be supported (for example LangGraph, the OpenAI SDK and Autogen), and what isolation and data residency each tenant needs.
- Control plane: an agent registry with versioned configs, a tool registry where each tool has an owner, a schema and the permissions it requires, and per-tenant policies and quotas. Data plane: each framework packaged as a container behind a common adapter interface (start, stream, cancel, checkpoint) running on ECS or Fargate.
- Runs: an API that accepts a run and puts it on a queue, workers that execute it and persist checkpoints and conversation state to a database so long runs can resume, and a model gateway that every LLM call passes through for per-tenant rate limits, cost tracking and logging.
- Isolation trade-off: pooled infrastructure with tenant IDs on every record and per-tenant concurrency limits is cheaper; dedicated task pools or accounts per tenant isolate noisy neighbours and sensitive data better. Tools run with tenant-scoped credentials, and risky actions need an approval step.
- Safety and observability: step and token budgets so an agent cannot loop forever, prompt-injection defences on tool outputs, PII redaction, a trace per run with each step and tool call, and an immutable audit log.
Follow-up
- One tenant requires that its data never shares compute with others. What changes?
- An agent gets stuck calling the same tool repeatedly. How does the platform stop it?
- How do you upgrade a framework version without breaking agents already in production?
What considerations do you make when designing fault-tolerant distributed systems in cloud environments like A
What considerations do you make when designing fault-tolerant distributed systems in cloud environments like AWS?
Approach
- Name the failure domains: a single task or instance, an availability zone, a dependency, and a region. Decide which ones the system must survive from the RTO and RPO the business needs.
- Within a region: stateless services spread across zones behind a load balancer with health checks, autoscaling, managed databases with a standby in another zone, and backups you have actually restored.
- Between services: timeouts on every call, retries with exponential backoff and jitter on idempotent operations only, circuit breakers and bulkheads so one slow dependency does not consume all threads, and queues to absorb spikes and outages.
- Degrade instead of failing: serve cached or partial data, turn off non-essential features, and shed load deliberately. For multi-region, compare active-passive (simpler, some data loss and failover time) with active-active (harder consistency, faster recovery).
- Prove it: game days and fault injection, and alarms that tell you failover happened.
Follow-up
- A downstream service slows down and your retries make it worse. What went wrong?
- The business asks for near-zero data loss across regions. What does that cost?
- How would you test zone failure without hurting customers?
How do you approach vector database selection, retrieval augmentation, and prompt patterns for enterprise AI i
How do you approach vector database selection, retrieval augmentation, and prompt patterns for enterprise AI implementations?
Approach
- Selection criteria: number of vectors and growth, query latency target, metadata filtering (tenant and document permissions must be filterable at query time), hybrid search with keyword scoring, index type (HNSW for low-latency recall, IVF-style for very large sets), update frequency, and whether a managed service or pgvector in an existing Postgres meets residency and operations needs.
- Ingestion: structure-aware chunking with overlap, one embedding model applied consistently, metadata on each chunk (source, owner, access list, timestamps), and a re-indexing path for updated or deleted documents.
- Retrieval: top-k search filtered by the caller's permissions, optional reranking, and only then building the prompt. Prompt pattern: clear instructions, retrieved passages delimited and cited, an instruction to say it does not know when the context lacks the answer, and structured output where downstream code parses it.
- Evaluate it: a fixed set of questions with known answers, measuring retrieval recall at k and answer faithfulness, run on every change to chunking, model or prompt.
- Enterprise concerns: documents can contain prompt injection, PII must be filtered or masked, and every answer should be traceable to the sources used.
Follow-up
- You switch embedding models. What happens to the existing index?
- A user gets an answer drawn from a document they should not see. Where did the design fail?
- How do you tell whether a wrong answer came from retrieval or from the model?
Can you describe a complex system integration you designed and how you handled potential bottlenecks or failur
Can you describe a complex system integration you designed and how you handled potential bottlenecks or failure points?
Approach
- Set the scene briefly with numbers: which systems were connected, the direction and volume of data, and the business reason for the integration.
- Name the bottlenecks and failure points you identified up front: vendor rate limits, synchronous calls in the user's path, batch windows, schema mismatches, and partial failures where one side commits and the other does not.
- Explain what you built against each: async processing through a queue with backpressure, idempotent writes, retries with backoff and a dead-letter queue, reconciliation jobs, and dashboards and alerts on lag and error rate.
- State your own part with "I" and the result: throughput, error rate or manual work removed. Then say one thing that failed in production and how you changed the design.
- Close with what you would do differently now, which shows you learned from it rather than only describing it.
Follow-up
- What was the worst failure this integration had in production, and how was it found?
- How did you test the integration before going live with real data?
- If volume grew tenfold, which part breaks first?
How do you establish platform-level observability standards, including logging, metrics, tracing, and governan
How do you establish platform-level observability standards, including logging, metrics, tracing, and governance dashboards?
Approach
- Define the standard concretely: structured JSON logs with required fields (service, environment, trace ID, request ID), rules for what must never be logged (credentials, account numbers, personal data) with masking in the logging library, and log levels with clear meaning.
- Metrics and tracing: a naming convention and standard service metrics (request rate, errors, duration), OpenTelemetry instrumentation with W3C trace context propagated across HTTP and queue hops, and a collector that routes data to the backends.
- Make adoption the default: ship it as a shared library and service template so new services are compliant from the start, and offer dashboards and SLO alerts generated from the standard fields.
- Governance dashboards: coverage of services meeting the standard, SLO compliance per team, retention and access controls on telemetry, and audit of who queried sensitive logs.
- Control cost: limit high-cardinality labels, choose head or tail-based trace sampling, and set retention per data type.
Follow-up
- Half the teams ignore the standard. How do you get them on it without mandates?
- Metrics costs triple after one release. What do you look for?
- When would you choose tail-based sampling over head-based?
Can you describe a complex project you built from scratch and walk through your specific contributions and arc
Can you describe a complex project you built from scratch and walk through your specific contributions and architectural choices?
Approach
- Open with the problem and constraints in two or three sentences: who needed it, what existed before, and the limits (deadline, compliance, team size).
- Spend most of the answer on your own decisions, told with "I": the architecture you chose, two or three key choices (data store, sync versus async, build versus buy), and the alternatives you rejected with the reason.
- Show how you delivered it: the order you built it in, how you tested and released it, and how you brought others in.
- Give results with numbers (users, latency, cost, incidents) and one thing that went wrong and what you changed.
- The mistake that sinks this answer is a team story in "we" where your own contribution cannot be separated out, or a tour of every component with no decisions.
Follow-up
- Which architectural choice would you reverse now?
- What part of this did someone else own, and how did you work with them?
- How did the system behave under its first real production load?
Edge instances grow 400 MB per hour until the nightly restart
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
- 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.
- 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.
- 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.
- 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?
Each day targets one group of reported questions or one round, and pairs them with the practice problems in this guide on coding, SQL and debugging. Every day ends in something written or recorded that you reuse on the next day and in the panel.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Set up the loop and your source material
- Write the four reported rounds and, for each, the questions you will ask the recruiter about format (technical assessment or video assessment for the Technical Screen, coding challenge or asynchronous task for the Technical Assessments).
- Pick three or four systems from your own work and write for each: request path, data stores, deployment, one failure and one number that shows scale or improvement.
- Research the company's product and technology pages, then write and rehearse your answer to why fintech and why this company, linking one product surface to this role's reported work.
Deliverable: A round sheet with recruiter questions, a one-page brief on each of your systems, and a recorded motivation answer.
Practice prompt ↗02Python async and coding
- Write a small FastAPI service with one endpoint that fans out to three slow calls using an async HTTP client, a semaphore and timeouts, then add a blocking call and observe the effect on concurrent requests.
- Solve the heaviest-tenants-in-a-window problem under a timer, then explain the data structure and its memory use aloud.
- Solve the problem of merging partitioned event streams with bounded lateness, testing late and out-of-order events.
Deliverable: A working async service with notes on what the blocking call did, and two timed coding solutions with recorded explanations.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03SQL and database performance
- Work the soft-deleted accounts exercise and write the constraint or partial index that allows re-registration.
- Work the ignored-index exercise: read the query plan, explain why the index is skipped, and fix it.
- Write your answer to the performance tuning question around one real slow query you fixed: measurement, plan, index or query change, result.
Deliverable: Two solved SQL exercises with annotated query plans and a written performance-tuning answer with numbers.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Delivery, observability and debugging
- Draw your CI/CD pipeline for a containerized service from commit to production, marking where the image is built, scanned, tested, promoted and validated after deploy.
- Record answers to the post-deployment validation, CI/CD, DevOps and availability, and technical debt questions using the systems from day 1.
- Work the debugging exercise where edge instances grow steadily in memory until a nightly restart, writing the sequence of checks you would run.
- Outline a platform observability standard: required log fields, metric names, trace propagation and governance dashboard.
Deliverable: A pipeline diagram, four recorded delivery answers, a written memory-leak investigation, and a one-page observability standard.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05Cloud infrastructure, identity and integrations
- Sketch a service on AWS that uses API Gateway, Lambda for event work and ECS on Fargate for a long-running API, with IAM roles per component and Terraform module boundaries, then list its failure domains and how it survives each.
- Walk through an Okta OIDC login with PKCE and the JWT checks your API runs, then add a fine-grained authorization rule and how it is audited.
- Write the integration answer for a third-party system such as a CRM: adapter, idempotency, retries, reconciliation and secrets, then prepare your own integration story with its failure points.
- Outline moving data from internal systems into a warehouse such as Snowflake: incremental or change-data-capture loads, idempotent merges keyed on a business ID, handling schema drift, and masking personal data before it leaves the bank's systems.
Deliverable: An infrastructure diagram with failure domains, an authentication flow with token checks listed, written answers on integration and a past integration, and a one-page warehouse load outline.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06AI platform design and front-end architecture
- Design the multi-tenant, self-hosted AI agent platform end to end: control plane, framework adapters, run queue, state store, model gateway, tool permissions, isolation options and audit logging.
- Outline a retrieval-augmented system: vector store choice and why, chunking, permission filtering, prompt pattern and an evaluation set.
- Write the React and React Native state management answer: kinds of state, navigation, shared component library and token handling.
Deliverable: An agent platform design diagram with trade-offs noted, a retrieval design one-pager, and a written front-end architecture answer.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral stories and panel rehearsal
- Write four stories told in "I": a project built from scratch, influencing stakeholders without authority, a cross-functional disagreement, and a production deployment that went wrong.
- Rehearse each aloud, then answer the follow-ups listed under each question in this guide.
- Run a mock panel: one system design from day 5 or 6, one deep dive into a past project, and two behavioral questions back to back.
Deliverable: Four written and recorded stories with measured results, and notes from a full mock panel on what to tighten.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report behavioral questions on career history, project execution and collaboration, and say many panels weight behavioral fit and decision-making alongside technical depth. For this role, prepare stories about building systems end to end, persuading people you do not manage, resolving disagreements with product, security or infrastructure partners, and handling production failures, each with your own actions and a measured result.
How do you handle CI/CD pipelines, automated testing, and release management in a containerized environment?
How do you handle CI/CD pipelines, automated testing, and release management in a containerized environment?
Approach
- Walk the pipeline in order: lint and unit tests, build the container image once, tag it with the commit SHA, scan it for vulnerabilities, run integration tests against real dependencies in containers, push to a registry such as ECR, then promote the same immutable image through staging to production.
- Explain why the artifact is built once: what you tested is exactly what you ship, and rollback means redeploying a previous tag. Keep secrets out of the image and inject them at runtime from a secrets manager.
- For deployment to ECS or Fargate, compare rolling updates with blue/green and say which you used and why. Keep infrastructure changes in Terraform with plan output reviewed in the merge request, for example in GitLab CI.
- Release management: trunk-based development with feature flags or release branches, semantic versioning, generated changelogs, and an approval and audit trail of who deployed what and when, which matters in a regulated setting.
- Address pipeline health: test pyramid so most tests are fast, quarantining flaky tests with an owner, caching dependency layers to keep builds quick.
Follow-up
- Your pipeline takes too long and engineers batch changes to avoid it. What do you change first?
- Where do database migrations run in this pipeline, and what happens if one fails halfway?
- How would an auditor confirm that a given production image passed every required check?
Can you describe your experience with DevOps practices and how you ensure high availability and observability
Can you describe your experience with DevOps practices and how you ensure high availability and observability in production?
Approach
- Answer with a system you ran, not a list of practices: name the service, its traffic shape, and the availability target you held it to (an SLO with an error budget, and what the budget was used for).
- Availability measures: multiple availability zones behind a load balancer with health checks, stateless services with autoscaling, managed data stores with standby replicas and tested backups, timeouts and retries with jitter on every outbound call.
- Observability: structured logs with a request or trace ID, metrics per service using rate, errors and duration, distributed tracing (for example OpenTelemetry) across service hops, and alerts on user-facing symptoms with a runbook linked from each alert.
- Give one concrete outcome: an incident that your alerting caught early, or a noisy alert you removed, with the before and after (pages per week, time to detect).
- Mention the operating habits that keep it working: on-call rotation, blameless postmortems, and action items that are tracked to completion.
Follow-up
- Which SLO did you set for that service and how did you pick the number?
- Tell me about an alert that fired too often. How did you fix it?
- How did you test that failover to another zone actually worked?
Tell me about a time when you had to influence technical or executive stakeholders without having direct autho
Tell me about a time when you had to influence technical or executive stakeholders without having direct authority over them.
Approach
- Pick a case that fits the work candidates report for this role: driving cross-team adoption of a shared platform or component library, taking a design to an architecture review board, or persuading security or risk partners to accept a change in a regulated setting.
- Show you understood the other side first: what they cared about (deadlines, risk, cost, audit exposure) and why they resisted.
- Bring the evidence each audience needs: for an architecture review board, a written comparison of options and a risk assessment; for security or risk partners, a control mapping that shows which requirement each safeguard meets; for teams asked to adopt a shared platform, a pilot's metrics such as migration effort, defects avoided or time saved.
- Give the outcome and what it led to, honestly, including partial wins. Say how the relationship stood afterwards.
- Avoid stories where you won by escalating over someone's head or by persistence alone; the answer needs persuasion through evidence and their interests.
Follow-up
- What would you have done if they had still said no?
- Which argument actually changed their mind?
- How did you handle the executive who had the least time for detail?
How do you handle disagreements with cross-functional team members regarding technical direction or project sc
How do you handle disagreements with cross-functional team members regarding technical direction or project scope?
Approach
- Choose a real disagreement with a product manager, designer, security or infrastructure partner about technical direction or scope, where both sides had a reasonable case.
- Explain how you moved it from opinion to criteria: agreeing on the goal, writing down the options with costs and risks, and separating reversible decisions (try it and measure) from irreversible ones (deliberate more).
- Show listening: what you learned from their side that changed your position, even partly.
- State how it was decided and what you did after the decision, including committing to a choice you had argued against if that happened.
- Avoid a story where the other person was simply wrong; it reads as poor collaboration.
Follow-up
- What did you concede, and was it the right call in hindsight?
- How did you handle it when the disagreement came back later?
- What would you do if the decision went against what security required?
Can you share an experience where a production deployment went wrong and how you managed the incident and reme
Can you share an experience where a production deployment went wrong and how you managed the incident and remediation?
Approach
- Set it up quickly: what the deployment changed, how the problem was detected (alert, customer report) and the user impact in concrete terms.
- Show the incident sequence: assess blast radius, mitigate first (roll back, turn off a feature flag, scale out) before root-causing, communicate status to stakeholders on a fixed rhythm, then confirm recovery with metrics.
- Root cause and remediation: a blameless postmortem, the actual cause, and the process gap that let it through (missing test, no canary, migration not backward compatible).
- Prevention with follow-through: the specific changes you made and evidence they worked, such as a later release that the new check caught.
- Avoid blaming a teammate, hiding your own part in the failure, or stopping at the rollback with no lasting fix.
Follow-up
- Why did your pre-release checks not catch it?
- How did you decide between rolling back and fixing forward?
- What did you tell non-technical stakeholders while it was ongoing?
Why are you excited to build your career in financial technology with Ally Financial, and how do your values a
Why are you excited to build your career in financial technology with Ally Financial, and how do your values align with ours?
Approach
- Research the company yourself before the call: read the consumer and commercial product pages on its public website and its technology or careers pages, and note two product surfaces you have used or can describe in detail.
- Link one product surface to the work candidates report for this role, for example a shared React Native component library used across the mobile and web channels, or AWS platforms and enterprise integrations behind account servicing, and say which problem in that work you would want to own.
- Connect it to your own history: a problem you solved that resembles this work, and why building software under security and regulatory constraints interests you.
- For the values half, pick one or two values you can prove with a short example (for example caring about correctness in money-moving code, or raising a security concern that delayed a release) instead of listing adjectives.
- The mistake to avoid is a generic answer that would work for any bank; name at least one concrete product surface and one concrete piece of this role's work.
Follow-up
- What do you know about the products this team supports?
- Tell me about a time your values cost you something at work.
- Where do you want to be technically in a few years, and how does this role get you there?
- 01
Can you describe a complex project you built from scratch and walk through your specific contributions and architectural choices?
- 02
Tell me about a time when you had to influence technical or executive stakeholders without having direct authority over them.
- 03
How do you handle disagreements with cross-functional team members regarding technical direction or project scope?
- 04
Can you share an experience where a production deployment went wrong and how you managed the incident and remediation?
- 05
Tell me about a time you had to convince a skeptical stakeholder or team to adopt a new architectural standard or framework.
- 06
Describe a situation where a technical disagreement arose within your team and how you drove the group toward a consensus.
How many rounds are there and how long does the process take?
Candidates report four rounds over roughly three to five weeks: a Recruiter Screening Call, a Technical Screen, Technical Assessments and Panel Interviews. They also report that stages vary by team, location and seniority, so confirm the exact sequence with your recruiter in the first call.
Ally Financial Software Engineer candidate reports ↗What is the Technical Screen like?
Candidates describe a first technical stage that may be an assessment or a video assessment with set prompts about your work and how you solve problems. Ask which format you will get. For a video assessment, practise answering written prompts in one take with a clear structure: context, what you did with named tools, and the result.
PracHub Software Engineer practice ↗Which topics should I prepare?
Candidates list Python, SQL, coding challenges, code explanation and communication of technical work, and SDLC knowledge. The reported questions add delivery practice (CI/CD, observability, tech debt), FastAPI and asyncio, React and React Native, Okta OIDC and JWT, AWS serverless and containers, and design questions on an AI agent platform, fault tolerance and retrieval-augmented systems.
Ally Financial Software Engineer candidate reports ↗Do I need both Python backend and React skills?
The requirements candidates describe give Python with async frameworks or advanced TypeScript with React and React Native as examples, alongside AWS, CI/CD, containers and cloud security, and some roles centre on platform integration. Go deep on your own track and prepare enough on the other to discuss it sensibly, since the reported questions span both.
PracHub Software Engineer practice ↗How much AI and agent experience do I need?
Candidates list AI agent frameworks (LangGraph, the OpenAI SDK, Autogen) and vector databases as nice-to-haves, not must-haves, but reported design questions include a self-hosted multi-tenant agent platform and vector database selection with retrieval augmentation. Prepare one design for each, with tenancy, permissions, evaluation and audit logging covered.
PracHub Software Engineer practice ↗What experience level is the role aimed at?
The requirements candidates describe ask for around five years of professional software engineering, and seven or more for senior and principal tracks, which also carry more emphasis on platform architecture and cross-team leadership. Pitch your design and leadership stories to the level you are applying for.
PracHub Software Engineer practice ↗Is the role remote, hybrid or on-site?
Candidates report hybrid or on-site arrangements depending on team and business unit, with office hubs such as Charlotte, North Carolina and Detroit, Michigan mentioned. Ask about the specific team's arrangement in the recruiter call.
Ally Financial Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Ally Financial Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Veem Software Engineer Interview Guide
What Veem asks Software Engineer candidates, from reported rounds and questions.
Sorint.SEC Software Engineer Interview Guide
What Sorint.SEC asks Software Engineer candidates, from reported rounds and questions.
Raytheon Technologies Corporate Headquarters Software Engineer Interview Guide
What Raytheon Technologies Corporate Headquarters asks Software Engineer candidates, from reported rounds and questions.
NeuroFlow Software Engineer Interview Guide
What NeuroFlow asks Software Engineer candidates, from reported rounds and questions.