Reports describe a generalist engineering role: algorithmic coding, backend and frontend services, containerized deployment and production monitoring all appear in the role description. The reported questions span the same range. The 25 reported questions fall into five groups of five: coding problems (LRU cache, linked-list reversal, array and string techniques, tree and graph traversal), core CS and databases (operating-system synchronization, normalization and indexing, joins, OOP, TCP/IP and HTTP), web development (the JavaScript event loop, DOM events, React, secure Node.js or Spring Boot services, JWT and OAuth), cloud and architecture (Kubernetes, Dockerfiles, secrets on AWS or Azure, CI/CD, fault-tolerant design) and behavioral discussion.
Breadth is the main preparation problem. Pick one coding language from the reported set (Java, Python, C++ or JavaScript) and be fluent in its ordered map, queue, heap and set before you touch the other groups, because an LRU cache or a sliding window is much easier when the container is a reflex. Then give the fundamentals real time. The reported tips say SQL joins, indexing, operating-system concurrency and OOP come up even for full-stack and frontend candidates, so a frontend specialist still needs a second-highest-salary query and a clear mutex-versus-semaphore answer.
Candidates also describe less common topics worth a pass once the core is solid: tries and disjoint set union, WebSockets, GraphQL and gRPC, Redis caching, Kafka-style queues, Terraform and canary deployments. Example scenarios they report include finding the maximum sub-array sum in linear time, detecting a cycle in a directed graph, and writing a join query that finds inactive accounts across several tables. The reported advice also stresses being ready to explain every project on your resume, so treat your own past work as a topic you rehearse with the same discipline as the algorithms.
Online Assessment
reportedReports describe the first stage as a check on basic qualifications and how your background fits. They do not detail its format, and one description pairs it with a preliminary recruiter screening. Prepare for both a short technical check and a conversation about your background, and ask your recruiter what the format is for your team.
What to demonstrate
- Basic qualifications for the role
- How well your background fits the role
How to prepare
- Refresh the fundamentals the role lists as must-haves: one modern language, data structures and algorithms, object-oriented design and relational databases
- Write a short account of your experience that names the languages and tools from your resume that match Java, Python, JavaScript, React, Node.js, Docker, Kubernetes or AWS
- Ask the recruiter whether this stage is a timed coding assessment, a screening call or both, then rehearse that format
Technical Stages
reportedReports mention more than one technical interview in this stage, covering live pair-programming, core topics and walkthroughs of past projects. Plan to type working code while talking: state the approach, confirm edge cases, then write and test.
What to demonstrate
- Live coding in your chosen language, with time and space complexity stated
- Core computer science topics
- How clearly you explain your own contribution to a past project
How to prepare
- Practise coding aloud on the reported coding types: an LRU cache with O(1) operations, reversing a singly linked list both ways, a sliding-window string problem and two-pointer or dynamic programming array problems
- Rehearse the core CS and database questions from this guide too, for example the second-highest salary query written two ways, with joins and indexing explained on the same table
- Choose two resume projects and outline the architecture, your exact part and the trade-offs you made
System Architecture Evaluation
reportedReports describe this stage as a system design assessment whose depth depends on your seniority. They do not say which questions belong to it. Approach any design discussion by clarifying scope first, then walking from client to data store.
What to demonstrate
- System design skill, which reports say varies with seniority
- Reports do not list the topics, so treat scale, availability and failure as preparation areas rather than confirmed content
How to prepare
- Rehearse one end-to-end design: load balancer, stateless services, a Redis cache tier, a queue for asynchronous work, replicated and sharded storage, and what happens when each part fails
- Be able to draw the Kubernetes control plane (API server, etcd, kubelet, worker nodes) and say how pods are scheduled and reach each other
- Prepare a short answer on secrets, role-based access control and a CI/CD pipeline with logging on AWS or Azure
Onsite or Virtual Panels
reportedReports describe the last technical panels as taking place either onsite or over video. They do not say which topics each panel takes, so prepare as for a mixed technical round. Check in advance which format you have and, for a virtual panel, test your setup.
What to demonstrate
- Reports do not say what the panels cover
- Whether your panel is onsite or virtual, which depends on arrangements for your team
How to prepare
- Run a mixed mock that combines one coding problem, one SQL query, one concurrency or networking explanation and one design discussion
- Rework your weakest area, such as the JavaScript event loop, event bubbling versus capturing, or the React component lifecycle
- Practise changing a finished solution when a constraint changes, for example a cache that must now be thread-safe
Managerial Rounds
reportedReports describe the managerial stage as closing conversations with management about team fit and overall alignment. Prepare stories where your own decisions are visible. The behavioral prompts candidates report are listed in the behavioral section as a separate group.
What to demonstrate
- Team fit
- Overall alignment with the role
How to prepare
- Write STAR outlines for the conflict, technical debt and failed-deployment prompts, each with a measurable result
- Prepare a project walkthrough that states the architecture, your specific contributions and the trade-offs
- Build a why-ABC answer from facts you can verify about the role, and prepare questions about the team's stack and practices
Offer Extension
reportedReports describe the last stage as the point where a formal offer is made, once every earlier stage is done. No technical content is reported for it. Use it to read the offer carefully and ask any remaining questions about the team and the role.
What to demonstrate
- Completion of every earlier stage
- The formal offer as the closing step of the loop
How to prepare
- List what you still want to know about the team's stack, engineering practices and upcoming migrations before you respond
- Review the written offer terms against your own priorities and ask for anything unclear in writing
2 candidate reports. Individual accounts describe a particular role and hiring cycle.
ABC Software Engineer aptitude, sorting, and HR interview experience
The process had three levels: an aptitude and coding test, a technical interview, and an HR interview. The aptitude and coding test was very easy to clear. The technical round had simple data-structures and algorithms questions, especially sorting, plus database basics. HR was about fit rather than deep technical work. Overall, it felt manageable and landed on the easier side of the spectrum. Loc…
Read full experienceABC Software Engineer interview experience
The process was coding-heavy and structured from the start. After recruiter outreach, I completed an online assessment with coding questions and multiple-choice questions on OS, DBMS, OOP, SQL, and general aptitude. Later, the first technical interview went through my resume and projects, DSA, and core computer-science concepts. The next technical round was tougher, with a harder coding problem,…
Read full experiencePracHub editorial advice for the preparation topics above.
Building an LRU cache from a hash map alone, or removing entries by scanning a list
Pair the map with a doubly linked list, or with an insertion- or access-ordered map (Java LinkedHashMap, Python OrderedDict, JS Map), so lookup, update and eviction are all O(1). A sorted map such as TreeMap or C++ std::map is O(log n) and orders by key, not recency, and C++ has no built-in ordered equivalent, so C++ candidates use std::list plus unordered_map. Test capacity of one, updating an existing key, and reading a key that was just evicted before saying you are done.
Reversing a linked list in only one style, or losing the next pointer mid-reversal
Write the iterative version with previous, current and a saved next, then the recursive version, and state its O(n) call-stack depth. Run both on an empty list and a single node. The prompt names both styles, so prepare both.
Answering the second-highest salary query with a bare offset that breaks on duplicates or returns the wrong thing when there is only one salary
Use DENSE_RANK or a subquery that takes the maximum below the maximum, and decide what to return when no second value exists. Explain that an index on the salary column helps the subquery form, and say how normalization affects where the salary lives.
Reciting definitions for the web and cloud questions without the mechanism: naming JWT without saying how a service validates it, or listing Kubernetes components without saying what each does
For each reported topic prepare one sentence of purpose and one of mechanism: signature check, expiry and revocation for JWT; API server as the front door and etcd as the state store for Kubernetes; the stack and phase ordering of the JavaScript event loop.
Giving vague project and behavioral answers where it is unclear what you personally did
Reported tips advise being ready to explain every project and tool on your resume. Outline each project with the architecture, your own contribution, one trade-off and one lesson, and write STAR outlines for the conflict, technical debt and failed-deployment prompts.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Implement an LRU Cache with `O(1)` time complexity for lookup and insertion.
Implement an LRU Cache with O(1) time complexity for lookup and insertion.
Approach
- Pair a hash map (key -> node) with a doubly linked list ordered by recency: head is most recently used, tail is least. The map gives O(1) lookup; the list gives O(1) unlink and insert.
- get(key): on a miss return the agreed sentinel (often -1); on a hit unlink the node, move it to the head and return its value.
- put(key, value): if the key exists, update the value and move the node to the head without evicting. Otherwise insert a new node at the head; if size exceeds capacity, remove the tail node and delete its key from the map. Store the key in each node so eviction can find the map entry.
- Use dummy head and tail sentinel nodes so empty-list and single-node cases need no null checks. Test capacity 1, repeated puts on one key, and a get that refreshes recency just before an eviction.
- Mention the library shortcuts and their limits: Python OrderedDict with move_to_end and popitem(last=False), Java LinkedHashMap(cap, 0.75f, true) overriding removeEldestEntry. C++ has no built-in equivalent, so use std::list plus unordered_map. Write the manual version anyway. Space is O(capacity).
Follow-up
- How would you make this thread-safe, and what does one global lock cost compared with a segmented cache?
- How would you change it into an LFU cache while keeping O(1) operations?
- How would you add per-entry TTL expiry?
Write a function to reverse a singly linked list both iteratively and recursively.
Write a function to reverse a singly linked list both iteratively and recursively.
Approach
- Iterative: keep prev = null and curr = head. In each step save next = curr.next, set curr.next = prev, then advance prev = curr and curr = next. Return prev. O(n) time, O(1) extra space.
- Recursive: if head is null or head.next is null, return head. Otherwise newHead = reverse(head.next); head.next.next = head; head.next = null; return newHead. O(n) time and O(n) stack depth.
- Point out the stack risk: Python's default recursion limit is about 1000 frames, and a long list can throw StackOverflowError in Java, so the iterative version is the production choice.
- Edge cases: empty list, one node, two nodes. Forgetting head.next = null in the recursive version leaves a two-node cycle at the new tail, so check that the last node's next is null.
- Verify by walking the result: compare the value sequence with the reversed input and confirm the length did not change.
Follow-up
- Reverse only the sublist between positions m and n in one pass.
- Reverse the list in groups of k nodes, leaving a short final group as it is.
- Check whether a linked list is a palindrome using O(1) extra space.
Solve array manipulation problems involving dynamic programming and two-pointer techniques.
Solve array manipulation problems involving dynamic programming and two-pointer techniques.
Approach
- Name the deciding property first. Two pointers need a monotonic structure (sorted input, or a window whose validity changes in one direction). DP needs overlapping subproblems with a clear state, recurrence, base case and fill order.
- Two-pointer examples: pair sum on a sorted array (move the left pointer if the sum is too small, the right if too large), container with most water (move the shorter side), and 3Sum in O(n^2) after sorting, skipping equal neighbours to avoid duplicate triplets.
- Kadane for maximum subarray sum: cur = max(x, cur + x), best = max(best, cur). Initialise both with the first element, not 0, so an all-negative array returns its largest element. O(n) time, O(1) space.
- 1D DP such as house robber: dp[i] = max(dp[i-1], dp[i-2] + a[i]). Then reduce O(n) space to two rolling variables. For longest increasing subsequence, give O(n^2) DP and the O(n log n) tails array with binary search.
- Edge cases: empty array, a single element, duplicates, and integer overflow on large sums in Java (use long).
Follow-up
- Return the start and end indices of the maximum subarray, not just the sum.
- Solve maximum subarray sum on a circular array (max of Kadane and total minus minimum subarray, unless every element is negative).
- Reconstruct the actual choices from your DP table.
Given a string, find the longest substring without repeating characters.
Given a string, find the longest substring without repeating characters.
Approach
- Sliding window [left, right] with a map from character to its last seen index. For each right, if s[right] was seen at an index >= left, set left = lastIndex + 1. Then record the index and update best = max(best, right - left + 1).
- Write left = max(left, last[c] + 1) so left never moves backwards. 'abba' is the test that catches the bug: at the final 'a', the stale index 0 must not pull left back.
- Complexity: O(n) time because each index enters the window once; O(min(n, alphabet)) space. Compare it with the O(n^2) brute force that grows a set from every start index.
- Edge cases: empty string returns 0, all-identical characters return 1, all-distinct return n. In JavaScript, string length counts UTF-16 code units, so emoji count as two unless you iterate by code point.
- For a fixed ASCII alphabet, a 128-entry int array works in place of the hash map and avoids hashing overhead.
Follow-up
- Return the substring itself, and the first one if several share the maximum length.
- Find the longest substring with at most k distinct characters.
- How would you handle the input arriving as a stream that cannot be stored?
Demonstrate search and traversal algorithms on binary trees and graph structures.
Demonstrate search and traversal algorithms on binary trees and graph structures.
Approach
- Binary trees: preorder, inorder and postorder DFS, both recursive and iterative with an explicit stack. Level-order BFS uses a queue and processes one level per loop by reading the queue size first. Inorder traversal of a BST yields sorted order. BST search is O(h): log n when balanced, n when skewed.
- Graphs: store an adjacency list. BFS with a visited set gives shortest paths in an unweighted graph; DFS gives connectivity, components and topological order. Both are O(V + E). Mark nodes visited when enqueued, not when dequeued, to avoid duplicate queue entries.
- Directed cycle detection: three-colour DFS where an edge to a grey (in-progress) node is a back edge, or Kahn's algorithm, which finds a cycle when fewer than V nodes are output. Undirected graphs: track the parent in DFS, or use union-find.
- Weighted shortest paths: Dijkstra with a binary heap is O((V + E) log V) and requires non-negative weights. Bellman-Ford handles negative edges in O(VE) and detects negative cycles.
- Edge cases: disconnected graphs (start a traversal from every unvisited node), self-loops, and recursion depth on a skewed tree or long path, where an iterative version is safer.
Follow-up
- Write iterative inorder traversal without recursion.
- Find the lowest common ancestor of two nodes in a binary tree, then in a BST.
- Count the islands in a grid, and say whether BFS or DFS fits better.
Explain the difference between process synchronization, semaphores, and mutexes in operating systems.
Explain the difference between process synchronization, semaphores, and mutexes in operating systems.
Approach
- Frame synchronization as the problem: concurrent threads or processes touching shared state cause race conditions, so a critical section needs mutual exclusion, progress and bounded waiting. Mutexes and semaphores are two tools for this.
- Mutex: a lock with ownership. The thread that acquires it must release it, and it protects one critical section. Mention recursive mutexes and priority inheritance as variants.
- Semaphore: an integer counter with wait/P (decrement, block at zero) and signal/V (increment, wake a waiter), with no ownership, so any thread can signal. A counting semaphore limits access to N resources such as a connection pool. A binary semaphore is often used for signalling between threads.
- Show the classic combination, a bounded producer-consumer buffer: an 'empty' semaphore initialised to capacity, a 'full' semaphore initialised to 0, and a mutex around the buffer. Condition variables must be waited on inside a while loop because of spurious wakeups.
- Deadlock: the four Coffman conditions (mutual exclusion, hold and wait, no preemption, circular wait). Prevent it with a global lock order or tryLock with a timeout. Note that cross-process sync needs named or shared-memory primitives, such as POSIX sem_open.
Follow-up
- Implement a thread-safe bounded blocking queue in your language.
- Why is a binary semaphore not a drop-in replacement for a mutex?
- When would a spinlock beat a blocking mutex?
How does the JavaScript event loop work, and how do promises and `async/await` handle asynchronous execution?
How does the JavaScript event loop work, and how do promises and async/await handle asynchronous execution?
Approach
- JavaScript runs on one call stack. Timers and I/O are handled by the browser or by libuv in Node, which queue callbacks. The event loop takes one macrotask, then drains the whole microtask queue before the next macrotask (and, in browsers, before rendering).
- Promise reactions (.then/.catch and the continuation after await) are microtasks. setTimeout callbacks are macrotasks. So synchronous logs print first, then promise callbacks, then setTimeout(fn, 0), even with a zero delay.
- An async function runs synchronously until its first await, always returns a promise, and resumes as a microtask. A thrown error becomes a rejection that try/catch around await can handle.
- Node specifics: process.nextTick callbacks run before promise microtasks. libuv phases include timers, poll and check (setImmediate). CPU-heavy work blocks every callback, so move it to worker_threads.
- Pitfalls: awaiting inside a loop serialises independent calls (use Promise.all, or Promise.allSettled when partial failure is fine), unhandled rejections, and microtasks that keep queuing microtasks, which starve rendering and timers.
Follow-up
- Predict the output order of a snippet that mixes setTimeout, Promise.resolve().then, an async function and console.log.
- Write a helper that runs async tasks with a concurrency limit of N.
- How would you find what is blocking the event loop in a Node service?
Explain database normalization, indexing strategies, and write a SQL query to find the second-highest salary i
Explain database normalization, indexing strategies, and write a SQL query to find the second-highest salary in an employee table.
Approach
- Normalization: 1NF means atomic values and no repeating groups; 2NF removes partial dependence on part of a composite key; 3NF removes transitive dependence through non-key columns; BCNF requires every determinant to be a candidate key. The trade-off: denormalize for read-heavy reporting and accept update anomalies.
- Indexing: B-tree indexes serve equality and range filters plus ORDER BY. Composite indexes follow the leftmost-prefix rule, and a covering index allows an index-only scan. Every index slows writes and costs storage. Wrapping the column in a function defeats a plain index unless you add an expression index.
- Second-highest salary: SELECT MAX(salary) FROM employee WHERE salary < (SELECT MAX(salary) FROM employee); This returns NULL when there is no second distinct value, and MAX already ignores NULL salaries.
- Alternative: SELECT DISTINCT salary FROM employee WHERE salary IS NOT NULL ORDER BY salary DESC LIMIT 1 OFFSET 1. Wrap it in a scalar subquery to get NULL instead of zero rows. The IS NOT NULL filter matters because PostgreSQL sorts NULLs first under DESC by default.
- Generalise to the Nth highest with DENSE_RANK() OVER (ORDER BY salary DESC) = N. Use DENSE_RANK rather than ROW_NUMBER so tied salaries count as one value. Add PARTITION BY department_id for a per-department version.
Follow-up
- Return the second-highest salary for each department, including departments that have only one distinct salary.
- Which index would make this query cheap, and how does the plan change with it?
- When would you deliberately denormalize this schema?
Contrast inner joins, outer joins, and explain how indexing impacts query performance under high load.
Contrast inner joins, outer joins, and explain how indexing impacts query performance under high load.
Approach
- Semantics: INNER JOIN keeps only matched rows. LEFT JOIN keeps every left row and fills unmatched right columns with NULL. RIGHT JOIN is the mirror. FULL OUTER keeps unmatched rows from both sides.
- Anti-join for 'rows with no match': LEFT JOIN ... WHERE right.id IS NULL, or NOT EXISTS. Avoid NOT IN when the subquery result actually contains a NULL: x NOT IN (..., NULL) evaluates to UNKNOWN rather than TRUE, so no rows come back.
- A common bug: a filter on the right table placed in WHERE turns a LEFT JOIN into an inner join. Put that condition in the ON clause. Also, joining a one-to-many table before aggregating inflates SUM and COUNT, so aggregate first or count distinct keys.
- Physical joins: nested loop with an index on the inner side (small outer input), hash join (equality joins on larger inputs, bounded by memory), merge join (inputs already sorted). Index foreign-key columns and read EXPLAIN ANALYZE to see which join the planner picked.
- Under high load, indexes cut read cost, but each INSERT or UPDATE must maintain every index, adding write amplification, page splits and contention. Index for the hottest queries only, prefer covering indexes, and keep statistics fresh (ANALYZE) so plans stay good.
Follow-up
- Write a query that finds user accounts with no activity in any of three transaction tables over the last 90 days.
- Your query ignores an index you created. List the reasons that can happen.
- How do you choose the column order of a composite index?
Why do you want to join ABC, and how does this role align with your long-term career growth?
Why do you want to join ABC, and how does this role align with your long-term career growth?
Approach
- Use three parts: what draws you to this work, how your experience maps to it, and what you want to grow into over the next few years.
- Anchor it in what candidates report about the role: work across backend, frontend and cloud, with a stack that includes Java, Python, JavaScript, React, Node.js, Docker, Kubernetes and AWS. Name the parts you have shipped and the parts you want to deepen.
- Research the specific team and product from public sources before the call, and cite something concrete. Generic praise, or an answer that would work for any employer, adds nothing.
- Make growth concrete, for example moving from feature work to owning a service end to end, including deployment and monitoring, and ask how the team supports that path.
- Do not lead with pay or brand, and do not state facts about the company you cannot back up.
Follow-up
- Why are you leaving your current role?
- Where do you want to be in five years, technically?
- What other roles are you considering, and how does this one compare?
Describe the primary Object-Oriented Programming (OOP) principles: Abstraction, Encapsulation, Inheritance, an
Describe the primary Object-Oriented Programming (OOP) principles: Abstraction, Encapsulation, Inheritance, and Polymorphism.
Approach
- Define each principle with a small code example. Abstraction: a PaymentMethod interface with charge(amount), so callers do not know the implementation. Encapsulation: a BankAccount with a private balance changed only through withdraw/deposit, which enforce the invariant. Inheritance: a subclass that reuses and extends a base class (an is-a relation). Polymorphism: one call dispatching to different overrides at runtime.
- Separate the commonly confused pair: abstraction hides complexity behind a contract (what), while encapsulation protects state and enforces invariants (how). In Java, distinguish runtime polymorphism (overriding) from compile-time overloading.
- Give the trade-offs: prefer composition over deep inheritance (the fragile base class problem), and respect Liskov substitution. Square extending Rectangle breaks callers that set width and height independently.
- Cover the language differences. Java has single class inheritance plus multiple interfaces. Python uses duck typing and multiple inheritance resolved by C3 MRO, and offers only name mangling (__x) as a privacy convention. JavaScript classes are syntax over prototypes.
Follow-up
- When would you choose an abstract class over an interface?
- Model a parking lot or library system and show where each principle appears.
- Which SOLID principle does your inheritance example risk breaking?
How do TCP/IP, HTTP, and RESTful protocols operate during client-server communication?
How do TCP/IP, HTTP, and RESTful protocols operate during client-server communication?
Approach
- Walk one request end to end: DNS resolution, TCP three-way handshake (SYN, SYN-ACK, ACK), TLS handshake for HTTPS (one round trip in TLS 1.3), the HTTP request line, headers and body, then the response status, headers and body.
- Separate the layers. IP routes packets best-effort. TCP adds a reliable, ordered byte stream through sequence numbers, ACKs, retransmission, flow control (receive window) and congestion control. UDP gives none of these.
- HTTP versions: HTTP/1.1 reuses persistent connections but has head-of-line blocking per connection. HTTP/2 multiplexes streams over one TCP connection with HPACK header compression. HTTP/3 runs over QUIC on UDP, which removes TCP-level head-of-line blocking.
- REST: resources named by URLs and stateless requests. GET is safe and idempotent; PUT and DELETE are idempotent; POST is not. Use status codes precisely (201, 204, 400, 401 vs 403, 404, 409, 429, 503), caching through Cache-Control and ETag, and a versioning scheme.
- Close with connection teardown (FIN exchange, TIME_WAIT on the closing side) and why keep-alive or connection pools avoid repeated handshake cost.
Follow-up
- What happens, step by step, after you type a URL and press Enter?
- PUT vs PATCH vs POST: which are idempotent, and why does it matter for retries?
- When would you choose UDP over TCP?
Demonstrate event bubbling and capturing phases in DOM manipulation.
Demonstrate event bubbling and capturing phases in DOM manipulation.
Approach
- Three phases: capture (from window down to the target's parent), target, then bubble (back up to window). addEventListener(type, fn, { capture: true }) or a third argument of true registers for capture. The default is bubble.
- Demonstrate with three nested divs, each with a capture and a bubble listener that log their names. A click on the inner div logs outer, middle, inner on the way down, then inner, middle, outer on the way up.
- event.target is the element that was clicked; event.currentTarget is the element whose listener is running. stopPropagation halts travel to further elements, stopImmediatePropagation also skips remaining listeners on the same element, and preventDefault cancels the browser's default action without affecting propagation.
- Event delegation: one listener on a parent list, using event.target.closest('li') to handle current and future children, with fewer listeners and no rebinding on re-render.
- Exceptions: focus and blur do not bubble (use focusin and focusout), nor do mouseenter and mouseleave. React wraps native events in synthetic events, attached at the root container since React 17, and offers onClickCapture for the capture phase.
Follow-up
- Implement delegated click handling for a list whose items are added dynamically.
- Why can calling stopPropagation break an outside-click handler or analytics listener higher up?
- How do you remove a listener registered with capture: true?
Explain the component lifecycle and state management patterns in React.
Explain the component lifecycle and state management patterns in React.
Approach
- Class lifecycle: mounting (constructor, render, componentDidMount), updating (shouldComponentUpdate, render, componentDidUpdate) and unmounting (componentWillUnmount). In function components, useEffect runs after paint, its cleanup runs before the next run and on unmount, and the dependency array decides when it re-runs. useLayoutEffect runs after DOM mutation but before paint.
- A re-render is triggered by a state change, a parent re-render or a context value change. React.memo, useMemo and useCallback skip unnecessary work. Stable keys drive list reconciliation, and index keys break when items reorder.
- State patterns: useState for local state, useReducer for multi-field transitions, lifting state to the nearest common parent, Context for low-frequency global values (every consumer re-renders when the value changes), an external store such as Redux Toolkit or Zustand for shared client state, and a fetching cache such as React Query for server state.
- Pitfalls: stale closures in effects, missing dependencies, and reading state right after setting it. Updates are batched, so use the functional form setCount(c => c + 1). StrictMode in development mounts, unmounts and remounts components to surface effects without cleanup.
Follow-up
- This useEffect loops forever. Why, and how do you fix it?
- When is Context enough, and when would you add a dedicated state library?
- Controlled vs uncontrolled inputs: which would you use for a large form?
How do you construct secure microservices using Node.js/Express or Java Spring Boot?
How do you construct secure microservices using Node.js/Express or Java Spring Boot?
Approach
- Edge layer: an API gateway or ingress terminates TLS, applies rate limits and authenticates requests. Each service still validates the caller's token itself instead of trusting the network, and service-to-service traffic can use mTLS.
- Express: middleware that verifies the JWT signature, issuer, audience and expiry (for example with the jose library) before any route handler, then checks roles or scopes per route. Spring Boot: Spring Security as an OAuth2 resource server, a SecurityFilterChain bean, and @PreAuthorize for method-level checks.
- Input handling: validate every payload against a schema (zod or Joi; Bean Validation with @Valid), use parameterised queries or ORM bind parameters against SQL injection, cap request body size, set security headers (helmet), and keep an explicit CORS allow-list.
- Runtime hygiene: load secrets from a secret manager or injected environment, never from source. Give each service a least-privilege database user, run containers as non-root, and scan dependencies in CI (npm audit, OWASP Dependency-Check).
- Observability without leaks: structured logs with correlation IDs that never contain tokens or personal data, audit logs for sensitive actions, and a central error handler that hides stack traces from clients.
Follow-up
- A JWT has leaked. How do you revoke it in a stateless design?
- How do two internal services authenticate to each other?
- How would you protect the login endpoint against credential stuffing?
What mechanisms are used to manage authentication and authorization (e.g., JSON Web Tokens or OAuth)?
What mechanisms are used to manage authentication and authorization (e.g., JSON Web Tokens or OAuth)?
Approach
- Separate authentication (who you are) from authorization (what you may do). Compare server-side sessions (a cookie plus a session store, easy to revoke, needs a shared store across instances) with self-contained tokens.
- JWT: header.payload.signature, base64url-encoded. It is signed, not encrypted, so the payload is readable. Verify the signature with HS256 (shared secret) or RS256/ES256 (public key from a JWKS endpoint), check exp, nbf, iss and aud, and reject alg 'none' or unexpected algorithms.
- Revocation is the weak point of stateless tokens, so use short-lived access tokens with rotating refresh tokens, or a denylist keyed by jti for urgent revocation.
- OAuth 2.0 is a delegated authorization framework with four roles: resource owner, client, authorization server and resource server. Use the authorization code flow with PKCE for SPAs and mobile apps, and client credentials for service-to-service calls. The implicit flow is deprecated. OpenID Connect adds an ID token for login.
- Token storage and enforcement: an httpOnly, Secure, SameSite cookie avoids exposing the token to XSS but needs CSRF protection, while localStorage is readable by any injected script. Enforce RBAC or scopes on the server for every request.
Follow-up
- How do you log a user out everywhere when access tokens are stateless JWTs?
- What attack does PKCE prevent?
- Where would you store tokens in a React single-page app, and why?
Describe the core components of Kubernetes architecture (e.g., API server, etcd, kubelet, worker nodes).
Describe the core components of Kubernetes architecture (e.g., API server, etcd, kubelet, worker nodes).
Approach
- Control plane: kube-apiserver is the REST front end and the only component that talks to etcd, and it runs authentication, authorization and admission. etcd is a Raft-based consistent key-value store holding cluster state. kube-scheduler binds pending pods to nodes using resource requests, affinity and taints/tolerations. kube-controller-manager runs reconciliation loops (Deployment, ReplicaSet, Node controllers).
- Worker nodes: the kubelet makes sure the containers in each assigned PodSpec are running, runs liveness and readiness probes and reports status. A container runtime (containerd or CRI-O) runs through the CRI. kube-proxy implements Service virtual IPs with iptables or IPVS rules.
- Trace kubectl apply on a Deployment: the API server stores it in etcd, the Deployment controller creates a ReplicaSet, the ReplicaSet controller creates pods, the scheduler binds them to nodes, and each kubelet starts the containers. Everything is declarative desired state reconciled in loops.
- Networking: every pod gets its own IP from the CNI plugin and can reach other pods directly across nodes. A Service provides a stable virtual IP and a DNS name through CoreDNS, and an Ingress routes external HTTP traffic.
- Failure behaviour: when a node stops reporting, it is marked NotReady and its pods are evicted after a timeout, and the ReplicaSet recreates them elsewhere. etcd needs a majority quorum, so three members tolerate one failure and five tolerate two.
Follow-up
- Liveness vs readiness vs startup probes: what does each one control?
- When would you use a StatefulSet or a DaemonSet instead of a Deployment?
- What happens to running workloads if the API server goes down?
How do you structure a Dockerfile and optimize container image sizes for production deployments?
How do you structure a Dockerfile and optimize container image sizes for production deployments?
Approach
- Order instructions from least to most frequently changing: base image, system packages, then copy only the dependency manifest (package.json and lockfile, pom.xml, requirements.txt) and install, then copy the source. A code change then reuses the cached dependency layer.
- Use multi-stage builds: compile in a full JDK/Maven or Node stage, then copy only the artifact into a slim runtime image (JRE, distroless or slim). Alpine uses musl libc, which can break some native modules and Python wheels.
- Shrink layers: add a .dockerignore (node_modules, .git, build output), install and clean up in the same RUN (apt-get install --no-install-recommends ... && rm -rf /var/lib/apt/lists/*) because deleting files in a later layer does not reduce size, and use npm ci --omit=dev or pip install --no-cache-dir.
- Production hygiene: pin the base image by tag or digest, switch to a non-root USER, and use exec-form CMD/ENTRYPOINT so the app is PID 1 and receives SIGTERM. Never bake secrets into ENV, ARG or layers; use BuildKit --mount=type=secret.
- Verify the result with docker history or dive to see which layer is large, and scan the image (for example with Trivy) before it ships.
Follow-up
- Every build reinstalls dependencies even though only source files changed. Why?
- How do you give a build step a private registry token without leaving it in the image?
- Distroless vs Alpine: what do you gain and lose for debugging?
Explain how you would manage secrets and cloud access permissions in environments like AWS or Azure.
Explain how you would manage secrets and cloud access permissions in environments like AWS or Azure.
Approach
- Keep secrets out of code, images and repos. Store them in AWS Secrets Manager or SSM Parameter Store (SecureString) on AWS, or Key Vault on Azure, encrypted with KMS-managed keys and fetched at runtime. Secrets Manager supports scheduled rotation through a Lambda function.
- Prefer identities to static keys: IAM roles via EC2 instance profiles, ECS task roles and EKS IRSA or Pod Identity on AWS, managed identities on Azure. Use short-lived credentials from STS AssumeRole, and OIDC federation from CI instead of long-lived access keys.
- Least privilege: scope policies to specific actions and resource ARNs with conditions, separate accounts or subscriptions per environment, and use permission boundaries or service control policies as guardrails.
- Kubernetes: Secrets are only base64-encoded by default, so enable encryption at rest for etcd, restrict get/list on secrets with RBAC, or sync values from the cloud manager with the External Secrets Operator or the Secrets Store CSI driver.
- Detection and response: audit access with CloudTrail or the Azure Activity Log, run secret scanning (for example gitleaks) in CI, and keep a leaked-key runbook: revoke, rotate, then review what the key accessed.
Follow-up
- An access key was committed to a public repo. What do you do, in order?
- How do you rotate a database password with no downtime?
- How does a pod on EKS get AWS credentials without a stored key?
How do you implement automated CI/CD pipelines and monitor distributed applications using logging tools?
How do you implement automated CI/CD pipelines and monitor distributed applications using logging tools?
Approach
- Pipeline shape: on every pull request, lint, unit tests, build, static analysis and dependency scanning. On merge, build one immutable image tagged with the commit SHA, push it to a registry, deploy to staging, run integration and smoke tests, then promote that same artifact to production.
- Release safety: rolling, blue-green or canary deploys with automated rollback when error rate or latency crosses a threshold, and feature flags to separate deploying code from releasing behaviour. Database migrations follow expand-then-contract so the old and new versions both work during rollout.
- Observability: structured JSON logs carrying a trace or correlation ID, shipped to a central store (ELK/OpenSearch, CloudWatch Logs, Loki), plus metrics (rate, errors, duration per endpoint) and distributed tracing with OpenTelemetry so one slow request can be followed across services.
- Alert on user-facing symptoms tied to SLOs (error-budget burn rate) rather than every CPU spike, and link each alert to a dashboard and a runbook.
- Name tools you have used (GitHub Actions, Jenkins, GitLab CI; Argo CD for GitOps on Kubernetes) and explain why they fit, rather than listing them.
Follow-up
- How do you roll back a release that already ran a schema migration?
- Flaky tests keep blocking the pipeline. What do you change?
- A request is slow somewhere across five services. How do you find where?
Walk through designing a fault-tolerant, scalable web application architecture from scratch.
Walk through designing a fault-tolerant, scalable web application architecture from scratch.
Approach
- Start with requirements and numbers: core features, daily users, read/write ratio, peak QPS, data size, latency and availability targets. Do a back-of-envelope estimate before you draw anything.
- Baseline components: DNS and a CDN for static assets; a load balancer across multiple availability zones; stateless app servers in an autoscaling group, with session data in Redis or in tokens; a cache-aside Redis tier with TTLs; a primary relational database with read replicas and automatic failover; object storage for files; and a queue (SQS or Kafka) for slow or bursty work.
- Fault tolerance: remove single points of failure, use health checks, timeouts and retries with exponential backoff and jitter (only on idempotent operations), add circuit breakers and bulkheads, degrade gracefully, and run backups with tested restores against a stated RPO and RTO.
- Scaling data: read replicas bring replication lag, so handle read-your-writes. Shard by a key that spreads load and watch for hot keys. Guard the cache against stampedes with request coalescing or jittered TTLs.
- Operations: rate limiting at the edge, queue-based load levelling for traffic spikes, canary deploys, and dashboards and alerts on the golden signals.
Follow-up
- The primary database fails mid-write. What does the user see, and what does the system do?
- Traffic jumps tenfold in a minute. Which component saturates first?
- What changes if this must run active-active across two regions?
Describe a complex project you worked on recently, detailing the technical architecture and your specific cont
Describe a complex project you worked on recently, detailing the technical architecture and your specific contributions.
Approach
- Structure: the problem and its constraints (users, real scale figures, deadline), then the architecture described as components, data flow, storage and interfaces, then a clear split between the team's work and yours, told in first person singular.
- Pick two technical decisions you drove, such as a queue vs a synchronous call or relational vs document storage. Name the alternatives you rejected, why, and the cost you accepted.
- Give measurable outcomes (latency, error rate, cost, delivery date) and one thing that went wrong or that you would design differently now.
- Be ready to go two levels deeper on any component you name: schema, failure handling, testing and deployment. Only name what you can defend.
- The answer fails when it is a list of technologies with no reasons, or when plural pronouns hide what you personally built.
Follow-up
- What in this design breaks first at ten times the load?
- What would you redesign if you started this project again today?
- What was the hardest bug in this project, and how did you find it?
Every query on one table stalls for forty seconds mid-deploy
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
- 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.
- 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.
- 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.
- 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?
The plan follows the reported stages and the five question groups: coding first, then core CS and databases, web, cloud and design, and finally behavioral stories and a mixed mock. Each day lists what to produce.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and choose your tools
- Write the six reported stages in order, one line each on what it covers, and mark the one you are least ready for.
- Pick one coding language from the reported set (Java, Python, C++ or JavaScript) and list the standard-library structures you will use: ordered map, deque, heap, set.
- List the projects on your resume and pick the two you will defend in detail.
Deliverable: A one-page loop map, a named coding language with its data-structure cheat sheet, and a shortlist of two projects.
02Coding I: cache, linked list, sliding window
- Implement an LRU cache with a hash map plus a hand-built doubly linked list. Then write a second version with your language's recency-ordered container: LinkedHashMap with accessOrder=true in Java, OrderedDict in Python, or a JS Map with delete-then-set. C++ has no such container, so C++ users write only the std::list plus unordered_map version.
- Reverse a singly linked list iteratively and recursively, and state the stack depth of the recursive version.
- Solve the longest substring without repeating characters with a sliding window and say what the window invariant is.
Deliverable: Working code for the LRU cache (two versions, or the list-plus-map version for C++), the list reversal (two versions) and the substring problem, each with complexity written beside it.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Coding II: arrays, dynamic programming, trees and graphs
- Find the maximum sub-array sum in O(n), then write one two-pointer array problem.
- Solve one dynamic programming problem in memoized form and in table form.
- Write BFS and DFS on a binary tree and on a graph, then add cycle detection for a directed graph.
Deliverable: A solutions file with each problem's code, its complexity and its edge cases listed.
Practice prompt ↗Practice prompt ↗04Core CS and databases
- Write the second-highest salary query two ways and test it with duplicate salaries and a single-row table.
- Write inner and left join queries that find inactive user accounts across two tables, and say which index each uses.
- Explain in writing how process synchronization (the problem) differs from mutexes and semaphores (the tools), then cover deadlock and its four Coffman conditions as a separate item.
- Write one short code example for each OOP principle, then outline the path of a request from TCP handshake to a REST response.
Deliverable: Tested SQL for both query tasks plus a one-page written explanation covering concurrency, OOP and TCP/HTTP/REST.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05Web development: JavaScript, React, secure services
- Predict the output of a snippet that mixes setTimeout, promises and async/await, then run it and explain any difference.
- Build a small HTML page that logs capture and bubble order on nested elements and shows stopPropagation.
- Map the React component lifecycle to hooks and compare local state, context and a store.
- Outline how a Node.js/Express or Spring Boot service validates a JWT, and where OAuth fits.
Deliverable: A tested event-loop snippet with explanation, a working event-order page, a lifecycle-to-hooks table and a one-page authentication flow.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Cloud, containers and system design
- Draw the Kubernetes control plane and worker node and label what each component does.
- Write a multi-stage Dockerfile for a Node.js or Java service and note what each step removes from the final image.
- Draw a fault-tolerant web architecture with a load balancer, cache, queue and replicated database, then mark what happens when each part fails.
- Describe a CI/CD pipeline with secret handling and logging, then work through PracHub's practice scenario on queries stalling mid-deploy.
Deliverable: A control-plane diagram, a multi-stage Dockerfile, an architecture diagram with failure notes, and a written pipeline and secrets outline.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral stories and a mixed mock
- Write STAR outlines for the conflict, technical debt and failed-deployment prompts, each with a measurable result.
- Write the project walkthrough for your most complex recent project and a why-ABC answer built only from facts you can verify.
- Run a mixed mock aloud: one coding problem, one SQL query and one design discussion, then list questions to ask the team.
Deliverable: Three STAR outlines, a project walkthrough, a why-ABC answer and a recorded mock with notes on weak spots.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report project deep dives inside the technical stages and Managerial Rounds focused on team fit and overall alignment. The reported behavioral prompts form their own group and are not tied to a particular stage. For an engineering role the stories that matter show your own decisions: what you chose, what it cost, how you worked with others and what you changed afterwards. Prepare the reported prompts first, then use the extra prompt to cover code review, which the role description mentions.
Tell me about a time you faced a technical conflict or disagreement on a team and how you resolved it.
Tell me about a time you faced a technical conflict or disagreement on a team and how you resolved it.
Approach
- Choose a disagreement where you were a party and the stakes were technical: a schema design, a synchronous call versus a queue, a library choice, a testing strategy. State each position fairly in one sentence so it is clear the other view had merit.
- Show the move from opinion to evidence. Name what you did: a small benchmark, a spike or prototype, a load test, or a short written comparison of options on criteria such as latency, operating cost, team familiarity and how easy the choice is to reverse.
- Say who made the final call and what you did after it. If you were overruled, describe how you committed to the decision and helped it succeed. If your view won, show how you brought the other person along rather than just being right.
- Use STAR but spend most of the time on Action and Result: the outcome in numbers or behavior (error rate, build time, a shipped date), and the state of the working relationship afterwards.
- The mistake that sinks it is a story that turns the other engineer into a villain, or one with no real disagreement. Keep the tone about the problem, not the person.
Follow-up
- What if the other engineer had turned out to be right?
- What would you have done if the evidence had been inconclusive?
- How did the working relationship look afterwards?
How do you approach prioritizing technical debt alongside new feature requirements under tight deadlines?
How do you approach prioritizing technical debt alongside new feature requirements under tight deadlines?
Approach
- Start with a way of sorting debt. Debt that slows work in code you are about to change, causes incidents or blocks a planned feature is worth paying now. Debt in code nobody touches can wait. Say this before telling any story.
- Make debt visible and sized: a ticket with an estimate and the cost of leaving it, such as extra days on each coming feature or a repeating incident. Where the feature touches the same code, pay the debt inside that change, protected by tests. Otherwise reserve explicit capacity instead of hoping for spare time.
- Describe how you negotiate with product and management. Present a trade-off in time and risk, then offer options: cut scope, phase the delivery, or ship a narrower version with a dated cleanup. Do not quietly cut corners and do not refuse the deadline.
- Anchor it in a real example: what you deferred, what you paid, and how you tracked the result with something checkable such as build time, incident count or cycle time.
- Avoid the absolute answers: debt always comes first, or features always come first. Both signal that you have not made this trade-off under pressure.
Follow-up
- How would you convince a product manager who sees refactoring as no user value?
- What do you do when the deadline cannot move and the debt is causing bugs in the feature itself?
- How do you stop deferred items from piling up indefinitely?
Describe a situation where a system or production deployment failed and how you troubleshot and resolved the i
Describe a situation where a system or production deployment failed and how you troubleshot and resolved the issue.
Approach
- Choose a failure you handled personally and give the sequence: how it was detected (alert, error rate, user report), then stabilization first. Say what you did to stop the damage, such as rolling back, switching a feature flag off or shifting traffic, before you hunted for the cause.
- Describe the diagnosis as a method, not a hunch. Compare what changed in the release (code, configuration, database migration, dependency, secret), read logs, metrics and traces around the start time, reproduce in a staging environment, and narrow by bisecting. If your story involved containers or Kubernetes, name the actual checks you ran on the deployment.
- State the root cause plainly, including your own part if you had one, and the fix: a rollback, a forward patch, a corrected config. Explain why you chose that option over the other.
- Close with prevention that is specific: a regression test, a canary or staged rollout, an automated rollback trigger, a pre-deploy check, a written postmortem. Include how you updated stakeholders during the incident.
- The mistake that sinks it is a story where the fix was heroics and nothing changed afterwards, or where blame sits entirely with someone else.
Follow-up
- How did you decide between rolling back and shipping a forward fix?
- How would you have detected the problem sooner?
- What did you tell stakeholders while the incident was still open?
- 01
Tell me about a time you faced a technical conflict or disagreement on a team and how you resolved it.
- 02
How do you approach prioritizing technical debt alongside new feature requirements under tight deadlines?
- 03
Describe a situation where a system or production deployment failed and how you troubleshot and resolved the issue.
- 04
Describe a complex project you worked on recently, detailing the technical architecture and your specific contributions.
- 05
Why do you want to join ABC, and how does this role align with your long-term career growth?
- 06
Tell me about a code review that changed how you approached a problem.
How many rounds does the ABC Software Engineer loop have?
Candidates report six stages over about 4-6 weeks: Online Assessment, Technical Stages, System Architecture Evaluation, Onsite or Virtual Panels, Managerial Rounds and Offer Extension. Reports add that team and location can alter the sequence, so ask your recruiter for your own schedule.
PracHub Software Engineer practice ↗Which programming language should I use?
Reports name Java, Python, C++ and JavaScript for coding. Choose the one you are fastest in and learn its standard library: the ordered map, deque and heap matter for the LRU cache and graph questions. Know your language's memory and concurrency behavior too, since follow-up questions can move to thread safety.
PracHub Software Engineer practice ↗What technologies should I know beyond algorithms?
The role lists Java, Python, JavaScript, React, Node.js, Docker, Kubernetes and AWS, with Spring Boot, Azure, GCP, CI/CD and Terraform as nice-to-have. The reported questions cover the JavaScript event loop, React lifecycle and state, secure Node.js or Spring Boot services, JWT and OAuth, Kubernetes components, Dockerfiles and secrets management. Go deep on the ones on your resume.
PracHub Software Engineer practice ↗How much SQL and CS fundamentals should I expect?
A lot of the reported material sits here: normalization, indexing, inner and outer joins, a second-highest-salary query, process synchronization, semaphores and mutexes, OOP principles and TCP/IP with HTTP and REST. Reported tips say these come up even for frontend and full-stack candidates, so schedule a full day for them.
PracHub Software Engineer practice ↗Is the system design stage asked at every level?
Candidates describe the System Architecture Evaluation as varying by seniority. Whatever your level, the reported questions include cloud and architecture topics: a fault-tolerant web application design, Kubernetes components, Dockerfile optimization and CI/CD with monitoring. Practise one full design on a whiteboard and one on a virtual canvas.
PracHub Software Engineer practice ↗How should I prepare for the project deep dive?
Choose two projects and outline the architecture, your own contribution, the alternatives you rejected and what you would change now. Reported tips say to expect follow-up questions on every project, technology and decision on your resume, so be ready to explain why each tool was chosen. Use STAR for stories about conflict, debt and failures.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01ABC Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
XYZ Software Engineer Interview Guide
What XYZ asks Software Engineer candidates, from reported rounds and questions.
TELUS Digital AI Community Software Engineer Interview Guide
What TELUS Digital AI Community asks Software Engineer candidates, from reported rounds and questions.
Raytheon Technologies Corporate Headquarters Software Engineer Interview Guide
What Raytheon Technologies Corporate Headquarters asks Software Engineer candidates, from reported rounds and questions.
Photon Software Engineer Interview Guide
What Photon asks Software Engineer candidates, from reported rounds and questions.