The reported loop needs three kinds of preparation. The first is coding. The coding questions are classic data-structure problems: two-sum and subarray problems, linked-list reversal and cycle detection, binary tree traversals including the boundary traversal, swapping characters without library helpers, and sliding-window and two-pointer string work. Candidates say the difficulty rises with level, from easy-to-moderate at entry to hard for senior roles, and that obscure tricks are rare. On problems this familiar, your answer has to stand out through clean Java, handled edge cases (empty input, a single node, a self-loop, an odd-length string) and a time and space complexity you state before you write code.
The second is depth in Java and databases. The reported Java questions go below the API: how HashMap resolves collisions and when a bucket turns into a tree, how BlockingQueue coordinates producers and consumers, how garbage collection and stack versus heap allocation work, and the split between checked and unchecked exceptions. The SQL questions cover multi-table joins filtered with GROUP BY and HAVING, DDL versus DML, temporary tables versus table variables, and tuning slow queries with indexes and execution plans, and one backend question asks how Kafka handles high-throughput streams and consumer-group rebalancing. The role lists schema migrations and data access layers next to Java services, so give SQL the same practice time as Java.
The third depends on your level. Candidates report low-level and high-level design assessments in SDE II and SDE III/Lead loops. Reported examples include an object-oriented design such as a parking lot or a notification engine, and fault-tolerant service-to-service communication through proxies and load balancers. At every level, candidates report detailed questions about the frameworks and tools on their resume in several rounds, and a final managerial round that mixes technical depth with project leadership, puzzles and conflict resolution. Remove anything from your resume that you cannot explain one layer down, or relearn it before the loop.
Preliminary Test
reportedCandidates who enter through campus or university drives report a preliminary stage that is either a verbal communication test or an aptitude test. A Hermet test and a group discussion are named as examples. Lateral hires generally report that they skip this stage. It tests reasoning and spoken communication, not code. Practise quantitative and logical aptitude items against a clock. If your drive uses a group discussion, practise making one clear point early, building on what others say and summarising at the end, rather than trying to talk the most.
What to demonstrate
- Verbal communication, as reported for this stage
- Aptitude and logical reasoning, for candidates given the aptitude format
How to prepare
- Work a set of aptitude problems (percentages, ratios, time and work, number series) and logical puzzles. The same reasoning helps with the brain-teaser candidates report later in the loop.
- Practise a group discussion out loud on a technology topic: state a position, give one supporting example, answer a counterpoint, then summarise where the group landed.
- Ask the campus coordinator or recruiter which format your drive uses so you prepare for the right one.
Technical Phone Screen
reportedLateral hires report starting here, with a technical phone screen or an online coding assessment in place of the preliminary test. Review JVM memory, multithreading primitives, thread safety and basic network protocols before the screens. You may get a live conversation or an online judge, so prepare for both. In a live screen, explain your approach and its complexity before you write code. In an online assessment, submit complete, compiling solutions that handle empty and boundary inputs.
What to demonstrate
- Working code on data-structure problems, which a coding screen or online assessment inherently tests
- Core Java and CS fundamentals such as JVM memory and thread safety
How to prepare
- Solve two-sum with a hash map, maximum subarray with Kadane's algorithm and subarray-sum-equals-k with prefix sums, and state each complexity aloud.
- Write linked-list reversal and Floyd's cycle detection in Java from memory, including the step that returns the node where the cycle starts.
- Rehearse short spoken answers on stack versus heap, why a plain HashMap is unsafe across threads, and checked versus unchecked exceptions.
- Refresh networking basics: TCP versus UDP, the path of an HTTP request from browser to server, and how DNS resolution works.
Core Technical Rounds
reportedCandidates describe the core technical rounds as covering problem-solving, data structures, algorithm implementation, programming fundamentals in Java and SQL, and system architecture. Resume deep-dives are reported across rounds. Practise switching between code, SQL and runtime explanations without notes: solve a tree problem, explain HashMap internals, then write a join with HAVING. For each coding problem, state the brute force, the better approach and its complexity before you write it.
What to demonstrate
- Data structures and algorithm implementation in working code
- Java and SQL fundamentals
- System architecture discussion, which candidates list among the core topics
How to prepare
- Implement in-order, pre-order and post-order traversals iteratively, then the anti-clockwise boundary traversal, and test them on a skewed tree and on a single node.
- Practise sliding-window and two-pointer string problems: longest substring without repeating characters, minimum window substring, valid palindrome.
- Write a three-table query with a LEFT JOIN, GROUP BY and HAVING, and a query for the top three spenders per region using a window function.
- Explain HashMap treeification, BlockingQueue locking and generational garbage collection aloud without notes.
Low-Level Design Assessment
reportedCandidates report a separate low-level design assessment in SDE II and SDE III loops, focused on object-oriented class structure. The reported examples are enterprise modules such as a parking lot or a notification engine. SOLID principles and the Factory, Singleton and Observer patterns are on the reported study list. Use the same sequence for every design. Pin down requirements and scope, list the entities and what each one is responsible for, and define interfaces before concrete classes. Then trace one request through the objects. Name a pattern only where it isolates something that is likely to change.
What to demonstrate
- Turning requirements into classes, interfaces and relationships
- Applying OOP principles, SOLID and common design patterns
How to prepare
- Design a notification engine: Notification, Recipient, a Channel interface with email, SMS and push implementations, a ChannelFactory, a retry policy and a delivery status. Show how a new channel is added without editing existing classes.
- Design a parking lot: levels, spot types, vehicle types, tickets, a spot-allocation strategy and a fee calculator. Make spot assignment safe when two cars enter at once.
- Write a one-line example of each SOLID principle and of a violation, such as Square extending Rectangle for Liskov substitution.
High-Level Architectural Assessment
reportedCandidates report a high-level architectural assessment for SDE II and SDE III/Lead candidates, focused on system architecture and microservices. Reported architecture study topics include service-to-service communication, API gateways, reverse proxies, caching, load balancing, circuit breakers, sharding and stateless services. Structure each answer in four parts: requirements and scale, a component diagram, the data flow for the main request, and failure handling (what happens when a service instance, a proxy or a cache goes down).
What to demonstrate
- Breaking a system into services and choosing how they communicate
- Resilience under failure: load balancing, timeouts, retries and circuit breakers
How to prepare
- Outline a fault-tolerant messaging bridge: clients behind a load balancer, a reverse proxy or gateway, stateless services and a durable queue between producers and consumers. Put timeouts, retries with backoff and jitter, and a circuit breaker on every outbound call.
- Compare load-balancing algorithms (round robin, least connections, consistent hashing), where a cache sits (at the gateway or as a cache-aside layer in the service) and how it is invalidated, and what a gateway adds over a plain reverse proxy (authentication, rate limiting, routing).
- Pick a shard key for a large orders table, say which query it makes expensive, and explain why stateless services make horizontal scaling and failover simpler.
- Prepare an answer on latency and message loss between services: idempotency keys, at-least-once delivery with deduplication, and the transactional outbox.
Managerial and HR Evaluation
reportedCandidates report that the loop ends with a combined managerial and HR evaluation. The managerial part reportedly mixes technical depth with project leadership, puzzle-solving and conflict resolution, and HR topics reported include stability, pay expectations, location and values. Prepare two or three project stories you can take technically deep if asked, a puzzle-solving routine you can narrate, and plain, consistent answers on notice period, location and why you would stay.
What to demonstrate
- Project delivery history and the decisions you made personally
- Behavioural fit, handling of conflict, and reasoning on a puzzle
How to prepare
- Write a one-page outline of your strongest resume project: the problem, its scale, the architecture, two decisions with the alternatives you rejected, your own part and the measured result.
- Rehearse a conflict story and a project-leadership story in STAR form, each ending with what changed afterwards.
- Solve classic puzzles out loud: two eggs and 100 floors, 25 horses with five lanes, finding the heavier ball with a balance.
- Settle your answers on compensation expectations, location and career plans in advance, and make sure they match what you told the recruiter.
PracHub editorial advice for the preparation topics above.
Using StringBuilder.reverse(), String.valueOf() or a sort call on the character-swap or string questions after being told not to use built-ins.
Ask at the start exactly which helpers are allowed, including whether charAt is acceptable or the input can be a char[]. Then write the two-pointer swap on a char array yourself, explain that Java Strings are immutable so a copy is needed, and test empty, single-character and odd-length input.
Describing HashMap as 'an array of linked lists' and stopping there, with nothing on resizing, Java 8 treeification or how ConcurrentHashMap differs from a synchronized map.
Rehearse the full chain aloud: hash spreading, index masking, load factor and resize, treeifying a bin once adding a node takes it past 8 (the 9th node) when capacity is at least 64, the equals/hashCode contract, then ConcurrentHashMap's CAS and per-bin locking and its ban on nulls. Do the same depth for BlockingQueue's locks and conditions.
Writing a LEFT JOIN and then filtering the right-hand table in WHERE, or counting with COUNT(*), so customers with no orders disappear or show a count of 1.
Move right-table conditions into the ON clause, count a right-table key, COALESCE the sums, and check row counts before and after each join. Pre-aggregate any second one-to-many table so totals do not inflate.
Claiming Kafka keeps events in order across a whole topic, or ignoring the duplicates a consumer-group rebalance can cause.
State that ordering holds only within a partition, so related events share a key. Explain offset commits after processing, at-least-once delivery and idempotent handlers, and mention cooperative rebalancing and static membership as ways to reduce churn.
Listing technologies on the resume that you cannot explain beyond having used them, or telling project stories in 'we' with no personal decisions.
For each resume line, prepare the architecture, one decision you made with its alternatives, and one internal detail of every listed tool. Remove anything you cannot defend, and tell stories in 'I' with measured results.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Given an array of integers, solve two-sum and sub-array optimization problems within optimal time complexity.
Given an array of integers, solve two-sum and sub-array optimization problems within optimal time complexity.
Approach
- Two-sum: walk the array once with a HashMap from value to index. For each x, check whether target - x is already in the map before inserting x. That gives O(n) time and O(n) space, and checking first stops you pairing an element with itself.
- If the array is sorted, or you may sort it and return values instead of indices, use two pointers from the ends. Move left when the sum is too small and right when it is too large: O(n log n) with the sort, O(1) extra space.
- Maximum subarray sum: Kadane's algorithm, cur = max(a[i], cur + a[i]) and best = max(best, cur), O(n) and O(1). Start best at a[0], not 0, so an all-negative array returns its largest element.
- Count of subarrays summing to k: keep a running prefix sum and a map of prefix-sum counts seeded with {0: 1}. Add count[prefix - k] at each step. This works with negative numbers. A shrinking sliding window only works when every value is positive.
- Edge cases to state: duplicate values (the [3, 3] with target 6 case), no valid pair, and int overflow on large sums, which you avoid by using long.
Follow-up
- How would you return every unique pair that sums to the target, with no duplicate pairs?
- How does your subarray-sum approach change if the array can contain negative numbers?
- Can you return the start and end indices of the maximum subarray as well as its sum?
How do you reverse or traverse a singly linked list, and how do you detect cycles within it?
How do you reverse or traverse a singly linked list, and how do you detect cycles within it?
Approach
- Iterative reversal uses three references: prev = null and curr = head. In a loop, save next = curr.next, set curr.next = prev, then advance prev and curr. Return prev. That is O(n) time and O(1) space. The recursive version is shorter but uses O(n) stack and can overflow on very long lists.
- Cycle detection is Floyd's tortoise and hare. Slow moves one step and fast moves two. If fast or fast.next becomes null there is no cycle; if they meet, there is one. O(n) time, O(1) space, compared with a HashSet of visited nodes that costs O(n) space.
- To find where the cycle starts, reset one pointer to the head and move both one step at a time. They meet at the entry node. Be ready to justify this: if the tail before the cycle has length a and the meeting point is b steps into the cycle, then a is congruent to -b modulo the cycle length.
- Test on an empty list, a single node, a single node pointing to itself, a two-node cycle and a cycle that starts at the head.
Follow-up
- How do you find the length of the cycle once you have detected it?
- Reverse the list in groups of k nodes, leaving any final partial group as it is.
- How would you remove the cycle without losing any node?
Implement binary tree traversals (in-order, pre-order, post-order) and solve boundary tree traversal problems.
Implement binary tree traversals (in-order, pre-order, post-order) and solve boundary tree traversal problems.
Approach
- Recursive traversals differ only in where the visit happens: pre-order visits before both children, in-order between them, post-order after both. Each is O(n) time and O(h) stack, where h is the height, which is O(n) for a skewed tree.
- Iterative versions: for in-order, push left children onto a stack until null, pop and visit, then move to the right child. For pre-order, pop, visit, then push right before left. For post-order, either use two stacks or produce root-right-left order and reverse it. Morris traversal gets in-order down to O(1) extra space by temporarily threading predecessor links.
- Anti-clockwise boundary traversal has three parts. First print the root, then the left boundary from the top down excluding leaves (prefer the left child, fall back to the right). Then print all leaves from left to right with a DFS. Finally print the right boundary from the bottom up excluding leaves, which you collect top-down and then reverse.
- Edge cases: a root with no left subtree (the left boundary is empty, and the root must not be printed twice), a single-node tree (print it once, not again as a leaf) and fully skewed trees. The whole traversal is O(n) time and O(h) space.
Follow-up
- Write post-order iteratively with a single stack.
- Print the tree level by level, then in zigzag order.
- How would you print the vertical order or the top view of the same tree?
Write a program to swap characters in a string without using any built-in functions or extra library utilities
Write a program to swap characters in a string without using any built-in functions or extra library utilities.
Approach
- Clarify the constraint first: does it rule out only helpers like StringBuilder.reverse(), or also toCharArray() and charAt()? Java Strings are immutable, so every version needs a mutable char array. A String gives no access to its characters without charAt, toCharArray or getChars, so if all three sound banned, ask whether charAt is allowed or whether the input can be a char[].
- To swap positions i and j: check that both indices are in range, then do tmp = arr[i]; arr[i] = arr[j]; arr[j] = tmp; and build the result from the array. For full reversal, use two pointers from the ends that swap and move inward until they cross. To swap adjacent pairs, step by 2 and swap i with i + 1.
- Complexity is O(n) time and O(n) space for the array copy, since a Java String cannot be changed in place. In C or C++ the same swap works in place with O(1) extra space.
- Edge cases: an empty string, one character, odd length (the middle character or the last unpaired one stays put) and i == j. If you show the XOR swap without a temporary, point out that it zeroes the value when i == j, so guard against that case.
Follow-up
- Reverse the order of the words in a sentence in place, without split().
- Can you swap two characters without a temporary variable, and what can go wrong?
- What happens with characters outside the Basic Multilingual Plane, which Java stores as surrogate pairs?
Explain the algorithmic approach to solve string manipulation, sliding window, and two-pointer challenges.
Explain the algorithmic approach to solve string manipulation, sliding window, and two-pointer challenges.
Approach
- Variable-size window: grow the right edge, update state (a HashMap or an int[26] or int[128] of counts), and shrink the left edge while the window breaks the condition. Each index enters and leaves once, so it is O(n). Use it for longest substring without repeating characters, minimum window substring and longest substring with at most k distinct characters.
- Fixed-size window: add the incoming element and remove the outgoing one each step. Use it for maximum sum of k consecutive elements and finding all anagrams of p in s, where you compare count arrays in O(26) per step.
- Opposite-end two pointers on sorted data or symmetric strings: pair sum, valid palindrome (skip non-alphanumerics, compare case-insensitively), container with most water. Same-direction read and write pointers handle in-place compaction, such as removing duplicates from a sorted array.
- Say when the window technique fails. With negative numbers, shrinking no longer keeps the sum monotonic, so switch to prefix sums with a hash map, or a monotonic deque for constraints on the minimum or maximum in the window.
Follow-up
- Write minimum window substring and explain how you know when the window is valid.
- Why does the sliding window break for 'longest subarray with sum at most k' when values can be negative?
- How would you find the longest palindromic substring, and what does expanding around centres cost?
Explain the internal working of Java collections, specifically focusing on `HashMap` collisions and thread-saf
Explain the internal working of Java collections, specifically focusing on HashMap collisions and thread-safe implementations.
Approach
- HashMap structure: a table of Node buckets whose length is a power of two (16 by default). The hash is spread as h ^ (h >>> 16) and the index is (n - 1) & hash. Default load factor 0.75: when size passes capacity times 0.75, the table doubles, and each bucket splits into a low list and a high list without rehashing every key.
- Collisions: entries in one bucket form a linked list, and lookups compare hash, then equals(). Since Java 8, a bin is treeified into a red-black tree when adding a node takes it past TREEIFY_THRESHOLD (8), that is on the 9th node, provided the table has at least 64 slots; below that the table resizes instead. A tree bin reverts to a list at 6 nodes when a resize splits it. Worst-case lookup drops from O(n) to O(log n).
- State the contract: keys that are equal must have equal hashCodes. Mutating a key after inserting it strands the entry in the wrong bucket.
- Thread safety: a plain HashMap loses updates under concurrent puts (and in Java 7 a concurrent resize could form a loop). Collections.synchronizedMap and Hashtable lock the whole map. Java 8's ConcurrentHashMap uses a CAS to fill an empty bin and synchronizes on the bin's first node otherwise. It allows no null keys or values, its iterators are weakly consistent, and computeIfAbsent and merge are atomic.
Follow-up
- Why must the capacity be a power of two?
- What breaks if a class overrides equals() but not hashCode()?
- Why does ConcurrentHashMap reject null values, and how accurate is its size()?
What are the concurrency utilities available in Java, and how does a `BlockingQueue` handle producer-consumer
What are the concurrency utilities available in Java, and how does a BlockingQueue handle producer-consumer patterns?
Approach
- List the java.util.concurrent toolbox by purpose. Execution: ExecutorService, ThreadPoolExecutor, Future, CompletableFuture. Coordination: CountDownLatch, CyclicBarrier, Semaphore, Phaser. Locking: ReentrantLock, ReadWriteLock, StampedLock. Lock-free counters: AtomicInteger, LongAdder. Collections: ConcurrentHashMap, CopyOnWriteArrayList, BlockingQueue.
- BlockingQueue semantics: put() blocks while the queue is full, take() blocks while it is empty, offer() and poll() with a timeout give up after waiting, and add() throws when the queue is full. A bounded queue creates backpressure: fast producers slow down instead of exhausting memory.
- Implementations: ArrayBlockingQueue uses one ReentrantLock with two Conditions, notEmpty and notFull. LinkedBlockingQueue uses separate put and take locks, so producers and consumers contend less. Mention SynchronousQueue (a direct hand-off) and PriorityBlockingQueue (unbounded).
- Write the pattern: N producer threads call put() and M consumer threads loop on take(), all managed by an ExecutorService. Shut down with a poison-pill object per consumer or by interrupting the threads, and restore the interrupt flag when you catch InterruptedException.
Follow-up
- Implement a bounded blocking queue yourself with wait/notifyAll, and explain why the wait sits inside a while loop.
- What goes wrong if the producer-consumer queue is unbounded?
- How does ThreadPoolExecutor decide between queueing a task, adding a thread and rejecting it?
Explain garbage collection mechanisms in Java and how memory allocation differs between stack and heap memory.
Explain garbage collection mechanisms in Java and how memory allocation differs between stack and heap memory.
Approach
- Stack versus heap: each thread has its own stack of frames holding local primitives and references, freed when the method returns, and deep recursion overflows it with StackOverflowError. The heap is shared and holds objects. The garbage collector reclaims it, and running out throws OutOfMemoryError. Escape analysis can sometimes keep an object that never escapes off the heap.
- Reachability: the GC traces from roots (thread stacks, static fields, JNI references) and collects anything it cannot reach. Cycles of objects are therefore collected, unlike under reference counting.
- Generations: new objects go into Eden. A minor GC copies the survivors between two survivor spaces and promotes long-lived objects to the old generation, which is collected less often with mark-sweep-compact or region-based schemes. Collectors: Serial, Parallel (throughput), G1 (the default since Java 9, region-based with a pause-time goal), and ZGC and Shenandoah (very short pauses).
- Effect on latency: stop-the-world pauses show up as p99 spikes. Reduce the allocation rate, size the heap and generations, pick a low-pause collector, and read the GC logs. In Java, leaks come from objects that are still referenced: growing static collections, unremoved listeners, ThreadLocals in pooled threads, and unclosed resources.
Follow-up
- How would you confirm and locate a memory leak in a running service?
- What are strong, soft, weak and phantom references for?
- What triggers a full GC, and why is it worse than a minor GC?
Write a SQL query to perform multi-table inner, left, and right joins while filtering aggregated datasets usin
Write a SQL query to perform multi-table inner, left, and right joins while filtering aggregated datasets using GROUP BY and HAVING.
Approach
- Fix the grain first. For example, with customers(id, name, region_id), regions(id, name) and orders(id, customer_id, amount, created_at), write customers JOIN regions (inner, since every customer has a region) LEFT JOIN orders. Then GROUP BY c.id, c.name, r.name, select SUM(o.amount) and COUNT(o.id), and filter with HAVING SUM(o.amount) > 1000.
- WHERE filters rows before grouping and HAVING filters groups after it. A condition on the right-hand table of a LEFT JOIN placed in WHERE silently turns it into an inner join, so put it in the ON clause. With a LEFT JOIN use COUNT(o.id), not COUNT(*), so customers with no orders count 0, and COALESCE the sums.
- A RIGHT JOIN is the mirror image of a LEFT JOIN, so rewrite it as a LEFT JOIN with the tables swapped for readability. Show an anti-join (LEFT JOIN ... WHERE o.id IS NULL) to find customers with no orders.
- Watch for fan-out: joining orders and payments both at the customer level multiplies rows and inflates sums. Aggregate each one in its own subquery or CTE first. For the reported top-three-spenders-per-region variant, rank with ROW_NUMBER() or DENSE_RANK() OVER (PARTITION BY region ORDER BY total DESC) and filter on rank <= 3.
Follow-up
- Return the top three highest-spending customers per region, and decide how ties are handled.
- List customers who placed no orders in the last 30 days.
- Why does the total double after you join a second one-to-many table, and how do you fix it?
What are temporary tables in SQL, when should you use them, and how do they differ from table variables?
What are temporary tables in SQL, when should you use them, and how do they differ from table variables?
Approach
- Name the dialect: #temp tables and @table variables are SQL Server concepts. MySQL and PostgreSQL have CREATE TEMPORARY TABLE but no table variables.
- Temporary tables (#t) live in tempdb, are visible to the session (a ##global table to all sessions) and are dropped when the session or procedure ends. They support indexes, statistics and ALTER, and they take part in transactions, so a ROLLBACK undoes changes to them.
- Table variables (@t) are scoped to the batch or procedure. They also live in tempdb, so the idea that they are purely in memory is a misconception. They historically had no statistics, so the optimiser assumed very few rows; SQL Server 2019's deferred compilation improves this. Their changes are not undone by ROLLBACK, and they cause fewer recompiles.
- Rule of thumb: use a temp table for large intermediate results you will join or index, and a table variable for small lookup sets. Also say when neither is needed: a CTE or derived table is enough when the intermediate result is used once.
Follow-up
- How is a CTE different from a temp table, and is a CTE materialised?
- Write the top-three-spenders-per-region query with a temp table holding per-customer totals.
- Why might a query against a table variable get a poor execution plan?
What are the core principles of Object-Oriented Programming (OOP), and how do you apply abstraction and encaps
What are the core principles of Object-Oriented Programming (OOP), and how do you apply abstraction and encapsulation in system design?
Approach
- Name the four principles, each with a concrete Java mechanism. Encapsulation means private fields with methods that enforce invariants. Abstraction means interfaces and abstract classes that expose what a component does and hide how. Inheritance means extends, for genuine is-a relationships. Polymorphism means dynamic dispatch through overriding, decided at runtime, as distinct from overloading, which is resolved at compile time.
- Show encapsulation with an example: an Account class whose balance is private and changes only through withdraw() and deposit(), which reject negative amounts and overdrafts. Callers can never put the object into an invalid state.
- Show abstraction at a design boundary: a NotificationChannel interface with send(message, recipient), implemented by EmailChannel and SmsChannel. The service depends only on the interface, so adding a channel touches no existing caller (the open/closed principle).
- Cover the trade-off: deep inheritance trees are fragile, and Square extending Rectangle breaks Liskov substitution. In most cases favour composition, and keep inheritance for true subtypes.
Follow-up
- When would you choose an abstract class over an interface, given that Java 8 interfaces have default methods?
- Give an example where you would replace inheritance with composition.
- How do overloading and overriding resolve differently, and what does that mean for static methods?
How do exception handling mechanisms work in enterprise Java applications, and what is the difference between
How do exception handling mechanisms work in enterprise Java applications, and what is the difference between checked and unchecked exceptions?
Approach
- Hierarchy: Throwable splits into Error (OutOfMemoryError, StackOverflowError, which you do not catch) and Exception. Checked exceptions such as IOException and SQLException must be caught or declared. Unchecked exceptions, which are subclasses of RuntimeException such as NullPointerException and IllegalArgumentException, do not need to be.
- Mechanics: try, catch and finally. finally runs whether the try block completes or throws, except when System.exit is called, the JVM crashes or is killed, or the thread is killed. A return in finally overrides the try block's return and swallows any exception, so avoid it. Use try-with-resources for anything AutoCloseable; exceptions thrown on close are attached as suppressed exceptions rather than lost.
- Practice in a layered service: translate low-level exceptions at each boundary and keep the cause, for example throw new OrderStoreException("save failed", e). Map them to API responses in one global handler. Log each exception once, where it is handled, and never swallow it in an empty catch.
- Choosing a type: use checked exceptions for conditions a caller can reasonably recover from, and unchecked ones for programming errors and failures the caller cannot fix. Mark which failures are safe to retry (a timeout) and which are not (a validation error).
Follow-up
- Should a custom exception for a missing database row be checked or unchecked, and why?
- What happens if both the try block and the close() of a resource throw?
- Does finally run if System.exit is called inside the try block?
Explain the difference between Data Definition Language (DDL) and Data Manipulation Language (DML) commands.
Explain the difference between Data Definition Language (DDL) and Data Manipulation Language (DML) commands.
Approach
- DDL defines structure: CREATE, ALTER, DROP, TRUNCATE, RENAME. DML changes or reads data: INSERT, UPDATE, DELETE, MERGE, and SELECT (sometimes classed separately as DQL). Add the other two groups for completeness: DCL (GRANT, REVOKE) and TCL (COMMIT, ROLLBACK, SAVEPOINT).
- Transactions differ by engine. Oracle and MySQL commit implicitly around most DDL, so you cannot roll back a CREATE or ALTER there; PostgreSQL and SQL Server allow DDL inside a transaction. DML is transactional on transactional engines (InnoDB, PostgreSQL, SQL Server, Oracle), but not on MySQL's MyISAM, where a ROLLBACK cannot undo an UPDATE.
- Compare DELETE, TRUNCATE and DROP. DELETE removes rows one at a time, accepts WHERE, fires triggers and is fully logged. TRUNCATE removes all rows by deallocating pages, takes no WHERE, usually resets identity counters and is classed as DDL. DROP removes the table itself.
- Production context: on a large table, an ALTER can take locks or rewrite the table depending on the engine and version. Run migrations in small, reversible steps (add a nullable column, backfill in batches, then add the constraint).
Follow-up
- Can you roll back a TRUNCATE?
- When would you choose TRUNCATE over DELETE, and when can you not use it?
- How would you add a NOT NULL column to a table with hundreds of millions of rows without downtime?
How does messaging middleware like Kafka handle high-throughput event streams and consumer group rebalancing?
How does messaging middleware like Kafka handle high-throughput event streams and consumer group rebalancing?
Approach
- Throughput: a topic is split into partitions, and each partition is an append-only log addressed by offset. Producers batch and compress records and choose a partition by key hash. Brokers write sequentially, lean on the OS page cache and send data to consumers with zero-copy. Throughput scales with the number of partitions.
- Durability and ordering: each partition has a leader and followers in the in-sync replica set. With acks=all, min.insync.replicas of 2 or more and an idempotent producer, acknowledged writes survive the loss of a broker. Ordering is guaranteed only within a partition, so give all events for one conversation or customer the same key. There is no global order across partitions.
- Consumer groups: each partition goes to exactly one consumer in a group, so parallelism is capped at the partition count. A rebalance happens when a consumer joins or leaves, misses its session timeout, exceeds max.poll.interval.ms, or when partitions are added.
- Rebalance cost and safety: eager rebalancing revokes every partition. The cooperative sticky assignor and static membership (group.instance.id) cut that churn. Commit offsets after processing, which gives at-least-once delivery, and make handlers idempotent, because messages processed but not yet committed are redelivered after a rebalance. Kafka transactions give exactly-once from Kafka to Kafka.
Follow-up
- How do you guarantee the order of events for one customer across a topic with many partitions?
- Consumer lag keeps growing on one partition. What do you check?
- Why can a message be processed twice after a rebalance, and how do you make that harmless?
How do you optimize slow database queries using indexing strategies and execution plan analysis?
How do you optimize slow database queries using indexing strategies and execution plan analysis?
Approach
- Start from evidence. Find the slow statement in the slow-query log or monitoring, then run EXPLAIN (EXPLAIN ANALYZE in PostgreSQL, EXPLAIN in MySQL, the actual execution plan in SQL Server). Look for full scans on large tables, estimated row counts far from the actual ones, nested loops over large inputs, and sorts or hashes spilling to disk.
- Index design: a B-tree on the filter and join columns. In a composite index put equality columns first and the range column last, because the leftmost-prefix rule applies. Use a covering index (INCLUDE columns, or every selected column) to avoid lookups back to the table, and index high-selectivity columns.
- Know what makes an index unusable: a function on the column (WHERE YEAR(created_at) = 2025, which you rewrite as a range), a LIKE pattern that starts with a wildcard, implicit type conversions, and OR across different columns. Fix the query shape as well: no SELECT *, no N+1 query loops, and keyset pagination instead of a large OFFSET.
- Trade-offs: every index slows INSERT and UPDATE and costs storage. For a high-cardinality column with heavy writes, keep only the indexes that queries actually use, prefer a narrow index, and consider batching writes. Refresh statistics (ANALYZE or UPDATE STATISTICS) when estimates drift.
Follow-up
- How would you index a high-cardinality column on a table with heavy write traffic?
- The index exists but the optimiser ignores it. Why might that be?
- What is the difference between a clustered and a non-clustered index?
How do you approach building fault-tolerant microservice communications using proxy servers and load balancers
How do you approach building fault-tolerant microservice communications using proxy servers and load balancers?
Approach
- Lay out the request path: clients go to a load balancer, then to an API gateway or reverse proxy, then to stateless service instances. Health checks pull bad instances out of rotation, both active probes and passive outlier ejection. Choose L4 or L7 balancing and an algorithm: round robin, least connections, or consistent hashing when you need affinity.
- Each outbound call needs a timeout shorter than its caller's timeout. Retry with exponential backoff and jitter, only on idempotent operations or with an idempotency key, and within a retry budget so retries cannot multiply load during an outage.
- Contain failures with a circuit breaker on each dependency (closed, open, half-open), bulkheads that separate thread or connection pools per dependency, and fallbacks such as cached data or degraded responses when a non-essential service is down.
- For message loss, move work that need not happen in the request onto a durable queue such as Kafka. Use at-least-once delivery with deduplication on the consumer, and the transactional outbox pattern so a database write and its event are never split. The proxies themselves must not be single points of failure: run them as redundant pairs behind a virtual IP or DNS.
Follow-up
- How do you stop retries from turning a slow dependency into an outage?
- How would you handle long-lived WebSocket connections behind a load balancer for real-time messaging?
- What happens to in-flight requests when you deploy a new version of a service?
Describe a past project listed on your resume, detailing your specific architectural decisions and tech stack
Describe a past project listed on your resume, detailing your specific architectural decisions and tech stack selections.
Approach
- Open with the problem and its scale in numbers you can defend: requests per second, data volume, latency target, number of users or tenants. Then sketch the architecture: components, data stores and the path of one main request.
- Pick two or three decisions and give each one the options you considered, what you chose and why, and the cost you accepted. For example: PostgreSQL over MongoDB because the data was relational and needed transactions, accepting harder horizontal scaling.
- Separate your own work from the team's. Use 'I' for what you designed, wrote or decided, and be explicit about what others owned.
- End with the measured outcome and one thing you would change now. Before the loop, review every technology on that resume line one layer below how you used it (how the framework handles a request, how the queue keeps ordering), because candidates report questions on specific listed tools.
Follow-up
- Why did you choose that database or framework over the obvious alternative?
- What broke in production, and how did you find out?
- What would have to change if traffic grew tenfold?
Read latency spikes on a sixty-second sawtooth
The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.
Approach
- Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
- Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
- Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
- De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.
Follow-up
- The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
- How does your answer change if the recompute takes 4 seconds instead of 250 ms?
The plan starts with an aptitude warm-up and coding fundamentals, moves to Java, networking and SQL depth, then design for SDE II and above, and ends with resume stories, behavioral prompts and puzzles. Every day ends with written or working output you can review before the loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Arrays, strings and an aptitude warm-up
- Solve two-sum with a HashMap, the sorted version with two pointers, maximum subarray with Kadane's algorithm and subarray-sum-equals-k with prefix sums, and write each complexity at the top of the file.
- Write the character-swap function in Java on a char[] input (or one filled with charAt, if that is allowed): swap two indices, reverse with two pointers and swap adjacent pairs, with tests for empty, single-character and odd-length input.
- Solve longest substring without repeating characters and minimum window substring, writing the window invariant as a comment before the code.
- If you enter through a campus drive, do a short timed aptitude set: percentages, ratios, time and work, number series and two logical-reasoning items.
Deliverable: A Java file of working array, character-swap and sliding-window solutions with complexity notes and passing edge-case tests, plus a scored, timed aptitude set.
Practice prompt ↗Practice prompt ↗Practice prompt ↗02Linked lists and binary trees
- Write iterative and recursive linked-list reversal, Floyd's cycle detection and the cycle-start step, then prove on paper why resetting one pointer to the head finds the entry node.
- Implement pre-order, in-order and post-order traversals both recursively and iteratively, plus level-order with a queue.
- Implement the anti-clockwise boundary traversal and test it on a full tree, a left-skewed tree, a root with no left child and a single node.
Deliverable: Tested list and tree implementations, plus a one-paragraph written proof of the cycle-entry step.
Practice prompt ↗Practice prompt ↗03Core Java and networking under the hood
- Write one page on HashMap internals (hashing, resize, treeification) and on ConcurrentHashMap versus a synchronized map, then explain it aloud from memory.
- Write a producer-consumer program with ArrayBlockingQueue, two producers, three consumers and poison-pill shutdown, then write a small bounded queue yourself with wait/notifyAll.
- Rehearse spoken answers on stack versus heap, generational GC and collector choice, checked versus unchecked exceptions, try-with-resources and when finally does not run, and the four OOP principles with a code example each.
- Write a one-page network refresher: TCP versus UDP, the TCP handshake, the path of an HTTP request and DNS resolution.
Deliverable: A HashMap one-pager, a working producer-consumer program and a home-made bounded queue, a checklist of the rehearsed Java and OOP answers, and a network one-pager.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗04SQL joins, schema commands and tuning
- Create customers, regions and orders tables locally. Write inner, left, right and anti-joins with GROUP BY and HAVING, then the top-three-spenders-per-region query twice: once with a window function and once with a temp table.
- Write a comparison table of DDL versus DML and of DELETE, TRUNCATE and DROP, including how each engine handles rollback, and another of temp tables versus table variables.
- Load enough rows to make a query slow, read its EXPLAIN plan, add a composite index, and record the plan and timing before and after.
Deliverable: A SQL script of working queries, two comparison tables, and before-and-after execution plans for one tuned query.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05Low-level design for SDE II and above
- Sketch the class diagram for a notification engine (Channel interface, implementations, factory, retry policy, delivery status) and walk one notification through it out loud.
- Sketch the parking lot design with an allocation strategy and fee calculator, and write the thread-safe spot-claim method in Java.
- Write one example and one violation for each SOLID principle, and say where Factory, Singleton and Observer appear in your two designs.
Deliverable: Two class diagrams, a thread-safe spot-allocation method and a SOLID cheat sheet that refers to both designs.
Practice prompt ↗Practice prompt ↗06High-level architecture and Kafka
- Outline a fault-tolerant messaging bridge with load balancers, a gateway or proxy, stateless services and a durable queue, and note the timeout, retry, circuit-breaker and deduplication choice at each hop.
- Write out how Kafka partitions, keys, replication, consumer groups, offset commits and rebalancing work, and answer the ordering-across-partitions question in writing.
- Work the latency-spike debugging exercise and list the causes you would check in order, including GC pauses, cache expiry and scheduled jobs.
Deliverable: An architecture diagram with notes on how each failure is handled, a Kafka explainer and a ranked list of causes for the latency-spike exercise.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Resume stories, behavioral prompts and puzzles
- Write the one-page outline for your strongest resume project, and review every tool listed on your resume one layer below how you used it.
- Rehearse a technical-blocker story, a conflict story and a project-leadership story in STAR form out loud, and record yourself once.
- Solve the horses, eggs and balance-scale puzzles out loud, then settle your answers on compensation expectations, location and career plans.
Deliverable: A project outline, three recorded STAR stories, narrated puzzle solutions and written HR answers.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report that the closing managerial round mixes technical depth with project leadership, puzzle-solving and conflict resolution, and that resume deep-dives come up in several rounds. The HR conversation reportedly turns to how settled you are, pay, where you want to work and values. Rehearse stories that hold up under technical follow-up questions.
Walk through the low-level design (LLD) of an enterprise service or object-oriented module (e.g., parking lot
Walk through the low-level design (LLD) of an enterprise service or object-oriented module (e.g., parking lot system, notification engine).
Approach
- Scope it first. For a notification engine: which channels (email, SMS, push), whether delivery is synchronous or queued, user preferences and opt-outs, priorities, retries and rate limits. For a parking lot: the number of levels, the spot and vehicle types, how entry and exit work, and the pricing rules.
- Notification engine classes: a Notification (id, template, payload, priority), a Recipient with preferences, a Channel interface with send(), the implementations EmailChannel, SmsChannel and PushChannel, a ChannelFactory (or Strategy) that picks channels from preferences, a NotificationService that orchestrates, a RetryPolicy with exponential backoff, and a DeliveryStatus record.
- Parking lot classes: ParkingLot contains Levels and Levels contain ParkingSpots (compact, large, EV). Add a Vehicle hierarchy, a Ticket, a SpotAllocationStrategy interface (nearest-first, by level) and a FeeCalculator interface. Make allocation atomic, either by locking per level or by claiming a spot with compare-and-set, so two cars never get the same spot.
- Defend the design against SOLID. Adding a channel or a pricing rule means adding a class, not editing a switch statement (open/closed). Each class has one reason to change. Handle edge cases explicitly: duplicate sends (an idempotency key), a failing channel (fall back or send to a dead-letter queue), and a full lot.
Follow-up
- Add a WhatsApp channel. Which classes change?
- How do you stop the same notification going out twice after a retry?
- How would you make spot allocation thread-safe without one global lock?
Solve a brain-teaser or logical puzzle while explaining your step-by-step analytical reasoning to the intervie
Solve a brain-teaser or logical puzzle while explaining your step-by-step analytical reasoning to the interviewer.
Approach
- Narrate a routine: restate the puzzle and its constraints, try the smallest cases, look for an invariant or a bound, then build up to the general answer and check it against an extreme case.
- 25 horses, 5 lanes, no timer, fastest three: run 5 heats, then race the 5 heat winners in a sixth race. Name the heats by that result (A1 first, B1 second, C1 third). A1 is fastest overall. Only five horses can still be 2nd or 3rd: A2 and A3 from A1's heat, B1 and B2, and C1. Race those 5; the top two finish 2nd and 3rd overall, for 7 races in total. Every horse from the D and E heats is out.
- Two eggs, 100 floors: drop the first egg from floors 14, 27, 39 and so on, shrinking the step by one each time, then step through the remaining floors one by one with the second egg. The worst case is 14 drops, because 14 + 13 + ... + 1 = 105, which is at least 100.
- Eight balls, one heavier, a balance scale: weigh 3 against 3. If they balance, weigh the remaining 2 against each other. Otherwise weigh 1 against 1 from the heavier group. That is two weighings. If you get stuck, say what you have ruled out and what you are trying next instead of going silent.
Follow-up
- Generalise the egg problem to k eggs and n floors.
- With 12 balls where the odd one may be heavier or lighter, how do you find it in three weighings?
- In the horse puzzle, why can B3 not be third overall?
Describe a situation where you encountered a major technical blocker during development and how you resolved i
Describe a situation where you encountered a major technical blocker during development and how you resolved it.
Approach
- Choose a blocker that is concrete and technical: a deadlock under load, a memory leak, a consumer group stuck rebalancing, a third-party API changing behaviour. Avoid vague stories about a slow approval. Give the situation and the stakes (deadline, users affected) in two sentences.
- Spend most of the answer on the diagnosis in order: what you observed, the hypotheses you ranked, the evidence that ruled each one in or out (logs, a thread dump, a heap dump, a reproduction), and the point at which you escalated or asked for help, with your reason.
- State the fix and the alternatives you rejected, then the measured result: latency back to target, the error rate, the release shipped on time.
- Close with what changed afterwards: a test, an alert, a runbook or a design change, so the same blocker cannot recur unnoticed. Two mistakes sink this answer: a story where someone else solved it, and one that ends without a result.
Follow-up
- At what point would you have escalated if your fix had not worked?
- What would you do differently if you hit the same blocker today?
- How did you make sure it did not happen again?
- 01
Describe a past project listed on your resume, detailing your specific architectural decisions and tech stack selections.
- 02
Describe a situation where you encountered a major technical blocker during development and how you resolved it.
- 03
Solve a brain-teaser or logical puzzle while explaining your step-by-step analytical reasoning to the interviewer.
- 04
Tell me about a time you disagreed with a teammate on a technical approach and how it was settled.
- 05
Tell me about a project you led from planning to delivery and how you kept it on schedule.
How long does the [24]7.ai Software Engineer process take, and how many rounds are there?
Candidates name six stages: Preliminary Test, Technical Phone Screen, Core Technical Rounds, Low-Level Design Assessment, High-Level Architectural Assessment, and Managerial and HR Evaluation. Not everyone gets all six. Reports put the number of stages at four to six depending on level and entry channel, and the reported timeline ranges from one to three weeks in some accounts to four to six weeks in others. Ask your recruiter for your own sequence.
[24]7.ai Software Engineer candidate reports ↗Will I get system design questions as an entry-level candidate?
Candidates report the low-level and high-level design assessments mainly in SDE II and SDE III/Lead loops. Mid-level loops focus on object-oriented class design and senior loops on microservice architecture. Entry-level candidates should still prepare the OOP principles question and one small class design, because OOP is also listed under the core Java topics.
[24]7.ai Software Engineer candidate reports ↗Do I have to interview in Java?
The requirements candidates describe list Java, or C++ or C#. However, the reported fundamentals questions are Java-specific: HashMap collisions, BlockingQueue, JVM garbage collection, checked versus unchecked exceptions. If you code in C++ or C#, prepare the equivalents (unordered_map or Dictionary internals, thread-safe queues, memory management) and be ready to say where they differ from Java.
PracHub Software Engineer practice ↗How hard are the technical questions?
Candidates describe the difficulty as rising with level, from easy-to-moderate for entry roles to hard for senior architecture roles. The reported coding questions are classic problems on arrays, linked lists, trees and strings rather than unusual puzzles. Prepare to write them cleanly, with edge cases and stated complexity, rather than collecting rare tricks.
[24]7.ai Software Engineer candidate reports ↗How much SQL and Kafka should I prepare?
SQL is listed as a must-have, and the reported questions cover joins with GROUP BY and HAVING, DDL versus DML, temp tables versus table variables, and index-based tuning, so practise writing queries, not just reading them. Kafka is listed as a nice-to-have, but one reported question asks about throughput and consumer-group rebalancing. Know partitions, keys, ordering and offset commits.
PracHub Software Engineer practice ↗What happens in the managerial and HR round?
Candidates report that the managerial part combines technical depth with project leadership, a puzzle and conflict resolution. The HR part is reported to cover how long you intend to stay, what you expect to be paid, where you want to work and values. Prepare a deep project story, a project-leadership story, a conflict story and a puzzle routine, and decide your answers on location and pay in advance.
[24]7.ai Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01[24]7.ai Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
candidate · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
platform · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
housing organisation Software Engineer Interview Questions & Guide 2026
What housing organisation asks Software Engineer candidates, from reported rounds and questions.
Zulily Software Engineer Interview Guide
What Zulily asks Software Engineer candidates, from reported rounds and questions.
Zemoso Technologies Software Engineer Interview Guide
What Zemoso Technologies asks Software Engineer candidates, from reported rounds and questions.
Zebra Technologies Software Engineer Interview Guide
What Zebra Technologies asks Software Engineer candidates, from reported rounds and questions.