cswork / libraryOpen practice workspace

Interview guides · Azentio Software

Azentio Software Software Engineer Interview Guide

Azentio Software Software Engineer interview guide: five reported rounds, Java, Spring Boot, SQL and PL/SQL questions, STAR prompts and a 7-day plan.

The 60-second brief

Candidates describe Azentio Software as a maker of enterprise software products, often for insurance, banking and financial services. For a Software Engineer the stack they list is Java-based microservices, Oracle PL/SQL database layers and, on some teams, React or Angular frontends. Day-to-day work, as candidates describe it, includes writing and reviewing code, debugging production issues, working closely with the database, and either migrating older systems to modern frameworks or building new microservices.

This guide is for candidates interviewing for a Software Engineer position at Azentio Software, whether a fresh graduate or an experienced developer. It covers the five reported rounds, the technical-knowledge, coding and behavioral questions candidates report, question-by-question preparation for the behavioral scenarios, and a seven-day plan. It does not cover other roles at the company, and the exact stack (Java, PL/SQL or frontend) can vary by team.

Candidates report five rounds over roughly 4-6 weeks: Initial Screening, Technical Assessments, Coding Rounds, Panel Interviews and Final Round Discussions. The stages are candidate-reported, not a published process, and details can vary by team and location.

Focus areas

  • Java
  • Spring Boot
  • Object-Oriented Programming (OOPs)

Overview

The reported questions cluster in a small number of areas: Java and Spring Boot, object-oriented programming, microservices, and SQL with Oracle PL/SQL. Candidates also list React or Angular and cloud familiarity as nice-to-have. Before anything else, decide which lane you are interviewing in. Candidates are advised to confirm their specific stack, for example Java versus PL/SQL, before the technical rounds begin, because the depth of questioning follows that choice.

The reported questions fall into three groups. Technical and domain knowledge covers HashMap and Hashtable internals, the React or Angular component lifecycle, Spring Boot versus the Collection Framework, DELETE versus DROP versus TRUNCATE, and creating and managing PL/SQL packages and procedures. Coding covers finding primes between 1 and 100, reversing a number, a classic dynamic programming or graph problem, and a SQL query with multiple joins and subqueries. The behavioral group covers a critical bug on a Friday evening, a client whose recurring issues eat into your personal time, and why you want to join. Most of these are fundamentals questions, so the gap between candidates is usually how precisely and how completely they explain, including edge cases, rather than obscure knowledge.

Candidates also report being questioned on the projects listed on their resume, including being asked to draw the architecture on a whiteboard or shared screen, and writing code on a shared screen without IDE help. Freshers report a heavy emphasis on aptitude, DSA and core Java and SQL, while more senior candidates report design discussions about how components fit together or how to scale an existing application. Prepare one project you can explain end to end: the components, the data flow, the decision you would defend and the one you would change.

The Azentio Software interview process

Candidates describe five stages, with technical depth increasing toward the final discussions with senior architects or managers. The stages below are what candidates report, not a published process.

Initial Screening

Candidates describe an opening screen that checks basic qualifications and fit. Treat it as a spoken version of your CV: the technologies you have used, what you built with them, and why you are applying for this role. Candidates are also advised to confirm which stack the role centres on before the technical stages start.

What to demonstrate

  • Basic qualifications against the skills the role lists: Java or your primary language, SQL and data structures and algorithms
  • Fit for the role, as the stage is described
  • How clearly you summarise your own experience

How to prepare

  • Write a CV walk-through that names the stack used in each project (Java, PL/SQL, React or Angular) and your own part in it.
  • Settle which lane you are interviewing in, for example Java services or the PL/SQL database layer, so your answers do not wander.
  • Rehearse a short answer on why you want to join Azentio Software and which specific skill you bring; candidates report this as a question.

Technical Assessments

Candidates report technical assessments that evaluate both coding skill and technical knowledge. The reported technical-knowledge questions are fundamentals of the main stack, such as how HashMap and Hashtable work, the difference between DELETE, DROP and TRUNCATE, or what Spring Boot is relative to the Collection Framework. Prepare to explain mechanism and reason, not just definitions.

What to demonstrate

  • Technical knowledge of your primary stack, for example Core Java collections, Spring Boot and SQL
  • Coding ability at the level of small, well-defined problems
  • Whether you can explain why a technology behaves the way it does

How to prepare

  • Practise the technical-knowledge questions candidates report aloud, starting with HashMap versus Hashtable and DELETE versus DROP versus TRUNCATE, until each answer covers mechanism, difference and edge case.
  • Review Core Java topics candidates list: OOP concepts, collections, Java 8 streams and lambdas, multithreading and thread safety.
  • Review Spring Boot annotations, REST API development and JPA transaction management so you can explain how they fit together.

Coding Rounds

Candidates describe coding rounds centred on problem-solving and algorithmic challenges. Candidates report sharing their screen and writing code live, and recommend practising syntax without IDE assistance. A coding stage is where problems such as prime numbers, reversing a number, a dynamic programming or graph problem and a multi-join SQL query are practised.

What to demonstrate

  • Working code produced live, without relying on IDE completion
  • Choice and justification of data structures and algorithms
  • Handling of edge cases while you talk through the approach

How to prepare

  • Write the simple coding problems candidates report (primes between 1 and 100, reversing a number) in a plain text editor and test them against edge cases.
  • Pick two or three classic DP problems and two graph traversals (BFS and DFS) and write each from memory with its complexity.
  • Write a SQL query with several joins and a subquery by hand, then explain which indexes it would use.

Panel Interviews

Candidates report a panel of interviewers who discuss technical and behavioral aspects together, so one conversation can move between code, your past projects and how you handle pressure. Candidates also report detailed questions on the projects listed on a resume, including drawing the architecture.

What to demonstrate

  • Depth of knowledge in your own project work
  • A mix of technical explanation and behavioral judgement in the same conversation
  • Clarity when several people are asking questions

How to prepare

  • Draw the architecture of two projects from your resume on paper, labelling services, data stores and the data flow between them.
  • Write STAR outlines for the Friday-evening production bug scenario and the recurring client issues scenario.
  • Prepare an honest answer for a gap in your knowledge: say you do not know and describe how you would find out.

Final Round Discussions

Candidates describe final discussions with senior architects or managers, aimed at high-level architectural thinking. Candidates report that questioning gets deeper as the loop progresses, and that for more senior roles the discussion can include designing a small system or scaling an existing application.

What to demonstrate

  • High-level architectural thinking, as the stage is described
  • How components fit together and how data flows between services
  • Ability to communicate design decisions clearly

How to prepare

  • Practise explaining how you would scale one application you know: where the bottleneck is, what you would measure first, and what you would change in the database and service layers.
  • Review microservice architecture topics candidates list, including service discovery and thread safety, and be ready to say what each solves.
  • Prepare to explain a design decision from your own work in terms of the alternatives you considered and the trade-off you accepted.

Where candidates lose points

Answering DELETE versus DROP versus TRUNCATE with three one-line definitions and no mention of transactions

For each statement, say what it removes, whether it takes a WHERE clause, whether it can be rolled back, and what happens to the table structure and its constraints. In Oracle, note that TRUNCATE and DROP are DDL and commit implicitly, unlike DELETE.

Solving the small coding problems quickly but skipping their edge cases

For primes between 1 and 100, state that 0 and 1 are not prime and stop trial division at the square root, or use a sieve. For reversing a number, handle negative values, trailing zeros and integer overflow, then say how you would test each.

Describing a resume project at buzzword level and being unable to draw it

Candidates report being asked to draw project architecture on a whiteboard or screen. Prepare a diagram with components, data stores and request flow for each project, and one decision you would defend and one you would change.

Giving a heroic or dismissive answer to the Friday-evening bug and recurring-client scenarios

Structure each answer as triage, stabilise, communicate, fix, prevent, using STAR. Include a real number and a systemic follow-up such as monitoring, a rotation or a root-cause report, and avoid both martyrdom and refusal.

Bluffing on a topic outside your stack, or leaving gaps in the stack you claimed

Candidates advise against bluffing. Choose your lane before the technical rounds, know it deeply, and when you reach the edge say so plainly and explain how you would find the answer.

Questions & practice

Write a program to identify prime numbers between 1 and 100.

Medium · Coding & Problem Solving

Approach

  1. Start with the edge cases: 1 is not prime, 2 is the only even prime, and the answer for 1 to 100 is 25 primes, from 2 to 97. Say you will write it for a general upper bound n.
  2. Baseline: trial division that tests each candidate against divisors up to its square root (loop while d * d <= k), skipping even numbers after 2. That is O(n sqrt n) across the range and O(1) extra space.
  3. Better: the Sieve of Eratosthenes. Use a boolean array of size n + 1. For each p with p * p <= n that is still unmarked, mark multiples starting at p * p in steps of p. That is O(n log log n) time and O(n) space. Starting at p * p is safe because smaller multiples were already marked by smaller primes.
  4. Code it cleanly in Java: return an empty list for n < 2, and guard p * p against int overflow for large n (use p <= n / p or a long). Collect the unmarked indices from 2 upward. Odd-only storage or a BitSet halves or shrinks the memory if asked.

Follow-up

  • How would you list primes in a range [L, R] where R is around 10^12 but R - L is small? (segmented sieve)
  • How would you test whether one 64-bit number is prime without a sieve?
  • What does the sieve cost in memory for n = 10^8, and how would you reduce it?

Implement a solution to reverse a given number.

Medium · Coding & Problem Solving

Approach

  1. Clarify the contract first. Can the input be negative? What should 1200 return (21 as an int, or "0021" as text)? What happens on overflow? Then write the arithmetic loop: while n != 0, digit = n % 10, rev = rev * 10 + digit, n /= 10. That is O(d) for d digits, which is O(log n), with O(1) space.
  2. Negatives work without special-casing in Java, because % keeps the sign of the dividend: -123 gives digits -3, -2, -1 and the result -321. The loop condition must be n != 0, not n > 0.
  3. Guard against overflow before multiplying. Reversing 1534236469 does not fit in an int. Check rev > Integer.MAX_VALUE / 10 || (rev == Integer.MAX_VALUE / 10 && digit > 7), and the mirror check against MIN_VALUE (digit < -8), or accumulate in a long and compare at the end. Return 0 or throw, whichever was agreed.
  4. Mention the string alternative: new StringBuilder(String.valueOf(Math.abs(n))).reverse() with the sign added back. It is readable but allocates, it still overflows on parsing, and Math.abs(Integer.MIN_VALUE) stays negative. Test 0, a single digit, trailing zeros, negatives and MAX_VALUE.

Follow-up

  • Check whether a number is a palindrome without converting it to a string or reversing all of it.
  • How would you reverse a number with 50 digits?
  • How would you reverse the bits of a 32-bit integer instead of its decimal digits?

Solve a classic Dynamic Programming (DP) or Graph problem.

Medium · Coding & Problem Solving

Approach

  1. Name the problem family before coding. Use DP when the problem asks for an optimal value or a count over overlapping subproblems. Use a graph when the input is entities plus relations (dependencies, routes, grid cells). Restate the constraints, because they decide which algorithm is feasible.
  2. For DP, state the subproblem, the recurrence, the base case and the fill order out loud. Example, coin change minimum coins: dp[0] = 0, dp[a] = min over coins c of dp[a - c] + 1, with infinity meaning unreachable. That is O(amount x coins) time and O(amount) space. For LCS, a 2D table is O(mn), which drops to O(min(m, n)) space with two rows.
  3. For graphs, build an adjacency list (O(V + E) space), then match the algorithm to the edge weights. BFS handles unweighted shortest paths. Dijkstra with a binary heap is O((V + E) log V) for non-negative weights. Bellman-Ford is O(VE) when weights can be negative. Kahn's topological sort orders dependencies and detects a cycle when fewer than V nodes come out. Union-find handles connectivity.
  4. Pick memoised recursion or bottom-up tabulation deliberately. Memoisation only touches reachable states, but deep recursion in Java can throw StackOverflowError (as can recursive DFS on a big grid), so switch to an explicit stack or a table.
  5. Trace a small example by hand, then cover the edges: empty input, an unreachable target, a disconnected graph, cycles, and duplicate edges.

Follow-up

  • How do you reconstruct the actual path or the chosen items, not just the optimal value?
  • What breaks in Dijkstra if one edge weight is negative?
  • Can you cut the DP's memory from two dimensions to one, and in what order must the loop run?

Explain the difference between DELETE, DROP, and TRUNCATE in SQL.

Medium · Technical & Domain Knowledge

Approach

  1. Classify the commands. DELETE is DML: it removes the rows a WHERE clause matches (or all rows), writes undo and redo per row, fires DELETE triggers, and can be rolled back until commit.
  2. TRUNCATE is DDL. It removes every row with no WHERE clause, deallocates the space and resets the high-water mark, so later full scans are fast again, and it fires no DML triggers. In Oracle and MySQL it commits implicitly and cannot be rolled back. In PostgreSQL and SQL Server it can be rolled back inside a transaction.
  3. DROP removes the table itself: data, indexes, constraints, triggers and grants. Dependent views and procedures become invalid. In Oracle 10g and later, the dropped table goes to the recycle bin and FLASHBACK TABLE ... TO BEFORE DROP restores it, unless you dropped it with PURGE.
  4. Cover constraints. Oracle refuses to TRUNCATE a table that an enabled foreign key references (ORA-02266) unless you use TRUNCATE ... CASCADE (12c and later, which needs ON DELETE CASCADE keys). DROP needs CASCADE CONSTRAINTS. A standalone Oracle sequence is not reset by any of the three.
  5. Finish with the practical choice. Use DELETE for selective removal or when it must be auditable and reversible, TRUNCATE to empty a staging table, and DROP to retire the object. To remove most of a huge table, delete in batches with commits, or copy the rows you keep with CTAS and swap the tables.

Follow-up

  • How would you remove 90% of the rows from a very large table without filling the undo tablespace?
  • Someone ran TRUNCATE on a production table in Oracle. What are your recovery options?
  • Why does a full table scan stay slow after a DELETE of every row, but not after TRUNCATE?

How do you create and manage Oracle PL/SQL packages and procedures?

Medium · Technical & Domain Knowledge

Approach

  1. Split the package into a spec and a body. The spec (CREATE OR REPLACE PACKAGE) is the public contract: procedure and function signatures, types, constants and cursors. The body (CREATE OR REPLACE PACKAGE BODY) holds the implementation plus private helpers. Callers depend only on the spec, so a body-only change does not invalidate them.
  2. Write procedures with explicit IN, OUT and IN OUT parameters (NOCOPY for large collections). Use a function when you need a return value, including from SQL if it has no side effects. Overloading is allowed inside packages. Handle exceptions by name, log and re-raise from WHEN OTHERS rather than swallowing, and use RAISE_APPLICATION_ERROR with codes -20000 to -20999 for business errors.
  3. Leave COMMIT to the caller so a procedure can join a larger transaction. Use PRAGMA AUTONOMOUS_TRANSACTION only for things like error logging that must persist after a rollback. For volume, replace row-by-row cursor loops with a single SQL statement, or with BULK COLLECT ... LIMIT plus FORALL, to cut context switches.
  4. Manage it as code: scripts in version control, SHOW ERRORS or USER_ERRORS after compiling, USER_OBJECTS to find INVALID objects, and UTL_RECOMP or DBMS_UTILITY.COMPILE_SCHEMA to recompile. Grant EXECUTE on the package rather than on the tables, and choose definer's rights or AUTHID CURRENT_USER deliberately.
  5. Name the deployment trap. Package-level variables hold per-session state, so recompiling a stateful body raises ORA-04068 (existing state of packages discarded) in live sessions. Keep packages stateless, or plan the release for it.

Follow-up

  • Why put procedures in a package instead of creating them standalone?
  • How would you deploy a package change to a live system without ORA-04068 errors for connected users?
  • A row-level trigger that queries its own table fails with ORA-04091. Why, and how do you fix it?

Write a complex SQL query involving multiple joins and subqueries.

Medium · Coding & Problem Solving

Approach

  1. Fix the output grain first (one row per customer, account or month), then trace the join path outward from that table. Agree the schema aloud with an example: customers, accounts and transactions, with a question such as "customers whose total this quarter exceeds their branch average".
  2. Avoid fan-out. Aggregate the many-side in a derived table or CTE before joining, or SUM across two one-to-many joins will double count. Pick the subquery form on purpose: a correlated subquery for a per-row check, EXISTS or NOT EXISTS for semi- and anti-joins, a derived table for pre-aggregation.
  3. Know the NULL traps. NOT IN returns no rows if the subquery produces a single NULL, so prefer NOT EXISTS. A WHERE filter on the right table of a LEFT JOIN quietly turns it into an inner join, so put that condition in the ON clause.
  4. For latest-per-group or top-N, use ROW_NUMBER() (or DENSE_RANK() when ties matter) OVER (PARTITION BY account_id ORDER BY txn_ts DESC) in a subquery and filter on rank = 1. In Oracle, ROWNUM is assigned before ORDER BY, so use FETCH FIRST n ROWS ONLY (12c and later) or an ordered inline view.
  5. Talk about performance. Index the join and filter columns, avoid wrapping indexed columns in functions or implicit conversions, and read the plan with EXPLAIN PLAN plus DBMS_XPLAN.DISPLAY to check the join method and cardinality estimates.

Follow-up

  • Rewrite your correlated subquery as a join or a window function, and say which runs faster and why.
  • Return the second-highest transaction per account, including ties.
  • The query takes minutes on production data. Walk through how you would find out why.

Why do you want to join Azentio Software, and what specific value do you bring to our team?

Medium · Behavioral & Situational

Approach

  1. Treat it as a motivation question, even though it is filed with the SQL questions. Answer in three parts: why this company, what you bring, and what you want to build or learn there. Keep it specific enough that it could not be pasted into another company's interview.
  2. Anchor the why in facts you can stand behind. Candidates report that the company builds software for insurance, banking and financial services, with a stack of Java microservices, Oracle PL/SQL, and React or Angular. Connect that to work you have done or want to do, such as transaction-heavy systems or data integrity. Read up on the product lines yourself beforehand rather than guessing.
  3. For the value, give two concrete strengths that match the reported stack, each with evidence: a project, your own part in it, and a measurable result (a query you tuned, a service you shipped, an incident you resolved). If you are a fresher, use coursework or internship projects with real detail instead.
  4. Answer in the first person singular, avoid salary, brand size or job security as the main reason, and do not claim product knowledge you cannot back up when asked. Answers that fit any employer, or that list adjectives with no example behind them, are the ones that fall flat.

Follow-up

  • What do you know about the products, and which one would you want to work on?
  • Which is your primary stack, Java or PL/SQL, and why?
  • Why are you leaving your current role, and what would make you stay at this company?

Explain the internal working of HashMap and HashTable in Java.

Medium · Technical & Domain Knowledge

Approach

  1. Describe the HashMap layout: a Node<K,V>[] table of buckets, where the index is (n-1) & hash and hash() XORs the high 16 bits of hashCode() into the low bits. The default capacity is 16 and the load factor 0.75. Once size passes capacity x 0.75, the table doubles and each bucket splits into a low list and a high list.
  2. Explain collisions. Entries in the same bucket chain as a linked list. Since Java 8, a bin with 8 or more nodes becomes a red-black tree if the table has at least 64 buckets (otherwise the table resizes instead), and it turns back into a list at 6. Average get/put is O(1); a treeified bin is O(log n) instead of O(n).
  3. Compare Hashtable with HashMap. Hashtable is the legacy class: every public method is synchronized on the instance, null keys and values throw NullPointerException, and the index is (hash & 0x7FFFFFFF) % length with a default capacity of 11 that grows to 2n+1. It never treeifies. HashMap allows one null key and many null values.
  4. Cover the equals/hashCode contract: equal keys must return equal hash codes, and mutating a key after insertion makes it unreachable. HashMap iterators are fail-fast on a best-effort basis (ConcurrentModificationException). Hashtable's keys()/elements() Enumerations are not fail-fast.
  5. Close on concurrency. Neither class is the right pick today: use ConcurrentHashMap (CAS on empty bins, a lock on the bin head otherwise, no nulls allowed), and use computeIfAbsent or merge for check-then-act updates, because a get followed by a put is still a race.

Follow-up

  • What happens if a key class overrides equals but not hashCode?
  • Why is the HashMap capacity always a power of two, and what does that mean for a poor hashCode?
  • Why does ConcurrentHashMap reject null keys and values when HashMap accepts them?

Describe the component lifecycle in React or Angular.

Medium · Technical & Domain Knowledge

Approach

  1. Say which framework you are answering for first, then walk through the phases in order. For React class components, mounting is constructor, getDerivedStateFromProps, render, componentDidMount. Updating is getDerivedStateFromProps, shouldComponentUpdate, render, getSnapshotBeforeUpdate, componentDidUpdate. Unmounting is componentWillUnmount, and getDerivedStateFromError/componentDidCatch handle errors.
  2. For hooks: render must stay pure. useEffect runs after the browser paints, and its cleanup runs before the next run of that effect and on unmount. The dependency array controls when it re-runs: none means every render, [] means mount only. useLayoutEffect runs synchronously after DOM mutation and before paint, which is where measurement belongs.
  3. For Angular: the constructor handles DI only. ngOnChanges runs when a bound input reference changes (and before ngOnInit if there are inputs), ngOnInit runs once, ngDoCheck runs on every change-detection pass, then ngAfterContentInit/Checked, ngAfterViewInit/Checked, and ngOnDestroy.
  4. Tie each hook to a real job: fetch data in componentDidMount/useEffect or ngOnInit, and read @ViewChild only from ngAfterViewInit. Release subscriptions, timers and listeners in the cleanup function or ngOnDestroy (takeUntil or the async pipe in Angular), or the component leaks.
  5. Name the classic bugs: an unconditional setState in componentDidUpdate loops forever, a useEffect with missing dependencies reads stale values, and changing a bound value in ngAfterViewInit raises ExpressionChangedAfterItHasBeenCheckedError in dev mode.

Follow-up

  • Why does a useEffect run twice on mount in React 18 development mode under StrictMode?
  • With ChangeDetectionStrategy.OnPush, what makes Angular check the component again?
  • How would you cancel an in-flight request when the component unmounts?

What are the differences between Spring Boot and the standard Collection Framework?

Medium · Technical & Domain Knowledge

Approach

  1. Start by pointing out that the two are not alternatives. The Collections Framework is the java.util in-memory data-structure library in the JDK. Spring Boot is an application framework built on Spring. Say this calmly, then explain each and how they meet, rather than inventing a comparison.
  2. Collections: the List, Set, Queue/Deque and Map interfaces (Map is not a subtype of Collection) and their implementations (ArrayList, LinkedList, HashSet, TreeSet, ArrayDeque, PriorityQueue, HashMap, LinkedHashMap, TreeMap). Pick by access pattern: index access, uniqueness, ordering or priority.
  3. Spring Boot: auto-configuration driven by conditions such as @ConditionalOnClass and @ConditionalOnMissingBean, starter dependencies, an embedded server (Tomcat with the web starter), externalised configuration with profiles, and Actuator. @SpringBootApplication combines @Configuration, @EnableAutoConfiguration and @ComponentScan.
  4. Show where they meet. A JPA repository returns List<Entity>, Jackson serialises a List to a JSON array, and Spring can inject List<Handler> or Map<String, Handler> holding every bean of a type, which is a clean way to pick a strategy by key.
  5. Offer the likely intended questions too: Spring Framework vs Spring Boot (manual configuration vs opinionated auto-configuration), or Collection (the interface) vs Collections (the static utility class with sort, unmodifiableList and synchronizedMap).

Follow-up

  • How does Spring Boot decide whether to create a DataSource bean, and how do you override it?
  • When would you choose LinkedList over ArrayList, and is that choice ever right in practice?
  • How would you inject every implementation of an interface and select one at runtime?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

  1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
  2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
  3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
  4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

  • The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
  • How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

Seven days built around the reported rounds: map the loop, then Java fundamentals, SQL and PL/SQL, hand-written coding, frontend and architecture, behavioral stories, and a full mock pass. Days point at the reported questions they practise.

Day 1 — Map the loop and choose your lane

  • Write the five reported rounds in order and next to each one line on what it covers, based on the descriptions above.
  • Decide whether you are interviewing as a Java, PL/SQL or frontend candidate, and list the topics from this guide that belong to that lane.
  • Draw the architecture of one resume project, showing components, data stores and request flow.

Deliverable: A one-page round map, a ranked list of topics for your lane, and one project architecture diagram.

Day 2 — Core Java and Spring Boot fundamentals

  • Explain HashMap and Hashtable aloud: buckets, hashCode and equals, collision handling, resizing, synchronisation and null handling. Then write a short comparison table.
  • Write a paragraph on how Spring Boot and the Collection Framework differ, starting with the fact that one is an application framework and the other a library of data structures.
  • Review Java 8 streams and lambdas, multithreading and thread safety, and write one small example of each.

Deliverable: A HashMap versus Hashtable comparison table, a Spring Boot versus Collection Framework paragraph, and one stream example and one thread-safety example.

Day 3 — SQL and Oracle PL/SQL

  • Write a table comparing DELETE, DROP and TRUNCATE on WHERE support, rollback, structure and constraints.
  • List the parts of a PL/SQL package (specification and body), a procedure and a trigger, and write one small package with a procedure from memory.
  • Write a query with several joins and a subquery by hand, then explain how you would find and fix its slow part with an index.

Deliverable: A DELETE, DROP and TRUNCATE table, one PL/SQL package, and one multi-join query with a written tuning note.

Day 4 — Coding without an IDE

  • In a plain editor, write a prime-number program for 1 to 100 twice: trial division up to the square root and a sieve. State the complexity of each.
  • Write a reverse-a-number function and test it on negatives, trailing zeros and values near the integer limit.
  • Solve one classic dynamic programming problem and one graph traversal problem from scratch, narrating your approach as if sharing a screen.

Deliverable: Four working solutions (primes, reverse number, one DP, one graph) with edge-case tests and a complexity line for each.

Day 5 — Frontend lifecycle and architecture

  • For React or Angular, whichever is on your CV, write the lifecycle in order and what belongs in each stage, such as setup, updates, cleanup and event handling.
  • Explain microservice service discovery and JPA transaction boundaries in your own words, with one concrete example each.
  • Prepare a spoken answer to how you would scale one application you know, naming the first thing you would measure.

Deliverable: A lifecycle cheat sheet, two short explanations (service discovery and JPA transactions), and a scaling talk track.

Day 6 — Behavioral stories

  • Write STAR outlines for the Friday-evening production bug and the recurring client issues scenarios, each with a number and a systemic follow-up.
  • Write a 60-second answer on why you want to join Azentio Software and what specific skill you bring, using your lane from day 1.

Deliverable: Two STAR outlines, one written motivation answer, and a note on what the practice narration changed.

Day 7 — Full mock pass

  • Run a timed mock on a shared screen: one technical-knowledge question, one coding problem written without an IDE, one SQL query and one behavioral story, in that order.
  • Fix the weakest answer from the mock and rewrite it.

Deliverable: A scored list of the mock answers with the weakest one rewritten, and a written debugging sequence for the latency practice question.

Behavioral preparation: production pressure and client issues

Candidates report that the panel stage mixes technical and behavioral discussion, and the reported scenarios share a theme: production pressure and client relationships in enterprise software. Prepare stories where you made decisions, were honest about trade-offs, and followed through with a fix or a process change.

  1. Why do you want to join Azentio Software, and what specific value would you bring to the team?
  2. Walk through the architecture of a project on your resume and one design decision you would change.
  3. Tell me about a time you did not know the answer to a technical question and how you found it.

How do you handle a critical bug report on a Friday evening that threatens your weekend plans?

Medium · Behavioral & Situational

Approach

  1. Open with triage, not heroics: confirm severity and blast radius first. Who is affected, is data being corrupted or only displayed wrongly, and is money or a regulated process involved? Candidates describe banking and insurance software, so wrong data is worse than slow data.
  2. Stabilise before you diagnose. Say what you would reach for first: roll back the last release, switch off a feature flag, or apply a small configuration change. Then reproduce the bug from logs and the failing request and find the cause, rather than guessing at a fix.
  3. Communicate early and on a schedule: acknowledge the report, tell your lead or the on-call owner, and send short updates with what is known, what is being done and the next update time. Pull in a colleague for a second pair of eyes on a production change instead of acting alone.
  4. Be honest about the personal cost without making it the story. Say you would work the issue because the impact justifies it, agree who covers when, and take the time back afterward. Refusing, or presenting yourself as a martyr, are both weak answers.
  5. Close with the result and the follow-up: a regression test, an alert or monitoring change, and a short postmortem. In STAR form, spend two sentences on situation and task and most of the answer on action and result, with a real number such as users affected or time to mitigate.

Follow-up

  • How do you decide between rolling back and shipping a forward fix when the cause is unclear?
  • What would you do if you cannot reproduce the bug and the client is waiting?
  • The fix requires a change to production data or a database script. How do you make it safe?

If a client reports issues consistently, impacting your work-life balance for months, how do you communicate a

Medium · Behavioral & Situational

If a client reports issues consistently, impacting your work-life balance for months, how do you communicate and manage this?

Approach

  1. Separate the feeling from the evidence. Keep a simple log of incidents over the months: date, hour, symptom and root cause category. A pattern such as the same defect recurring, missing monitoring or unclear requirements turns a complaint into a problem the team can solve.
  2. Raise it with your manager or team lead first, with the log and two or three options: a permanent fix for the recurring defect, an on-call rotation so one person is not always the contact, or clearer severity levels and response windows agreed with the client.
  3. Communicate with the client constructively. Acknowledge the impact on them, share a written root-cause summary and a date for the permanent fix, and agree what counts as urgent out of hours. Do not blame the client and do not quietly absorb the load.
  4. Show the outcome: fewer out-of-hours incidents after the fix or the new agreement, and a relationship that stayed intact. Mention what you learned about setting boundaries early.
  5. If your real story is smaller, say so and use it honestly. Inventing a dramatic example is the common way this answer falls apart under follow-up.

Follow-up

  • What if your manager says the client is the priority and nothing can change?
  • How do you tell a client that something is not urgent without damaging the relationship?
  • How would you measure whether the changes actually reduced the load?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

  1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
  2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
  3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
  4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

  • What would you do differently in the first five minutes, given the same dashboard and no more information?
  • Which follow-up action did you deliberately not take, and why was dropping it the right call?