Advent Infotech Software Engineer Interview Guide

The 60-second brief

Candidates describe the Software Engineer title at Advent Infotech as covering several different jobs: Java full stack developer, cloud engineer on AWS, Azure or Oracle, or a specialist such as a Mulesoft developer. The work is described as client infrastructure and digital transformation projects aimed at the North American market, with the engineer turning a client's requirements into working software or cloud setups.

This guide is for candidates interviewing for a Software Engineer position at Advent Infotech, whichever stack the posting names. It covers the two reported rounds, the five questions candidates report (web languages, React.js, relational versus non-relational databases, Java full-stack experience and cloud-native design on AWS or Azure), and the design and troubleshooting topics reported for more senior roles.

Candidates report two rounds over roughly 2-4 weeks: a Screening Call with a recruiter, then Technical Evaluations focused on the stack of the role, such as cloud, Java or networking.

Focus areas

• React.js
• Relational Databases
• Non-Relational Databases (NoSQL)

Overview

The first thing to settle is which job you are interviewing for. Candidates describe the Software Engineer title covering Java full stack work, cloud engineering on AWS, Azure or Oracle, and specialist roles such as Mulesoft development, and the technical evaluation follows the stack on the posting. Read the posting, list every technology it names, and prepare those in depth instead of spreading your time thinly across all of them.

The day-to-day work candidates describe is coding, debugging and integrating components, keeping documentation, taking part in code reviews, and sometimes moving legacy systems onto cloud platforms. Requirements candidates mention include proven experience in your main stack, clear written and spoken communication, and flexibility about project location. Docker, Kubernetes, CI/CD pipelines and consulting experience are described as nice to have. Each of these is something you should be able to illustrate with a project of your own.

The reported questions are experience-led: which languages you have used in web development, how extensive your React.js experience is, how relational and non-relational databases differ, what your Java full-stack experience looks like, and how you would design a cloud-native architecture on AWS or Azure. None of them has a single correct answer, so the preparation is to attach a real project, a decision and a trade-off to every one. Candidates also report React.js and relational databases as common areas of interest.

For more senior roles, candidates report design questions about handling high-concurrency requests and troubleshooting a bottleneck in a distributed system. Prepare a repeatable sequence for both: how you would measure, where you would look first, and what you would change. The recruiter screen is reported to cover background, English proficiency and logistics such as relocation to the United States, so settle your own position on those before the call.

The Advent Infotech interview process

Candidates describe a short two-stage process: a recruiter call first, then technical evaluations that follow the stack of the role. These are candidate reports, not a published process.

Screening Call

Candidates report a call with a recruiter that covers your background, your language proficiency (often including English) and logistics, such as willingness to relocate to the United States. Treat it as the first test of how clearly you can describe your experience. Have a short account of your career that points at the stack on the posting, and a settled answer on location and availability.

What to demonstrate

• How well your background matches the stack named on the posting
• Spoken language proficiency, often including English, when you discuss technical work
• Whether your logistics, such as relocation, fit the role

How to prepare

• Write a two-minute career summary that ends on the exact stack of the posting, for example Java and Spring, AWS or Azure, or Mulesoft.
• Decide your position on relocation, project locations and start date before the call, and state it plainly.
• Practise explaining one project aloud in English, covering the problem, your part, the technologies and the result, without reading from notes.
• Have your own dates, titles and technologies ready so that every item on your resume can be explained in a sentence or two.

Technical Evaluations

Candidates report technical evaluations aimed at the stack of the role, such as cloud, Java or networking. For Java roles the reported emphasis is the Spring ecosystem; for cloud roles it is service orchestration, security, deployment and cost on AWS or Azure. For more senior roles, candidates also report design questions about high-concurrency requests and troubleshooting a bottleneck in a distributed system. Be ready to explain why you chose a technology as well as what you built with it.

What to demonstrate

• Depth in the core language or platform the posting names
• The reasoning behind technology and architecture choices, including trade-offs
• For more senior roles, designing for concurrency and troubleshooting distributed systems

How to prepare

• For a Java role, be able to trace one request through controller, service and repository layers in Spring and explain where transactions begin and end.
• For a cloud role, rehearse an AWS or Azure reference architecture for a web app: network layout, access control, deployment path, cost drivers. If the posting names Oracle cloud, map each piece to OCI: VPC/VNet to VCN, EC2/VMs to Compute, EKS/AKS to OKE, S3/Blob to Object Storage, RDS/Azure SQL to Autonomous Database, IAM roles to OCI IAM policies and compartments.
• If the posting names Mulesoft, prepare one API-led connectivity example (system, process and experience APIs), a RAML spec you wrote, a DataWeave transform you can explain line by line, and how a flow handles errors with On Error Continue versus On Error Propagate.
• Rehearse a bottleneck investigation in order: measure latency and error rates, find the saturated resource, check the database and downstream calls, change one thing, measure again. If networking is on the posting, use a real case: the symptom, what you checked first, the root cause.

Where candidates lose points

Answering the web languages question with a bare list of languages

Pair each language with a project, the role it played and why it was chosen. A short table of language, project and reason, prepared in advance, turns a list into evidence.

Claiming Java full-stack experience but being unable to trace one request from the browser to the database

Sketch the path for a real project, from React component to controller, service, repository and table, and mark the transaction boundary and where validation and errors are handled. Rehearse it aloud.

Contrasting relational and non-relational databases with generalities such as 'NoSQL scales better'

Argue from access patterns, consistency needs, schema change and query shape, and give one example where you chose each type, including what you gave up.

Listing cloud services in the cloud-native design question with no reasoning about security, cost or failure

Choose AWS or Azure, then walk through network layout, identity and access, deployment, scaling, monitoring and the main cost drivers, and name what breaks first under load.

Going into the recruiter call vague about relocation, location flexibility or spoken English

Decide your answers on relocation and availability beforehand, state them plainly, and practise discussing technical work aloud in English so the call goes smoothly.

Questions & practice

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

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

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

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

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

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

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

What programming languages have you utilized in web development?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Answer by layer instead of listing names: browser (JavaScript or TypeScript, with React.js if you have used it), server (for example Java with Spring Boot), and data (SQL). For each language, name one project and the part you built in it.
2. Say why each language fit the job. For example: 'I used TypeScript on the React client because its static types caught API contract mismatches at compile time. The types are erased at build, so the runtime is still plain JavaScript.'
3. Have one runtime detail ready for each language you claim. In JavaScript, after each task the event loop drains every queued promise callback (microtask) before it takes the next timer or I/O task. In Java, the JVM runs real threads, so shared state needs synchronization or concurrent collections.
4. Say how the layers talked to each other: REST or JSON endpoints, how request and response shapes were kept in sync, and where validation ran (on the server, always, even when the client also checks).
5. Be honest about depth. Separate languages you have shipped to production from ones you have only read or tweaked, so every claim on your CV holds up under a follow-up.

Follow-up

• If one script schedules Promise.resolve().then(a) and setTimeout(b, 0), which callback runs first, and why?
• How did your Java back end and your JavaScript front end stay in agreement when an API field changed?
• If you had to rewrite that project's server in a different language, which one would you pick, and what would you gain or lose?

What are the primary differences and use cases for relational databases versus non-relational databases?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Start with the data model. Relational databases store normalized tables with a fixed schema, use SQL joins, and give ACID transactions across rows and tables. Non-relational stores come in four families with different models: key-value (Redis, DynamoDB), document (MongoDB), wide-column (Cassandra) and graph (Neo4j).
2. Explain the scaling and consistency trade-off. A relational database usually scales up first, then adds read replicas; sharding it takes application or extension work. DynamoDB and Cassandra partition by key natively, but MongoDB needs a sharded cluster with a chosen shard key, and Redis needs Cluster mode. Many NoSQL stores offer tunable or eventual consistency; Cassandra lets you pick ONE, QUORUM or ALL per query.
3. Avoid the outdated claim that NoSQL has no transactions. MongoDB added multi-document ACID transactions in 4.0 on replica sets and extended them to sharded clusters in 4.2, and DynamoDB has TransactWriteItems. The practical difference is that they are scoped and cost more, and the data model is not built around them.
4. Choose from access patterns. If you need ad-hoc queries, reporting, joins and strong invariants (orders, payments, inventory), go relational. If you have known key-based lookups at high write volume, or records whose attributes vary (sessions, event logs, product catalogs with different attributes per item), a NoSQL store fits. Design the NoSQL schema around the queries, which means denormalizing.
5. Mention the middle ground. PostgreSQL JSONB keeps semi-structured fields inside a relational schema, and many systems use both kinds of store: relational as the source of truth, plus a cache or search store for hot reads.

Follow-up

• How would you model orders and their line items in a document store, and when would you embed the items rather than reference them?
• With an eventually consistent store, how do you make sure a user sees their own write right after saving it?
• Your PostgreSQL database has outgrown a single node. What do you try, and in what order?

How do you approach designing a cloud-native architecture in AWS or Azure?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Fix the requirements before naming services: request volume and its peaks, latency target, availability target, data size and retention, compliance limits and budget. Then pick the compute model: containers (ECS/EKS on AWS, AKS or Container Apps on Azure) for long-running services, or functions (Lambda, Azure Functions) for event-driven, spiky work.
2. Keep services stateless behind a load balancer (Application Load Balancer, or Azure Application Gateway) with health checks and autoscaling. Move state into managed services: a relational database (RDS/Aurora or Azure SQL Database), a NoSQL store (DynamoDB or Cosmos DB), object storage (S3 or Blob Storage) and a Redis cache.
3. Decouple slow or failure-prone work with a queue (SQS/SNS or Azure Service Bus). Standard SQS delivery is at-least-once, so consumers must be idempotent, and repeated failures should go to a dead-letter queue. Retry calls between services with exponential backoff and jitter.
4. Design for failure and security together. Deploy across multiple availability zones, put databases in private subnets or VNets, give each service a least-privilege IAM role or managed identity, keep secrets in Secrets Manager or Key Vault, and encrypt data at rest and in transit.
5. Finish with operations and cost. Use infrastructure as code (Terraform, CloudFormation or Bicep), a CI/CD pipeline with blue-green or canary releases, and metrics, logs and traces in CloudWatch or Azure Monitor. Control cost with right-sizing, autoscaling to demand, reserved capacity or savings plans for the steady baseline, and storage lifecycle rules.

Follow-up

• How would the design change if the service had to survive the loss of an entire region, not just one availability zone?
• A queue consumer processed the same payment message twice. How do you make that safe?
• Traffic grows tenfold and the monthly bill grows with it. Where do you look first to bring cost down?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

1. Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
2. Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
3. Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
4. Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

• The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
• Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

The seven days follow the two reported rounds and the five reported questions: recruiter screen first, then Java, React, databases, cloud design and troubleshooting, then a full mock.

Day 1 — Map the posting and prepare the screening call

• List every technology named in the posting and mark which stack it belongs to: Java full stack, cloud on AWS, Azure or Oracle, Mulesoft or networking.
• Write a two-minute career summary ending on that stack, and a plain statement of your position on relocation, project location and availability.
• Mark the three items on your resume you are least able to explain in two sentences.

Deliverable: A one-page sheet with the posting's stack, the written career summary, the relocation statement and the three weak resume items.

Day 2 — Java full-stack experience

• Sketch the request path of one project you built, from front end to controller, service, repository and database, and mark transaction and validation points.
• Write short answers on Spring dependency injection, @Transactional behaviour and N+1 queries.
• Answer aloud, recorded: Can you explain your experience with Java full-stack development?

Deliverable: A labelled request-path diagram, three written Spring answers and one recorded spoken answer.

Day 3 — Web languages and React.js

• Make a table of every language you used in web development, with the project and the reason you chose it.
• Build or review a small React component that fetches data, shows loading and error states, and cancels the request on unmount.
• Answer aloud, recorded: How extensive is your experience with React.js? Use one project with a bug you fixed.

Deliverable: The language table, a working fetch component and a recorded answer to the React question.

Day 4 — Relational versus non-relational databases

• Write a comparison grid of relational and non-relational stores covering access pattern, consistency, schema change and scaling, with one example from your work for each.
• Answer aloud: What are the primary differences and use cases for relational databases versus non-relational databases?

Deliverable: A filled comparison grid with two examples, worked solutions to the two SQL practice questions and a recorded spoken answer.

Day 5 — Cloud-native design and troubleshooting

• Choose AWS or Azure and sketch a reference architecture for a web app with a React front end, a Java API and a relational database, adding network layout, access control, deployment path and cost drivers.
• Write your bottleneck-investigation sequence for a distributed system, from measurement to the change you would make.

Deliverable: An annotated architecture sketch, a written troubleshooting sequence and the debugging practice answer.

Day 6 — Concurrency and communication

• Answer aloud: a Spring Boot API on AWS behind an Application Load Balancer, backed by RDS, gets a spike of concurrent requests. Cover HikariCP pool size against the database connection limit, timeouts and circuit breakers on downstream calls, rate limiting, idempotency keys for retried writes, and backpressure through a queue.
• Prepare two stories: a technology choice with its trade-offs, and a complex issue you troubleshot. Write each as situation, decision, outcome.

Deliverable: A spoken concurrency answer covering the five mechanisms, two written stories and a response to the practice question.

Day 7 — Full dry run

• Run a mock recruiter call, then answer all five reported questions aloud back to back, in English, without notes.
• Review your recordings and fix the two weakest answers.
• Write the questions you want to ask the recruiter about the stack, project location and next steps.

Deliverable: A completed mock, a list of two answers revised and a list of questions for the recruiter.

Experience and background questions

Candidates report that the recruiter call checks your background, English and logistics, and that the technical stage asks about your experience and your reasons for technical choices. For this role that means telling project stories in which you made the decision, can explain the trade-offs and can describe the work in plain terms to non-technical stakeholders.

1. Walk me through your background and why this role fits your goals, including your readiness to relocate.
2. Tell me about a time you chose between two technologies. What trade-offs did you weigh?
3. Describe a complex system issue you troubleshot. How did you narrow it down?
4. Tell me about explaining a technical decision to a non-technical stakeholder.

How extensive is your experience with React.js?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Start with a scoped summary in one or two sentences: how long you have used React, whether on function components with hooks or on older class components, and the kind of application. Then go deep on one project rather than listing features.
2. Be ready to defend the mechanics: state versus props, useState versus useReducer, useEffect dependency arrays and cleanup functions, stable keys in lists, controlled form inputs, and when to lift state, use context or use an external store.
3. Know the re-render rule exactly: a component re-renders when its own state changes, when a context it reads changes, or whenever its parent re-renders, even if its props did not change. React.memo limits re-rendering to prop changes with a shallow comparison, and useMemo and useCallback keep prop identities stable so that comparison works. Apply them where the React DevTools Profiler shows wasted renders, and quote one real case.
4. Tie the front end to a back end: loading and error states, cancelling a stale request in the effect cleanup with AbortController, where the auth token lives, and how CORS was configured. This connects the answer to full-stack work.
5. Name one bug you diagnosed, such as a stale closure or an effect that looped, and how you found it. State plainly what you have not used. The answer that sinks is a claim of broad experience with no project behind it, or libraries you cannot explain.

Follow-up

• When does a React component re-render, and how would you stop an unnecessary re-render?
• A user leaves a page while its API request is still in flight. What can go wrong and how do you handle it?
• How would you structure state for a multi-step form that submits to a Java back end?

Can you explain your experience with Java full-stack development?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Trace one request end to end for a project you built: React or another front end calls a REST controller, which calls a service layer, which calls a repository over a relational database, and a JSON response returns. Say which layers you personally owned.
2. Show Spring knowledge you can defend: dependency injection, Boot starters and auto-configuration, DTOs versus entities, bean validation, central error handling with @ControllerAdvice, and transaction boundaries with @Transactional. Know that by default it rolls back on unchecked exceptions, and that a call to another method in the same class bypasses the proxy.
3. Cover persistence honestly: JPA or Hibernate mappings, lazy loading and the N+1 query problem fixed with a fetch join or entity graph, pagination, indexes, and how schema changes were applied. Only name tools you actually used.
4. Describe delivery: Maven or Gradle builds, JUnit and Mockito tests, authentication such as Spring Security if you used it, and how the application reached an environment, with CI/CD, Docker or a cloud platform if that is part of your history.
5. Frame it as a story with a decision: the goal, your responsibility, one trade-off such as a monolith versus separate services or REST versus messaging, and the outcome. Say 'I' for your work. The mistake that sinks it is a technology list with no ownership.

Follow-up

• What happens when a @Transactional method is called from another method in the same class?
• You see one request firing hundreds of SQL statements. How do you confirm it is N+1 and fix it?
• How would you secure the endpoint the React app calls, and what CORS configuration does it need?

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

• How would you detect a consumer that reads the field only during a monthly export?
• One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?