Alten Calsoft Labs Software Engineer Interview Guide

The 60-second brief

Alten Calsoft Labs is described as working in product engineering, digital transformation and technical consulting. The engineering work mentioned ranges from enterprise backends and microservices to embedded and automotive software, networking and web front ends, sometimes for outside corporate clients. The stack depends on the track: Java with Spring Boot and Hibernate, .NET and ASP.NET, C/C++, Python, JavaScript with React, or hardware verification in SystemVerilog and UVM.

This guide is for candidates interviewing for a Software Engineer position at Alten Calsoft Labs, on any of the tracks candidates mention: enterprise backend (Java or .NET), full-stack web, embedded and networking in C/C++, or hardware verification. It covers the reported rounds, the twenty questions candidates report (core data structures, language and framework internals, networking and embedded topics, project and behavioral questions), and a plan you can bend towards your own track.

Candidates report five stages: HR Screening, an Aptitude and Technical Test, Technical Rounds, a Client Interview and a Techno-Managerial or HR Round, over roughly 4-6 weeks. Reports differ on length and on how many stages apply, so confirm the exact path with your recruiter.

Focus areas

• Problem Solving (Coding/Logical Programs)
• OOPs (Object-Oriented Programming)
• Data Structures & Algorithms

Overview

The reported questions fall into four groups: core computer science (a linked-list traversal, a Kth-smallest search in a matrix, OOP concepts, deadlocks and race conditions, TCP versus UDP), enterprise backend topics (Java 8 streams, the Object class contract, dependency injection and IoC, microservices with an API gateway, SQL tuning), embedded and hardware topics (OSPF and STP, C/C++ memory and bit operations, AMBA and ARM, SystemVerilog and UVM, TCL and Python scripting), and project and client handling. Candidates report that the questions follow the stack and the resume, so your first job is to decide which track you are interviewing for and prepare that track in depth instead of skimming all four.

A topic breakdown that candidates share lists problem solving, OOP, data structures and algorithms, and Java 8 streams as the most common subjects, alongside the interview process itself. That is a good reason to be able to write a short, correct solution in your primary language and to explain it aloud: state the approach, the time and space cost, and the edge cases (an empty list, an even-length list, a matrix with duplicate values). It is also a reason to prepare mechanisms rather than definitions. For hashCode and equals, know what breaks when a mutable key changes inside a HashMap. For TCP and UDP, know which header fields exist and what the sender does when a segment is lost.

Candidates also describe a project deep dive and a stage with the client's own technical staff. Expect to explain the architecture of your main project, which parts you personally built, and the performance or defect problems you solved. The behavioral questions centre on deadline risk, feedback about a teammate, a difficult stakeholder and competing urgent tickets. Prepare one story for each, with numbers where you have them, and keep your resume honest: every technology on it is something you may be asked to explain.

The Alten Calsoft Labs interview process

These are the five stages candidates describe for this role. Which ones you meet, and how many technical interviews you get, varies by business unit and by whether the job is an internal product team or a client placement.

HR Screening

Candidates describe this as a first conversation, often by phone, covering your experience, location preference, notice period and fit with the domain. One description also says it checks basic computer science knowledge and logical reasoning. Treat it as the place to settle the practical questions: which track the job is (backend, full-stack, embedded, hardware), whether it is an internal project or a client placement, and which stack the client uses. Have a short walk through your resume ready, with the technologies you used most and the one project you can discuss in depth.

What to demonstrate

• Match between your experience and the domain track of the opening
• Practical constraints such as location preference and notice period
• Basic computer science and logical reasoning, where a loop includes it at this stage

How to prepare

• Write a short spoken summary of your resume that names your primary language, your strongest project and your exact role in it.
• List the technologies on your CV and mark the ones you could explain at the level of internals; trim or study the rest.
• Prepare questions for the recruiter: the track, whether the job is a client placement, the client's stack, and the remaining stages in writing.

Aptitude and Technical Test

Candidates describe an online or written test, mainly for freshers and junior to mid-level applicants, covering logical aptitude, computer science fundamentals and basic programming tasks. Experienced applicants are reported to skip it and go straight to technical interviews. Because the format is a test and not a conversation, accuracy and pace matter: practise short programs and fundamentals questions without an IDE or search, and write answers in the language you will use throughout the loop.

What to demonstrate

• Logical and aptitude reasoning
• Computer science fundamentals
• Basic programming tasks written without help

How to prepare

• Hand-write the linked-list middle-node traversal and the Kth-smallest-in-a-matrix search in your primary language, with no autocomplete.
• Rehearse short written answers on OOP pillars, deadlock versus race condition, and TCP versus UDP so you can produce them quickly.
• Do a set of logical-reasoning and number-series puzzles against a clock, since the test is reported to include aptitude.

Technical Rounds

Candidates report one to two technical interviews, by video call or telephone, focused on domain expertise and coding. Reports say the questions are tailored to your track and your resume, so the reported question set spans backend frameworks, concurrency and SQL, embedded and networking topics, and hardware verification, and candidates do not say which question belongs to which stage. Prepare the topics for your own track here. Without a shared editor, narrate your plan before you write, state complexity, and say plainly when you do not know a protocol detail or a language internal.

What to demonstrate

• Working code and clear reasoning on data structure and algorithm problems
• Depth in the language and framework you list on your resume
• Domain knowledge for your track: backend, embedded and networking, or hardware verification

How to prepare

• Pick your track and drill its reported questions aloud: for backend, streams, hashCode and equals, IoC, the API gateway role and SQL tuning; for embedded, pointers, bit manipulation, TCP/UDP, OSPF and STP.
• Solve the linked-list and matrix problems in two ways each, and be ready to compare their time and space costs.
• Practise explaining a deadlock and a race condition with a code example, plus how you would find each in a running service.

Client Interview

Candidates describe a conversation with the external client, covering project-specific requirements and cultural fit. Another account says technical leads or managers from the client side check your hands-on experience against their environment. Ask the recruiter beforehand about the client's stack, then prepare concrete examples of similar work you have built and be ready to talk about how you would communicate with a client team day to day.

What to demonstrate

• Fit of your hands-on experience with the client's project requirements
• Clarity when explaining technical ideas to people outside your own team
• Cultural fit with the client team, as candidates describe the stage

How to prepare

• Get the client's technology focus from your recruiter and build two short examples from your own work that match it.
• Rehearse the walk through your main project's architecture, naming your own contributions separately from the team's.
• Prepare a difficult-stakeholder story and a negative-feedback story, since this stage is reported to cover project requirements and cultural fit.

Techno-Managerial or HR Round

Candidates describe a closing discussion that mixes behavioral questions with the practical side of an offer: salary expectations, location needs and onboarding logistics. It is reported either as a techno-managerial discussion or as an HR round. Prepare your stories for deadline risk, teammate feedback and prioritisation, and decide beforehand what you will say about expectations and joining logistics.

What to demonstrate

• Behavioral answers about deadlines, feedback and prioritisation
• How you describe project decisions and their outcomes
• Alignment on salary expectations, location and joining details

How to prepare

• Write one story each for deadline risk, feedback about a teammate, a difficult client or stakeholder, and competing urgent tickets, each with a decision and a result.
• Decide your salary expectation, notice period and location constraints before the call, so you answer calmly.
• Prepare two questions about the team, the client engagement and onboarding.

Where candidates lose points

Listing technologies on the resume that you cannot explain below the surface

Candidates report questions drawn from the exact projects and tools on the CV. Before the loop, take each line and write one internal-level fact you could defend (how Spring creates a bean, why a bit mask works, what a UVM component does). Remove what you cannot discuss.

Solving the linked-list or matrix problem silently and skipping the edge cases

Say the approach first. For the middle node, use slow and fast pointers and state which middle you return for an even length. For the Kth smallest in a sorted matrix, compare a min-heap (about k log n) with binary search on value, and mention duplicates and k beyond the size.

Reciting definitions for hashCode and equals, IoC, TCP versus UDP or deadlock with no mechanism

Attach a failure or example to each: a mutable key that disappears from a HashMap after it changes, a constructor-injected bean that cannot be created because of a cycle, a lost TCP segment that is retransmitted while UDP drops it, and two threads taking two locks in opposite orders.

Preparing the wrong track, or all tracks thinly

Reports show the questions diverge between enterprise backend, embedded and networking, and hardware verification. Confirm the track and stack at the HR screening, then spend your time on that track's questions and on the shared core: data structures, OOP and concurrency.

Behavioral and client stories that blame others or stop before the outcome

For deadline risk, teammate feedback, a difficult stakeholder and prioritisation, state the decision you made, what you said to whom, and a measurable result. Describe the client or teammate's concern fairly, then your action.

Questions & practice

Given a single LinkedList, write an algorithm to find the middle element in a single traversal.

Medium · Core Computer Science & Data Structures

Approach

1. Use two pointers from the head: slow moves one node per step, fast moves two. When fast can no longer advance, slow sits on the middle. That is one pass, O(n) time and O(1) extra space.
2. Settle the even-length case before coding. With the loop condition while fast and fast.next, slow stops on the second middle (node 3 in 1-2-3-4). With while fast.next and fast.next.next, it stops on the first middle (node 2).
3. Handle the edge cases explicitly: an empty list returns null or raises, depending on the contract you agree; a single node is its own middle; a two-node list follows your even-length rule.
4. Name the alternatives and say why you rejected them: counting the length and then walking n/2 takes two traversals, and copying nodes into an array costs O(n) memory. Both break the single-traversal, no-extra-memory constraint.

Follow-up

• How would you delete the middle node in the same pass, given that you then need the node before it?
• How do the same two pointers detect a cycle, and how do you find the node where the cycle starts?
• What happens to your loop if the list turns out to contain a cycle?

Find the Kth smallest element in a two-dimensional array/matrix of integers.

Medium · Core Computer Science & Data Structures

Approach

1. Clarify the input first: are rows and columns sorted, or is it an arbitrary matrix? Are duplicates counted separately? Is k 1-based and guaranteed to be at most rows x cols?
2. Unsorted matrix: keep a max-heap of size k over all m*n values, which is O(mn log k) time and O(k) space. Or flatten it and run quickselect, which is O(mn) on average but O((mn)^2) in the worst case unless the pivots are randomised.
3. Rows and columns sorted: seed a min-heap with the first element of each of the first min(k, rows) rows. Pop k times; after each pop, push the right neighbour from the same row. That costs O(k log min(k, rows)).
4. Also sorted, with value search: binary search on the range [matrix[0][0], matrix[m-1][n-1]]. Count the elements <= mid with a staircase walk from the bottom-left corner in O(m + n). If count >= k, set hi = mid, else lo = mid + 1. lo always converges to a value that is in the matrix, and the total is O((m + n) log(max - min)).
5. Test with duplicates, k = 1, k = m*n, a single row and negative values. Compute mid as lo + (hi - lo) / 2 to avoid overflow.

Follow-up

• What changes if only the rows are sorted and the columns are not?
• Why is the binary-search answer always an actual matrix element, even though mid values may not be?
• How would you return the kth largest instead, or the k smallest values in order?

Explain core OOPs concepts and demonstrate how concepts like decorators or dynamic dispatch operate in your pr

Medium · Core Computer Science & Data Structures

Explain core OOPs concepts and demonstrate how concepts like decorators or dynamic dispatch operate in your primary language.

Approach

1. Define the four pillars with one concrete example each: encapsulation (private state behind methods that keep an invariant), abstraction (an interface hides the implementation), inheritance (an is-a relationship and code reuse), and polymorphism (one call site, many behaviours).
2. Dynamic dispatch in Java: an overridden instance method is chosen at runtime from the object's actual class. Overloading is resolved at compile time from the static argument types. Static, private and final methods are not dispatched dynamically; a static method with the same signature hides the parent's rather than overriding it.
3. In C++, only functions declared virtual dispatch through the vtable. Passing a derived object by value slices it to the base type. A base class used polymorphically needs a virtual destructor, or deleting through a base pointer is undefined behaviour.
4. For Python, a decorator is a callable that takes a function and returns a wrapper; use functools.wraps to keep the name and docstring. Keep it separate from the Decorator design pattern, which wraps an object that implements the same interface, such as a logging wrapper around a repository class.
5. Close with the trade-off: prefer composition over deep inheritance trees, because a subclass is coupled to its parent's implementation (the fragile base class problem).

Follow-up

• What happens if a constructor calls an overridable method, in Java and in C++?
• How does Python resolve a method under multiple inheritance (the MRO), and how does C++ handle the diamond problem?
• Write a decorator that retries a function up to three times. How would you make the retry count configurable?

How do you detect and resolve deadlock and race conditions in multi-threaded application environments?

Medium · Core Computer Science & Data Structures

Approach

1. Start from the four conditions a deadlock needs: mutual exclusion, hold and wait, no preemption, and circular wait. Breaking any one prevents it, and lock ordering breaks circular wait.
2. Detect a deadlock in Java with a thread dump (jstack <pid> or jcmd <pid> Thread.print), which reports Java-level deadlocks and the locks each thread holds and waits for. In code, ThreadMXBean.findDeadlockedThreads() does the same. For a native process, attach gdb and inspect every thread's stack.
3. Resolve it by acquiring locks in one global order (for example, by account id), using ReentrantLock.tryLock(timeout) with back-off, shrinking critical sections, and never calling external or callback code while holding a lock.
4. For races, name the pattern: check-then-act (if not contains, then put) and read-modify-write (count++ is a read, an add and a write). Fix with synchronized or a lock, AtomicInteger, ConcurrentHashMap.compute or merge, immutable objects, or by confining state to one thread.
5. Note that volatile gives visibility, not atomicity. Races rarely reproduce on demand, so find them with stress tests that use many threads and a start barrier, ThreadSanitizer for C/C++, and a review of every piece of shared mutable state.

Follow-up

• How do deadlock, livelock and starvation differ, and how do you spot each one?
• Why is double-checked locking broken without volatile in Java?
• How would you handle a deadlock between two database transactions rather than two threads?

Explain the key differences between TCP and UDP protocols, including header overhead and reliability mechanism

Medium · Core Computer Science & Data Structures

Explain the key differences between TCP and UDP protocols, including header overhead and reliability mechanisms.

Approach

1. Headers: the TCP header is 20 bytes minimum and up to 60 with options (sequence and acknowledgement numbers, flags, window size, checksum). The UDP header is 8 bytes: source port, destination port, length and checksum.
2. TCP reliability comes from connection setup with a three-way handshake (SYN, SYN-ACK, ACK), sequence numbers, cumulative ACKs, retransmission on timeout or after three duplicate ACKs (fast retransmit), and in-order delivery to the application.
3. TCP also does flow control through the receiver's advertised window and congestion control (slow start, then congestion avoidance). Teardown uses FIN/ACK, and the side that closes first sits in TIME_WAIT.
4. UDP is connectionless and keeps message boundaries; TCP is a byte stream, so the application must frame its messages. UDP has no ordering, retransmission or congestion control. Its checksum is optional over IPv4 and mandatory over IPv6.
5. Choose by use case: TCP for HTTP/1.1 and HTTP/2, file transfer and database connections. UDP for DNS queries, VoIP, video and games, where late data is worthless. QUIC (HTTP/3) builds reliability and its own congestion control on top of UDP.

Follow-up

• What is head-of-line blocking in TCP, and how does QUIC avoid it?
• If you had to send reliable messages over UDP, what would you add (sequence numbers, ACKs, retransmit timers)?
• Which side accumulates TIME_WAIT, and when does it exhaust ephemeral ports (a client or proxy opening many outbound connections) versus only using socket memory?

How do memory management, pointers, and bitwise operations function in C/C++ applications running on constrain

Medium · Embedded Systems, Networking & Hardware

How do memory management, pointers, and bitwise operations function in C/C++ applications running on constrained targets?

Approach

1. Lay out the memory map: code and constants in flash (.text, .rodata), initialised globals copied to RAM at startup (.data), zeroed globals (.bss), then the stack and any heap. On constrained targets, avoid malloc after initialisation because of fragmentation and unbounded timing. Use static allocation or fixed-size block pools.
2. Pointers: access memory-mapped registers through a volatile pointer, for example volatile uint32_t * const reg = (volatile uint32_t *)ADDR, so the compiler does not cache or drop the reads and writes. Distinguish pointer to const from const pointer, and watch alignment and struct padding when overlaying structs on hardware or packet buffers.
3. Bit operations on unsigned fixed-width types: set reg |= (1u << n); clear reg &= ~(1u << n); toggle reg ^= (1u << n); test (reg >> n) & 1u. Use 1u: shifting 1 into the sign bit of an int is undefined behaviour in C. A read-modify-write on a register or variable shared with an ISR is not atomic, so disable interrupts briefly, use the hardware's set and clear registers, or use atomics; volatile alone does not make it atomic.
4. Debugging tools: detect stack overflow by filling the stack with a known pattern (stack painting) or by placing a guard region below it, and read the linker map file to see RAM and flash usage per symbol.
5. C++ on constrained targets is a design practice, not a debugging tool: use RAII for resources, and build with -fno-exceptions and -fno-rtti where the toolchain or the memory budget requires it, handling errors through return codes instead.

Follow-up

• Count the set bits in a 32-bit word. Why does n & (n - 1) clear the lowest set bit?
• What does volatile not guarantee, and when would you need a memory barrier?
• How do you handle endianness when parsing a multi-byte field from a network packet?

How do you approach SQL query optimization and database indexing when application response times degrade?

Medium · Enterprise Frameworks & Backend Engineer

Approach

1. Measure before changing anything. Confirm the time is spent in the database and not in N+1 queries from the ORM (for example, Hibernate lazy loading in a loop). Find the expensive statements with the slow query log or pg_stat_statements, ranked by total time, not just by the slowest single call.
2. Read the plan with EXPLAIN ANALYZE. Look for sequential scans on large tables with selective filters, estimated row counts far from the actual ones (stale statistics, so run ANALYZE), nested loops over large inputs, and sorts that spill to disk.
3. Index for the query shape: B-tree indexes on filter, join and ORDER BY columns. In a composite index, put equality columns before the range column (the leftmost-prefix rule). Use a covering index (INCLUDE in PostgreSQL and SQL Server) to allow index-only scans.
4. Know what makes an index unusable: a function on the column (WHERE LOWER(email) = ?, which needs an expression index), a wildcard at the start of a LIKE pattern ('%abc'), or an implicit type cast. OR across different columns defeats a single composite index, but PostgreSQL and other engines can combine separate per-column indexes with a bitmap OR (or index merge), or you can rewrite the query as UNION ALL. Indexes also slow writes and take space, and low-selectivity columns rarely benefit.
5. Rewrite the query too: select only the columns you need, replace large OFFSET pagination with keyset pagination (WHERE id > last_id ORDER BY id LIMIT n), batch the N+1 calls into one IN or JOIN query, and cache results that change rarely.

Follow-up

• How would you add an index to a large production table without blocking writes (for example, CREATE INDEX CONCURRENTLY in PostgreSQL)?
• Given an index on (a, b), which of WHERE a = ?, WHERE b = ? and WHERE a > ? AND b = ? can use it well?
• The plan looks fine in staging but the query is slow in production. What differs, and what do you check?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Explain Java 8 Stream API features and write code demonstrating the practical use of filter, map, and `red

Medium · Enterprise Frameworks & Backend Engineer

Explain Java 8 Stream API features and write code demonstrating the practical use of filter, map, and reduce.

Approach

1. Explain the model: a stream is a single-use pipeline over a source. It stores no data, intermediate operations (filter, map, sorted) are lazy, and nothing runs until a terminal operation (collect, reduce, count, forEach).
2. Write a concrete pipeline, such as the total of paid orders: orders.stream().filter(o -> o.getStatus() == Status.PAID).map(Order::getAmount).reduce(BigDecimal.ZERO, BigDecimal::add).
3. Know the reduce overloads: reduce(identity, accumulator) returns T; reduce(accumulator) returns Optional<T> because the stream may be empty; reduce(identity, accumulator, combiner) is for parallel reductions or a result type different from the elements. For parallel use, the identity must be a true identity and the operation must be associative.
4. Avoid boxing with primitive streams (mapToInt(...).sum() or average()), and use collect(Collectors.groupingBy(...)) rather than reduce for mutable containers.
5. Keep lambdas free of side effects (no adding to an outside list inside map). Short-circuiting operations such as findFirst and anyMatch stop early, and laziness means a filter on an infinite Stream.iterate needs a limit.

Follow-up

• What is the difference between map and flatMap? Give a case that needs flatMap.
• When does parallelStream() help, and when does it hurt (small data, blocking calls, a shared ForkJoinPool)?
• Why does reusing a stream after a terminal operation throw IllegalStateException?

What are the core methods inherited from the base Object class, and how do hashCode and equals interact in

Medium · Enterprise Frameworks & Backend Engineer

What are the core methods inherited from the base Object class, and how do hashCode and equals interact in collection classes?

Approach

1. List the Object methods: equals, hashCode, toString, getClass, clone (protected, and it needs Cloneable), wait, notify and notifyAll (only while holding the object's monitor), and finalize (deprecated since Java 9).
2. State the contract: if a.equals(b), then a.hashCode() == b.hashCode(). Unequal objects may share a hash code. equals must be reflexive, symmetric, transitive and consistent, and x.equals(null) must return false.
3. Explain the lookup in HashMap and HashSet: the hash picks a bucket, then equals finds the key within it. If you override equals without hashCode, two equal keys land in different buckets, so a HashSet holds duplicates and get() misses.
4. Name the traps: building hashCode from mutable fields loses the entry after a mutation; using instanceof versus getClass() in equals affects symmetry once subclasses exist; TreeMap and TreeSet use compareTo, not equals, so the two should agree.
5. Implement it with Objects.equals and Objects.hash, or with a record, which generates both from its components. Since Java 8, a bin is treeified (red-black tree) when an entry is added to a bin that already holds 8 nodes (TREEIFY_THRESHOLD) and the table capacity is at least 64; below 64 the table is resized instead.

Follow-up

• What breaks if a key's hashCode changes while it is in a HashMap?
• Why does == work for some String comparisons and not others (literal interning versus new String)?
• What would you write for equals and hashCode on an entity whose id is assigned only when it is saved?

How do dependency injection, Beans, and Inversion of Control (IoC) function within Spring Boot or ASP.NET cont

Medium · Enterprise Frameworks & Backend Engineer

How do dependency injection, Beans, and Inversion of Control (IoC) function within Spring Boot or ASP.NET container lifecycles?

Approach

1. Define the terms: with IoC, the container creates objects and wires them together instead of each object building its own dependencies. DI is the mechanism: constructor injection (preferred: final fields, explicit dependencies, easy unit tests), setter injection, or field injection.
2. In Spring, beans come from component scanning (@Component, @Service, @Repository) or from @Bean methods in @Configuration classes. Resolve ambiguity with @Qualifier or @Primary. Spring Boot 2.6 and later reject circular references by default.
3. Walk the bean lifecycle: instantiate, inject properties, Aware callbacks, BeanPostProcessor before initialization, then @PostConstruct, afterPropertiesSet or a custom init method, then BeanPostProcessor after initialization (where AOP proxies such as @Transactional are created). On shutdown: @PreDestroy or destroy.
4. Scopes: singleton (the default), prototype, and request and session in web apps. A prototype or request-scoped bean injected into a singleton is resolved only once, so use ObjectProvider, a lookup method or a scoped proxy.
5. ASP.NET Core equivalent: register in IServiceCollection with AddSingleton, AddScoped (per request) or AddTransient. Injecting a scoped service into a singleton is a captive dependency, and scope validation in the Development environment throws an error for it.

Follow-up

• Why does a @Transactional method called from another method in the same class not start a transaction?
• How would you swap a real payment client for a fake one in an integration test?
• How would you configure a custom scope, for example one bean instance per tenant?

Describe the architecture of a Microservices ecosystem, specifically explaining the role and benefit of an API

Medium · Enterprise Frameworks & Backend Engineer

Describe the architecture of a Microservices ecosystem, specifically explaining the role and benefit of an API Gateway.

Approach

1. Outline the pieces: services split by business capability, each owning its data (database per service). They talk synchronously over REST or gRPC, or asynchronously through a broker such as Kafka. Add service discovery, centralised configuration, and observability with logs, metrics and distributed tracing that carries a correlation id.
2. Gateway role: one entry point that routes /orders/** and /users/** to the right services. It also handles TLS termination, token validation (for example JWT), rate limiting, CORS, request aggregation for a client screen, and protocol translation. Backends-for-frontends gives web and mobile separate gateways.
3. Benefits: clients do not track internal service addresses, cross-cutting concerns live in one place, and internal services can change without breaking clients.
4. Costs: an extra network hop, and a single point of failure unless several instances run behind a load balancer. Business logic creeping into the gateway is a risk. Keep it to routing and policy.
5. Resilience between services: timeouts on every call, retries with exponential back-off only for idempotent requests, circuit breakers, and the outbox pattern or a saga when a workflow spans several services' data.

Follow-up

• How do you keep data consistent when one order touches the order, payment and inventory services?
• What is the difference between an API gateway and a service mesh?
• How would you version an API so that old mobile clients keep working?

Explain the operation of network routing protocols such as OSPF and STP, including how loops are prevented in

Medium · Embedded Systems, Networking & Hardware

Explain the operation of network routing protocols such as OSPF and STP, including how loops are prevented in switched networks.

Approach

1. Note first that OSPF is a Layer 3 link-state routing protocol, while STP is a Layer 2 loop-prevention protocol for switched Ethernet, not a routing protocol.
2. OSPF: routers form adjacencies through Hello packets and flood LSAs so that every router in an area holds the same link-state database. Each router runs Dijkstra's SPF to build a shortest-path tree, with cost derived from interface bandwidth (reference bandwidth divided by link bandwidth). On broadcast segments a DR and BDR cut the number of adjacencies. Areas attach to backbone area 0 through ABRs, which summarise routes.
3. OSPF stays loop-free because every router computes from the same database, so the shortest-path trees agree. During convergence the IP TTL is the backstop against transient loops.
4. STP (802.1D): bridges exchange BPDUs and elect the root bridge with the lowest bridge ID (priority, then MAC). Each non-root switch picks the root port with the lowest path cost to the root, each segment gets one designated port, and every other port is blocked, leaving a loop-free tree.
5. Explain why it matters: Ethernet frames carry no TTL, so a Layer 2 loop causes broadcast storms and MAC table flapping. Classic STP moves ports through blocking, listening, learning and forwarding with slow default timers, and RSTP (802.1w) converges much faster.

Follow-up

• What happens if an old, slow access switch wins the root election, and how do you control which switch wins?
• Two OSPF routers are stuck in EXSTART/EXCHANGE. What would you check first (an MTU mismatch is a common cause)?
• What do PortFast and BPDU Guard do, and where would you enable them?

Explain the key features of SystemVerilog (SV) and UVM frameworks for verification, focusing on dynamic arrays

Medium · Embedded Systems, Networking & Hardware

Explain the key features of SystemVerilog (SV) and UVM frameworks for verification, focusing on dynamic arrays and queues.

Approach

1. SystemVerilog basics: 2-state types (bit, int) versus 4-state types (logic, which adds X and Z), classes for transactions, interfaces with clocking blocks to connect the testbench to the DUT, SVA assertions, and functional coverage with covergroups, coverpoints and crosses.
2. Dynamic arrays: size them at runtime with new[n], resize with new[m](old) to keep existing elements, and use size() and delete(). Use them for payloads whose length is known per transaction. The size can be randomised: constraint c_len { data.size() inside {[1:16]}; }.
3. Queues: declare with [$] (bounded with [$:N]). Use push_back, push_front, pop_front, pop_back, insert and delete; access at either end is cheap. They suit scoreboard expected-transaction FIFOs and reordering buffers. Associative arrays (indexed by key, checked with exists()) suit sparse memory models.
4. Randomisation: rand versus randc (randc cycles through every value before repeating), constraint blocks, and inline randomize() with {...}. Always check the return value of randomize().
5. UVM structure: a test builds an env containing agents (sequencer, driver, monitor), a scoreboard and coverage. Sequences generate sequence items, monitors publish through analysis ports, phases run build, connect, run and report, uvm_config_db passes configuration, and creating objects with type_id::create lets the factory override them.

Follow-up

• How would you use the factory to replace a sequence item with an error-injecting subclass, without editing the env?
• When would you choose a queue over a dynamic array, and what does each cost when you insert in the middle?
• How do you know verification is finished: what do code coverage and functional coverage each tell you?

What scripting techniques (such as TCL or Python) do you use for build automation, synthesis flows, or testing

Medium · Embedded Systems, Networking & Hardware

What scripting techniques (such as TCL or Python) do you use for build automation, synthesis flows, or testing pipelines?

Approach

1. Pick one pipeline you actually built and describe it end to end: what triggers it, what it runs, what it produces, and how a failure is reported. A concrete example beats a list of languages.
2. Python techniques: an argparse or config-file interface instead of hard-coded paths, subprocess with return-code checks (check=True), parallel runs with concurrent.futures, structured logging, and results written as JUnit XML so the CI server can display them.
3. For TCL inside tool shells: wrap repeated steps in procs, keep design settings in variables or dicts, source a common setup file, and gate the flow on report checks, failing the run if the timing slack or error count crosses a threshold you set.
4. Reliability: make scripts idempotent and fail fast, parse tool logs with regex for errors and new warnings, record seeds and tool versions so a failing simulation or build can be reproduced, and keep the scripts in Git with code review like any other code.
5. Trade-off: TCL is the native control language of many EDA tools, while Python is better for orchestration, log parsing and reporting. Say which layer you would write in which language.

Follow-up

• A regression fails intermittently. How would your scripts help you reproduce it?
• How would you cut the wall-clock time of a nightly regression that has grown too long?
• How do you stop one bad tool licence or a hung job from blocking the whole pipeline?

Walk me through the high-level architecture and your specific individual contributions to the primary project

Medium · Behavioral, Project Deep Dives & Client

Walk me through the high-level architecture and your specific individual contributions to the primary project listed on your resume.

Approach

1. Open with the problem and the users in two sentences, then sketch the components: clients, services or modules, data stores, external integrations, and how they communicate. Trace one real request through it end to end.
2. Mark your own scope clearly with "I": which modules you wrote, which decisions were yours, and which parts belonged to others. Separate what you designed from what you inherited.
3. Pick one significant decision and give the alternative you rejected and why, such as SQL versus NoSQL, sync versus async, or a cache versus a query fix. Name the cost you accepted.
4. Give one measurable result (latency, throughput, defect rate, delivery date) and one thing that went wrong in production and how you diagnosed it. Have the numbers and the debugging steps ready.
5. Be ready to go one level deeper on any box you drew: the schema, the API contract, the threading model, or the test strategy for the part you own.

Follow-up

• What would break first if the load grew ten times, and what would you change?
• If you rebuilt this project today, which design decision would you reverse?
• How did you test your part, and what kind of defect still got through?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

Each day maps to a reported round or question group: a loop map, coding fundamentals, OOP and concurrency, Java/.NET backend topics, networking and embedded topics, project and behavioral stories, then a full mock.

Day 1 — Pick your track and audit your resume

• Write the five reported stages in order and note what each covers: HR Screening, Aptitude and Technical Test, Technical Rounds, Client Interview, Techno-Managerial or HR Round.
• Choose your track (backend Java/.NET, full-stack, embedded and networking, or hardware verification), and list every technology on your resume with a rating of how well you could explain its internals.
• Write the questions you will ask your recruiter: the track, internal or client placement, the client's stack, and which stages apply.

Deliverable: A one-page loop map, a rated technology list from your resume and a written list of recruiter questions.

Day 2 — Coding fundamentals: linked list and matrix

• Solve the single-pass middle-of-a-linked-list problem with slow and fast pointers by hand, covering one, two and even-length lists, and note the O(n) time and O(1) space.
• Solve the Kth smallest in a sorted matrix two ways (min-heap and binary search on value), stating the complexity of each and handling duplicates.
• Explain each solution aloud as you would in a screen share, before writing any code.

Deliverable: Two working solutions per problem in your primary language, each with a written complexity note and an edge-case list.

Day 3 — OOP, concurrency and the aptitude test

• Write a short answer for the OOP pillars with a code example of dynamic dispatch and a decorator in your primary language.
• Write one deadlock and one race condition in code, then fix each (lock ordering, a lock around a check-then-act sequence, an atomic operation) and describe how you would find them in a running service.

Deliverable: A written OOP answer with code, a deadlock and a race condition each with a bug, a fix and a diagnosis note, and a worked concurrent-create cap solution.

Day 4 — Java and .NET backend topics

• Write a Java 8 stream pipeline using filter, map and reduce, and describe lazy evaluation. Then write a class that overrides equals and hashCode, show the bug when a mutable field is used in a HashMap key, and list the Object class methods.
• Explain dependency injection, bean scopes and lifecycle in Spring Boot (or the ASP.NET equivalent), then sketch a microservices layout with an API gateway for routing, authentication and rate limiting.
• Take a slow query with an EXPLAIN plan and decide which index helps, which filter defeats it, and what you would measure first.
• For the full-stack track, review React component lifecycle and hooks, state management, and how a React front end calls the Spring Boot or ASP.NET APIs covered today.

Deliverable: A stream code sample, an equals/hashCode bug demo, a one-page IoC and gateway explainer, an index decision for a slow query and, for full-stack, a React-to-API call outline.

Day 5 — Networking, embedded and hardware topics

• Write a TCP versus UDP comparison covering header fields, the handshake, acknowledgement and retransmission, flow and congestion control, and when each fits.
• Explain how STP removes loops (root bridge election, port roles and blocking) and how OSPF builds a link-state database and picks shortest paths.
• Write short C programs using pointers, a bit mask to set, clear and test a flag, and a safe approach to allocation on a constrained target.
• If your track includes hardware, outline SystemVerilog dynamic arrays and queues in a UVM testbench, an AMBA bus story from your experience, and a TCL or Python build or test script you have written.

Deliverable: A TCP/UDP comparison sheet, an STP and OSPF explainer, a working bit-manipulation C snippet, and, for hardware tracks, an AMBA and UVM talking-points page.

Day 6 — Project deep dive and behavioral stories

• Write the architecture of your main project in order: components, data flow, your own contributions, one bottleneck you solved and one trade-off you made.
• Write one story each for deadline risk, teammate feedback, a difficult stakeholder or client team, and prioritising competing tickets, with the decision and a result for each.
• Say each story aloud and trim it to the situation, your action and the outcome.

Deliverable: A one-page project architecture walkthrough and four written stories, each with a decision and a result.

Day 7 — Full mock and the client and HR conversation

• Run a mock technical round: one coding problem (linked list or matrix), two questions from your chosen track, and the project walkthrough, all aloud.
• Rehearse the client conversation using the client's stack from your recruiter, and prepare to relate your past work to its requirements.

Deliverable: A recorded mock round with a list of weak spots, a written client-stack match, a written set of HR answers and a narrated debugging walk-through.

Project, client and team stories

Candidates report questions about your own project, how you handle deadline risk, feedback about teammates, difficult stakeholders and competing tickets. Since many roles involve client teams, prepare stories where you made a decision, communicated it clearly and can state the outcome. The AMBA and ARM question is filed with the behavioral set, so answer it as an experience question about what you personally built.

1. Walk me through the high-level architecture and your specific individual contributions to the primary project listed on your resume.

Describe your experience with AMBA-based bus protocols and ARM architecture integration.

Medium · Embedded Systems, Networking & Hardware

Approach

1. Treat it as an experience question: answer only with what you built or debugged, and name the exact pieces: which AMBA protocols (APB, AHB, AXI), which ARM core or subsystem, and which side you owned (master, slave, interconnect, bridge or testbench).
2. Show protocol-level fluency. APB is a simple two-phase peripheral bus (setup, then access, with PSEL, PENABLE and PREADY wait states). AHB pipelines address and data phases and uses HREADY for wait states. AXI has five channels (AW, W, B, AR, R), each with a valid/ready handshake, and allows out-of-order completion across different IDs.
3. Describe integration work concretely: the address map and decoder, clock and reset domains, bridges such as AXI to APB, endianness, how interrupts reach the core, and how you brought the block up.
4. Include one real bug, such as a hung handshake or a wrong address decode, and how you found it (waveforms, protocol assertions, a bus monitor) and fixed it.
5. If your experience covers only part of this, say which part and what you have studied. Claiming a protocol you have only read about is easy to expose with one follow-up.

Follow-up

• What is the difference between AHB and AXI, and why can AXI complete transactions out of order?
• How does a bridge from AXI to APB deal with a slave that inserts wait states?
• Walk me through a bus bring-up problem you debugged and how you proved the fix.

Tell me about a time you faced a major technical challenge or deadline risk in your project. How did you handl

Medium · Behavioral, Project Deep Dives & Client

Tell me about a time you faced a major technical challenge or deadline risk in your project. How did you handle it, and what was the final outcome?

Approach

1. Choose a project where you made the calls, and state the risk in two sentences: what was due, what threatened it (a design flaw, a vendor dependency, a late requirement) and who was affected.
2. Spend most of the answer on options and reasoning: cut scope, split the work, spike the riskiest part first, add a reviewer, or renegotiate the date. Say which you chose and why you rejected the others.
3. Show how you raised the risk early with your lead or the client, and what you said, so it does not sound like you hid it until the last day.
4. End with the real outcome, including what slipped or was cut, a number or two (defects, hours, delivery date versus plan), and one thing you changed afterwards. A story that ends in heroics and no lesson reads as luck.

Follow-up

• What did you tell your lead or the client about the risk, and when?
• If the deadline could not move, what would you have cut first?
• How did you confirm the fix actually worked in production?

How do you handle a situation where you receive negative feedback regarding a team member's performance or pro

Medium · Behavioral, Project Deep Dives & Client

How do you handle a situation where you receive negative feedback regarding a team member's performance or project deliverables?

Approach

1. Start by verifying: read the actual deliverable, review comments, defect list or ticket history before reacting, so you know whether the feedback is accurate, partly accurate or about a process problem.
2. Speak to the teammate privately and early, describe the specific issue instead of a verdict, and ask for their view. Look for the cause: unclear requirements, a skills gap, overload or a blocked dependency.
3. Agree a concrete fix with a date, and give practical help such as pairing, a checklist or an earlier code review. Protect the person from public blame.
4. Report back to whoever gave the feedback with the plan and the result, and follow up until the issue is closed. If you lead the work, own the outcome in front of the client or manager.
5. Avoid forwarding the criticism verbatim, escalating before talking to the person, or telling a story where the teammate is simply the problem.

Follow-up

• What if the feedback came from the client and you thought it was unfair?
• What would you do if the teammate did not improve after your help?
• How did you keep the delivery on track while this was happening?

Describe a situation where you had to manage interaction with a difficult stakeholder or external client team.

Medium · Behavioral, Project Deep Dives & Client

Approach

1. Say exactly what made the stakeholder difficult (shifting requirements, no clear acceptance criteria, escalating tone, a time-zone gap) and what was at stake for the delivery.
2. Describe what you did first: listen, restate their need in writing, and separate the person's frustration from the underlying concern, which is often a risk they fear about schedule or quality.
3. Name the mechanisms you set up: a regular status update, written minutes of decisions, and a change-request path that states the schedule effect of each new item. Support disagreements with evidence such as a demo, logs or an estimate.
4. Say when and to whom you escalated, if you did, and that you tried a direct fix first.
5. Finish with the outcome and the state of the relationship afterwards. Describing the client as unreasonable, with no tactic of yours, sinks the story.

Follow-up

• How did you handle a requirement change that arrived late?
• When did you escalate, and to whom?
• What did you change in how you communicate with clients afterwards?

How do you prioritize multiple urgent software tickets or feature requests with competing tight deadlines?

Medium · Behavioral, Project Deep Dives & Client

Approach

1. Give a method before an example: list everything, confirm who owns each deadline, and rank by impact and cost of delay. Production outages, data loss and security issues generally go first, then work that blocks other people, then feature work.
2. Factor in effort and dependencies. A thirty-minute fix that unblocks a teammate can go before a larger item, and shared code or shared environments may force an order.
3. Negotiate with evidence: tell the requesters what each choice delays (if I take the client defect now, the feature moves to Thursday) and let the owner of the priority choose between options.
4. Protect focus by batching, timeboxing and stating a working order in the ticket tracker or a message, so everyone sees what is coming.
5. Close with a real case, for example a bug fix against active feature work under a client deadline, and what happened to each item.

Follow-up

• Two tickets are both marked urgent by different people. What do you do?
• How do you respond to an urgent request that lands in the middle of a sprint?
• How do you say no or not yet without damaging the relationship?