cswork / libraryOpen practice workspace

Interview guides · Ayush Technologies

Ayush Technologies Software Engineer Interview Guide

Ayush Technologies Software Engineer interview guide: five reported rounds, Java, OOP, React, DSA and project questions, plus a 7-day prep plan.

The 60-second brief

Candidate-reported descriptions of the Software Engineer role at Ayush Technologies say it covers designing, building and maintaining software systems that often intersect with healthcare, wellness or other specialised, domain-specific platforms. No specific product is named in those reports, so do not guess one in the loop. The same descriptions list day-to-day work such as turning requirements from product managers and operations staff into technical specifications, writing and reviewing code, debugging production issues and tuning performance. They also mention keeping up with AI, machine learning and cloud platforms, and a hybrid working arrangement. Two of the reported questions ask directly about a healthcare or AYUSH project and about data sensitivity and compliance in design, so expect the domain to be part of the conversation.

This guide is for candidates preparing for the Software Engineer loop at Ayush Technologies. It covers the five reported rounds, the fifteen reported questions (Java and OOP fundamentals, pointers, React components, variable scope, linked lists and arrays, sorting complexity, Dijkstra, debugging, a healthcare or AYUSH project, compliance, time management and personal questions), and a seven-day plan. It does not cover other roles at the company.

Candidates report five rounds over about 4-6 weeks: Initial Screening, Technical Assessments, Behavioral Interviews, Feedback Session and Final Offer.

Focus areas

  • Data Structures & Algorithms (DSA)
  • Core Java
  • React (Front-End Fundamentals)

Overview

Reported descriptions place this Software Engineer role across the whole development lifecycle: turning product and operations requirements into technical specifications, writing and reviewing code, debugging production issues and tuning performance. The systems are described as often touching healthcare, wellness or other specialised domains. That explains why the reported questions mix classic computer science fundamentals with a healthcare or AYUSH project question and a question about data sensitivity and compliance.

The requirements candidates describe name Java or C/C++, data structures and algorithms, and experience with databases. React or another frontend framework, a cloud platform (AWS, Azure or GCP) and exposure to healthcare data standards are listed as extras. The technical areas reported for the assessment are core Java (constructors, memory management, class structure), React state and component lifecycle, DBMS, operating systems and networking basics, arrays, linked lists and pointers, sorting, searching and graph problems, and debugging. Most of the fifteen reported questions are technical: the core features of Java, the four pillars of OOP, pointers and their types, functional versus class components in React, local versus instance variables, a linked-list or array solution, sorting complexity and Dijkstra. The rest cover debugging, a healthcare or AYUSH project, compliance, time management and personal questions.

Candidates are told to explain why a technology or algorithm fits a situation, not to recite definitions. For this loop, that means every fundamentals answer should have three parts: the definition, a short code or example in Java, and a trade-off or failure case. Practise coding without an IDE, because the reported assessment includes writing code in a live environment and stating its complexity.

On timing, reports say five rounds over about 4-6 weeks, although one passage describes the whole process finishing within one to two weeks. Treat the longer figure as the planning number and ask the recruiter for the actual schedule after the first conversation.

The Ayush Technologies interview process

These are the stages candidates report, in the order they list them. Which reported question is asked in which stage is not published, so prepare the technical and the project and personal question types for the stages that cover them.

Initial Screening

Candidates report an initial screening meant to establish your background and fit for the role. No specific questions are tied to it, but the personal questions reported for this loop (an introduction and your career goals) are the natural material, along with a quick account of the languages and projects you would claim. Treat it as the first place your stack has to sound consistent with your CV: Java or C/C++, data structures, databases and, if you have it, React or cloud work.

What to demonstrate

  • Your background and fit for the role, as the stage is described
  • How clearly you summarise your own projects and skills
  • Whether your stated stack matches the Java or C/C++, DSA and database requirements candidates describe

How to prepare

  • Write a short introduction that names your current work or studies, two projects with their stack, and why this role. Rehearse it until it sounds spoken, not read.
  • Write one sentence per project: what it did, what you built, and the hardest problem you solved in it.
  • Prepare a concrete answer to the career goals question that connects to backend, frontend or domain skills you are building.
  • List the requirement keywords (Java or C/C++, DSA, DBMS, React, cloud) and note one piece of evidence for each that you actually have.

Technical Assessments

Candidates report technical assessments covering coding and domain knowledge, including structured coding assessments and writing code in a live environment while explaining complexity. The reported technical areas are core Java (constructors, memory management, class structure), React state and component lifecycle, DBMS, operating systems and networking basics, arrays, linked lists and pointers, sorting, searching and graph problems, and debugging. This is the stage where the fundamentals and coding questions in this guide are practised. Approach it by explaining the reasoning behind each choice, not only the final code.

What to demonstrate

  • Working code written live, with its time and space complexity stated
  • Core Java, OOP and React fundamentals, including why one approach fits better than another
  • Data structures (arrays, linked lists), sorting and graph algorithms
  • Basic DBMS, operating system and networking knowledge

How to prepare

  • Write singly linked list operations (insert, delete a node, reverse, find the middle) and an array problem in Java without an IDE, then state the complexity of each.
  • Build a table of sorting algorithms with best, average and worst time, extra space and stability, and say when you would choose each.
  • Implement Dijkstra with a priority queue on an adjacency list and be ready to explain why negative edge weights break it.
  • Rehearse spoken answers on the four pillars of OOP, local versus instance variables, pointers and their types, and functional versus class components in React, each with a small example.

Behavioral Interviews

Candidates report behavioral interviews that discuss your past experiences and cultural fit. The reported questions that fit this format are the project and personal ones: a healthcare or AYUSH project, handling data sensitivity and compliance in designs, managing time on a hard technical problem, handling a difficult bug, and criticism and weaknesses. Reports recommend structuring answers with Situation, Task, Action, Result and being honest when you lack experience in an area.

What to demonstrate

  • How you describe your own past projects and the decisions you made in them
  • How you reason about constraints such as data sensitivity and compliance
  • Communication and teamwork as discussed through your experiences

How to prepare

  • Prepare three project stories in Situation, Task, Action, Result form, each with a decision you personally made and a result you can state.
  • Build one story about a hard bug: how you isolated it, what you changed and how you recorded the fix for the team.
  • Write down the data-handling decisions in your best project (what was sensitive, who could see it, what was logged) so the compliance question has real content.
  • If you have no healthcare project, choose the closest one (payments, student records, any personal data) and plan an honest way to say so.

Feedback Session

Candidates report a feedback session in which you receive feedback on how the earlier interviews went. Nothing more is reported about its format, so use it as an opportunity rather than a test: listen to the points raised, ask what a stronger answer would have looked like, and take notes. The weaknesses and constructive criticism question reported for this loop is good rehearsal for it.

What to demonstrate

  • Hearing feedback on your performance in the earlier rounds
  • How you respond to criticism and follow up on it

How to prepare

  • After each earlier round, write down the two questions you answered least well so you can ask about them directly.
  • Prepare two or three questions about what a stronger answer in your weakest area would include.
  • Rehearse a calm, specific response to a critical comment: restate it, ask one clarifying question, say what you would change.

Final Offer

Candidates report a final stage that is a discussion of the job offer and its terms. No further detail is reported. Treat it as a conversation to confirm what you have been offered and what the role involves, using what you learned in the earlier rounds about the team and the work.

What to demonstrate

  • The offer and its terms
  • Your questions about the role, the team and the working arrangement

How to prepare

  • Write the terms you want to confirm in writing: role and team, the hybrid working arrangement described for the role, start date and anything about training.
  • Prepare questions drawn from the loop itself, such as how code review works, how production issues are handled and how healthcare or compliance requirements show up in day-to-day work.
  • Decide in advance what you need from the recruiter in writing before accepting.

Where candidates lose points

Reciting the four pillars of OOP or the core features of Java as dictionary definitions

Give each pillar a three-line Java example and one reason it matters, such as how polymorphism lets a caller depend on an interface. Do the same for the Java features you cite (platform independence, garbage collection, the JIT compiler) and say what each costs or enables.

Giving sorting complexities as a memorised list with no conditions

For each algorithm state best, average and worst time, extra space and stability. Say why quicksort's worst case happens, when insertion sort wins on nearly sorted input, and why merge sort is preferred when stability or linked lists matter.

Writing Dijkstra's algorithm without its limits or its data structure

Implement it with a priority queue and state the complexity. Say it requires non-negative edge weights, explain how you skip stale queue entries, and name what you would use instead (Bellman-Ford) for negative weights.

Answering the pointers question only in C terms, or ignoring references when you work in Java

Name the types (raw, null, void, dangling, wild, function and smart pointers) and explain the dangerous ones. Then contrast with Java references, which cannot be dereferenced arbitrarily or incremented, and tie it to linked-list node handling.

Describing a healthcare, AYUSH or compliance project in generalities, or claiming experience you cannot back up

Prepare concrete details: what data was sensitive, who could access it, what was logged and encrypted, and what you would change. If your project is not in healthcare, say so and describe the closest analogue honestly.

Questions & practice

What are pointers, and can you name their different types?

Medium · Technical Foundations & Core Concepts

Approach

  1. Define a pointer as a variable that holds a memory address. Show declaration, address-of and dereference in C (int *p = &x; *p = 5;). Explain that p + 1 advances by sizeof(*p) bytes, not by one byte.
  2. List the types usually asked about. Null pointer: points nowhere, and dereferencing it is undefined behaviour. Void pointer: generic, so it must be cast before dereferencing. Wild pointer: never initialised. Dangling pointer: points to freed or out-of-scope memory. Also cover function pointers and pointer-to-pointer (int **), and mention near, far and huge only as old 16-bit compiler terms.
  3. Explain const placement: const int *p means the pointed-to value is read-only, while int *const p means the pointer itself cannot be reseated.
  4. For C++, cover smart pointers. unique_ptr gives sole ownership and frees on scope exit. shared_ptr is reference-counted. weak_ptr observes without owning and breaks shared_ptr cycles. Contrast with Java references, which allow no pointer arithmetic, are garbage-collected, and throw NullPointerException instead of undefined behaviour.

Follow-up

  • How does a dangling pointer arise, and what habits or tools prevent it?
  • Why does sizeof give different results for an array and for a pointer to its first element?
  • What goes wrong when two shared_ptr objects reference each other, and how do you fix it?

Can you implement a solution using linked lists or arrays?

Medium · Coding & Problem Solving

Approach

  1. First ask which operation the problem needs, then pick the structure. Arrays give O(1) indexed access and good cache locality but O(n) insertion in the middle. A singly linked list inserts or deletes in O(1) once you hold the previous node, but reaching index i costs O(n).
  2. Know the core linked-list patterns cold. Iterative reversal uses prev, curr and next pointers: O(n) time, O(1) space. Floyd's slow/fast pointers detect a cycle or find the middle. Removing the n-th node from the end uses two pointers n apart. Merging two sorted lists uses a dummy head node so the head needs no special case.
  3. For array problems, name the matching technique. Two pointers for sorted pairs or in-place partitioning, a sliding window for subarray constraints, a prefix-sum array for range sums, and a hash map when you trade O(n) space for O(n) time.
  4. Test the edge cases out loud before you finish: an empty input, a single element, removing the head, even versus odd length when finding the middle, and a cycle that loops back to the head. Then state the time and space complexity of what you wrote.

Follow-up

  • After Floyd's algorithm detects a cycle, how do you find the node where the cycle starts, and why does that work?
  • How would you reverse a linked list in groups of k nodes?
  • In Java, when would you choose LinkedList over ArrayList, given cache behaviour and the cost of reaching a position?

How would you approach a challenging bug and document your resolution process?

Medium · Coding & Problem Solving

Approach

  1. Reproduce first. Get a reliable, minimal reproduction and record the exact inputs, environment and version. A bug you cannot trigger on demand cannot be proven fixed.
  2. Narrow it down with evidence, not guesses. Read the full stack trace and logs, check what changed recently, and bisect when a known-good version exists. git bisect finds the breaking commit in about log2(n) test runs. Change one variable at a time and write down each hypothesis and its result.
  3. Fix the root cause, not the symptom. Explain why the defect happened, then add a regression test that fails before the fix and passes after it.
  4. Document as you go so the write-up is just your notes tidied: symptom and impact, how to reproduce it, root cause, the fix and how you verified it, and what prevents a repeat (a test, an alert, a validation). Close with one real bug from your own work told in that order.

Follow-up

  • The bug only happens in production and never locally. What do you do next?
  • At what point do you ask a teammate for help, and what do you bring to that conversation?
  • How would you make sure the same class of bug does not come back?

Can you explain the time complexity of common sorting techniques?

Medium · Coding & Problem Solving

Approach

  1. Give the quadratic sorts with their best cases. Bubble sort is O(n^2), or O(n) on sorted input with an early-exit flag, and stable. Selection sort is O(n^2) in every case and not stable, but makes at most n-1 swaps. Insertion sort is O(n^2) worst case, O(n) on nearly sorted input, stable and in place.
  2. Give the O(n log n) sorts and their trade-offs. Merge sort is O(n log n) in all cases and stable, but needs O(n) extra space for arrays. Quicksort averages O(n log n) with O(log n) expected stack, is not stable, and degrades to O(n^2) with bad pivots, such as always picking the first element on sorted input. Heap sort is O(n log n) worst case with O(1) extra space, but is not stable and has poor cache locality.
  3. State the lower bound: any comparison sort needs Omega(n log n) comparisons in the worst case, because the decision tree must have n! leaves and log2(n!) grows as n log n. Counting sort runs in O(n + k) and radix sort in O(d(n + k)) because they do not compare elements.
  4. Link this to library sorts. Java's Arrays.sort uses dual-pivot quicksort for primitives and TimSort (stable, merge plus insertion) for objects, which Collections.sort also uses. Choose based on stability, memory limits, worst-case guarantees and whether the input is already nearly sorted.

Follow-up

  • Which sort would you use for a linked list, and why?
  • Why does stability matter when you sort records by a second key after sorting by the first?
  • How does randomised or median-of-three pivot selection change quicksort's worst case in practice?

How would you implement or explain the Dijkstra algorithm?

Medium · Coding & Problem Solving

Approach

  1. State the problem and its precondition: single-source shortest paths on a graph whose edge weights are all non-negative. Use BFS when the graph is unweighted and Bellman-Ford (O(VE)) when negative edges are possible.
  2. Describe the algorithm. Set dist[source] = 0 and every other node to infinity, and push (0, source) onto a min-heap. Repeatedly pop the smallest distance, skip the entry if it is stale (d > dist[u]), and relax each edge (u, v, w): if dist[u] + w < dist[v], update dist[v], record parent[v] = u and push (dist[v], v).
  3. Give the complexity. With a binary heap and lazy deletion it is O((V + E) log V). A simple array scan is O(V^2), which can win on dense graphs. A Fibonacci heap gives O(E + V log V) in theory.
  4. Explain why it is correct and when it fails. Once a node is popped with its smallest distance, no later path can be shorter, because every remaining path only adds non-negative weight. A negative edge breaks that guarantee. Cover the edge cases: unreachable nodes stay at infinity, parallel edges, self-loops, and stopping early when you only need one target.

Follow-up

  • Give a small graph with a negative edge where Dijkstra returns the wrong distance.
  • How do you rebuild the actual shortest path, not just its length?
  • How does A* change Dijkstra, and what property must its heuristic have to stay optimal?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

  1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
  2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
  3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
  4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

  • The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
  • How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

  1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
  2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
  3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
  4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

  • Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
  • Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

What are the core features of Java and how does it enable high performance?

Medium · Technical Foundations & Core Concepts

Approach

  1. Separate language features from runtime features. Language: static typing, classes and interfaces, checked exceptions, built-in threads and java.util.concurrent, no pointer arithmetic. Runtime: source compiles to bytecode that any JVM runs, which is where platform independence comes from.
  2. Explain where the speed comes from. HotSpot starts by interpreting bytecode, profiles which methods run most, and compiles them to native code with tiered C1/C2 JIT compilers. Profile data drives inlining, removal of devirtualised calls, and escape analysis, which can turn a short-lived object into stack or register values.
  3. Cover memory. A generational garbage collector (G1 has been the default since JDK 9) makes allocation cheap because most objects die young. The trade-off is GC pauses and a larger heap footprint than manual memory management.
  4. Name the costs honestly. JIT warm-up means early requests run slower, boxing in collections such as List<Integer> adds allocation and indirection, and synchronized sections limit throughput under contention. A strong answer explains why Java is fast after warm-up, not just that it is fast.

Follow-up

  • What is the difference between the JDK, the JRE and the JVM?
  • Why is String immutable in Java, and how does the string pool use that?
  • How does ahead-of-time compilation (for example a GraalVM native image) change startup time compared with the JIT?

Can you explain the four pillars of OOP?

Medium · Technical Foundations & Core Concepts

Approach

  1. Name all four pillars and give each a one-line Java example. Encapsulation: private fields behind methods that protect an invariant, such as a balance that can never go negative. Abstraction: callers depend on an interface or abstract class, not its implementation. Inheritance: a subclass extends a parent and reuses its behaviour. Polymorphism: one call site runs different code depending on the object's runtime type.
  2. Split polymorphism into its two forms. Overloading is resolved at compile time from the parameter types. Overriding is resolved at runtime through dynamic dispatch on the actual object. Point out that static methods are hidden, not overridden.
  3. Contrast abstract classes with interfaces. An abstract class can hold state and constructors. An interface can have default methods since Java 8, and a class can implement several interfaces but extend only one class.
  4. Show judgement as well as definitions: prefer composition when the 'is-a' relationship is weak, and check the Liskov substitution principle. The classic example is Square extending Rectangle and breaking callers that set width and height independently.

Follow-up

  • Why does Java not allow multiple inheritance of classes, and how do default methods handle the diamond problem?
  • Can you override a private or static method? What happens if you try?
  • Where did you use polymorphism in a past project instead of a chain of if/else type checks?

How do you differentiate between functional and class components in React?

Medium · Technical Foundations & Core Concepts

Approach

  1. Define both kinds. A class component extends React.Component, keeps state in this.state, updates it with this.setState (which shallow-merges), and uses lifecycle methods such as componentDidMount, componentDidUpdate and componentWillUnmount. A functional component is a plain function that returns JSX and, since React 16.8, uses Hooks for state and side effects.
  2. Map lifecycles onto Hooks. useEffect with an empty dependency array runs after the first render. Listing dependencies re-runs it when those values change. The function it returns is the cleanup, which runs before the next effect and on unmount. Note that a useState setter replaces the value instead of merging it, so object state needs a spread.
  3. Compare re-render control and reuse. React.memo plus useMemo and useCallback cover what shouldComponentUpdate and PureComponent did, and custom hooks replace higher-order components and render props for sharing logic.
  4. State the exception: error boundaries still need a class component (getDerivedStateFromError and componentDidCatch). Functional components are the default for new code because they avoid 'this' binding and keep related logic together.

Follow-up

  • What is a stale closure in useEffect, and how do the dependency array or a functional state update fix it?
  • When would you use useLayoutEffect instead of useEffect?
  • Why can reading state straight after setting it show the old value, and how does React 18's automatic batching affect this?

What is the difference between local and instance variables?

Medium · Technical Foundations & Core Concepts

Approach

  1. Local variables are declared inside a method, constructor or block. They exist only while that call or block runs, live in the call's stack frame, take no access modifiers (only final), and get no default value, so the compiler rejects reading one before it is definitely assigned.
  2. Instance variables are non-static fields declared in the class body. Each object gets its own copy, stored with the object on the heap. They default to 0, false or null, accept access modifiers, and live as long as the object is reachable.
  3. Add static (class) variables, which have one copy per class shared by all instances, and show shadowing: a parameter or local named like a field hides it, which is why constructors write this.name = name.
  4. Draw the thread-safety consequence. A local primitive is confined to its thread, but a local reference can still point at a shared heap object. Instance fields are shared by every thread that uses the same object, so they need synchronisation or immutability.

Follow-up

  • Why must a local variable captured by a lambda or anonymous class be effectively final?
  • If a method creates a new object and stores it in a local variable, where do the reference and the object each live?
  • What changes if you make that instance variable static?

Can you describe a project you worked on involving healthcare or AYUSH systems?

Medium · Project Experience & Scenario Analysis

Approach

  1. Pick one project and describe the system before the story: who used it, what data it held, and the main components and data flow (client, API, database, any integrations). Say plainly which part you built.
  2. Treat the sensitive data as a design constraint and say what you did about it: role-based access control, encryption in transit (TLS) and at rest, audit logs of who read or changed a record, collecting only the fields you needed, and testing with synthetic or de-identified data instead of real records.
  3. If the project followed a healthcare data standard or a compliance requirement, name the one you actually used and the decision it forced. If you have no healthcare or AYUSH project, say so and choose the closest project that handled personal or sensitive data.
  4. Close with a technical decision and its trade-off (for example a schema choice, a caching decision, or where validation lived) and a result you can check, such as a latency figure, an error-rate change, or a feature shipped and adopted.

Follow-up

  • How would your design handle a request to delete or export one person's records?
  • What would you change in that project's architecture if you rebuilt it today?
  • How did you test the system without exposing real patient or user data?

How do you manage your time when facing a complex technical hurdle?

Medium · Project Experience & Scenario Analysis

Approach

  1. Start with how you size the hurdle. Split it into the parts you understand and the unknowns, and set a timebox for investigating each unknown before you commit to an approach.
  2. Explain how you keep moving: build a small spike or prototype to test the riskiest assumption first, keep a running log of what you tried and ruled out, and switch to a workaround when the timebox runs out without progress.
  3. Say when and how you ask for help. You ask once you can state the problem, what you tried and what you suspect, so the other person can help quickly.
  4. Show that you communicate early: tell whoever depends on the work about the risk, offer options (reduce scope, a temporary fix now with the full fix later, a new date), and then back it up with one real example and its outcome.

Follow-up

  • Tell me about a time you missed a deadline because of a technical problem. What would you do differently?
  • How do you decide between a quick workaround and fixing the root cause?
  • If two blockers arrive at once, how do you decide which one gets your time?

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

Each day targets a group of this loop's reported questions: Java and OOP, pointers and linked lists, sorting and Dijkstra, React and database basics, debugging and projects, then personal questions and a full rehearsal.

Day 1 — Map the loop and rate your starting point

  • Write the five reported rounds in order and next to each note which reported question types it covers: personal, technical, project, feedback, offer.
  • List the technical questions in this guide and rate each from 1 to 3 for how well you could answer it aloud today.
  • Set up a Java file you can compile from the command line with no IDE help, and write a class with a constructor, a static method and a main method.

Deliverable: A one-page loop map, a rated list of the technical questions, and a Java file that compiles and runs.

Day 2 — Core Java, OOP and variable scope

  • Write a small Java program (for example a patient record, appointment and notification class set) that shows encapsulation, inheritance, abstraction and polymorphism, then explain each pillar from your own code.
  • Write a class that has local variables, instance variables and a static field, and show their default values, lifetime and where each lives in memory.
  • Make a list of the core Java features with the cost or benefit of each, including garbage collection, the JIT compiler and platform independence, and write a two-sentence answer on how Java achieves high performance.

Deliverable: One Java program, plus written answers to the core Java features, four pillars of OOP and local versus instance variable questions.

Day 3 — Pointers, linked lists and arrays

  • Write out the types of pointers (raw, null, void, dangling, wild, function, smart) with a short example of each and one sentence on how Java references differ.
  • Implement a singly linked list in Java with insert, delete, reverse and find-the-middle, then write complexity next to each method.
  • Solve two array problems that call for two pointers or a hash map and state the brute-force and improved complexities.

Deliverable: A linked list class with tested methods, two solved array problems, and a one-page pointers cheat sheet.

Day 4 — Sorting complexity and Dijkstra

  • Build a table of bubble, insertion, selection, merge, quick and heap sort with best, average and worst time, extra space and stability, and write when you would choose each.
  • Implement merge sort and quicksort and note what triggers quicksort's worst case.
  • Implement Dijkstra with a priority queue on a small weighted graph, trace it by hand, and write down why negative edges break it.

Deliverable: A sorting comparison table, working merge sort and quicksort, and a traced Dijkstra implementation with a note on its limits.

Day 5 — React components and database basics

  • Build the same counter with a functional component using hooks and with a class component, and write down differences in state, lifecycle and the this keyword.
  • Add a component that loads data on mount and cleans up on unmount, and explain how the lifecycle maps between the two styles.

Deliverable: Two working React components, a short comparison note, and a one-page revision sheet covering DBMS, OS and networking basics.

Day 6 — Debugging, time management and your project stories

  • Write out a repeatable debugging sequence (reproduce, narrow, form a hypothesis, test it, fix, add a regression test) and illustrate it with a real bug you fixed, including how you recorded the resolution.
  • Write your answer on managing time when stuck on a hard problem: a limit on solo effort, how you ask for help, and what you hand over.
  • Write the healthcare or AYUSH project answer, or the nearest equivalent, and the data sensitivity and compliance answer with concrete controls.

Deliverable: A written debugging narrative, a time-management answer, a project story and a compliance answer.

Day 7 — Personal questions and a full rehearsal

  • Write and rehearse the introduction, the career goals answer and the weaknesses answer, each tied to a specific example.
  • Run a full spoken rehearsal in loop order: introduction, two Java and OOP questions, a linked-list solution written live, sorting, Dijkstra, then a project story.
  • Prepare questions to ask in the feedback session and in the offer discussion, including the hybrid working arrangement and how code review and production issues are handled.

Deliverable: Three rehearsed personal answers, a recorded or written full run-through, and a list of questions for the last two rounds.

Project, compliance and personal questions

Candidates report that the behavioral interviews discuss past experiences and cultural fit. For this role, the reported prompts are personal (an introduction, career goals, criticism and weaknesses) and project-based (a healthcare or AYUSH project, compliance, and managing time on a hard problem). Use Situation, Task, Action, Result for stories, be honest about experience you lack, and prepare concrete details about the data you handled.

  1. Can you describe a project you worked on involving healthcare or AYUSH systems?
  2. How do you manage your time when facing a complex technical hurdle?

How do you handle real-world constraints like data sensitivity or compliance in your designs?

Medium · Project Experience & Scenario Analysis

Approach

  1. Choose a project where you made a design decision about sensitive data, such as personal, medical or financial records, and open with the data and what made it sensitive. Two sentences of context, then spend the answer on your decisions.
  2. Name specific controls you actually used: collecting only the fields you needed, encryption in transit and at rest, role-based access, audit logging of reads and writes, masking in logs and non-production data, retention and deletion rules.
  3. Show the trade-off the constraint caused, such as extra latency from field-level encryption or slower debugging because logs were masked, and how you handled it.
  4. Name a regulation or standard only if you worked under it (for example a healthcare privacy rule or GDPR), and say what it changed in the design. If you have not, say so and describe the closest practice you followed.
  5. End with how you verified the control worked: a review, a test with a restricted account, an access audit or a checklist sign-off.

Follow-up

  • How did you keep sensitive data out of logs, backups and test environments?
  • What did you do when a feature request conflicted with the constraint?
  • How would you design the access model if users had different roles?

Tell me about yourself.

Medium · Behavioral & Culture Fit

Approach

  1. Use a present, past, future shape: what you do now or study, the one or two projects that best show your Java, data structure, database or React skills, then why this role fits next.
  2. Mention the stack by name (for example Java or C/C++, a database, React) so the introduction matches the requirements candidates describe, and give one concrete outcome from a project, not a list of technologies.
  3. Include a short link to the domain if you have one, such as a healthcare or data-sensitive project, or say what drew you to that kind of work.
  4. Stop after a short, complete answer and leave room for follow-up questions. The common failure is reading the CV in chronological order, which gives no reason to ask anything.

Follow-up

  • Which of those projects was the hardest, and what made it hard?
  • Why this role and why this kind of domain?
  • What part of your background is least relevant to this role, and how would you close that gap?

What are your current career goals?

Medium · Behavioral & Culture Fit

Approach

  1. Give a goal specific to engineering craft, for example becoming strong in backend performance and databases, owning features from specification to deployment, or adding React and cloud depth. Tie it to the full-lifecycle work described for this role.
  2. Back it with evidence: a course, project, certification or feature you built in the last year that moves you toward it, so the goal reads as a direction you are already following.
  3. Connect it to what you could do here, such as the healthcare or domain-specific systems, code review and production debugging in the role description. Do not claim knowledge of the team's plans.
  4. Avoid goals that leave the role (a switch to management in a year), goals so vague they fit any job, and goals that depend on a promotion timeline you cannot know.

Follow-up

  • What have you done in the past year to move toward that goal?
  • What would you do if the work available did not match it for a while?
  • Which skill is furthest from where it needs to be, and how will you build it?

How do you handle constructive criticism or identify your own weaknesses?

Medium · Behavioral & Culture Fit

Approach

  1. Pick a real weakness that you have actively worked on, such as writing code before clarifying requirements, being slow to ask for help, or thin tests on edge cases. A weakness that is a strength in disguise (perfectionism) reads as evasion.
  2. Tell one specific incident of criticism, for example a code review comment or a bug caught in testing: what was said, how you reacted, and what you changed afterwards.
  3. Show the change as a habit with evidence, such as a checklist, a test style, a review step or an earlier question to the product manager, and a later case where it paid off.
  4. Keep the tone calm and non-defensive. If you disagreed with the feedback, say how you checked it before accepting or pushing back. The loop reportedly includes a feedback session, so this is also practice for hearing criticism on your own interviews.

Follow-up

  • Tell me about a time a code review comment changed how you write code.
  • How do you ask for feedback when no one offers it?
  • What are you working on improving right now, and how will you know it is working?