BizViz Technologies Software Engineer Interview Guide

The 60-second brief

BizViz Technologies builds data visualization and analytics products, and candidates describe the Software Engineer role as work on that analytics platform: turning product requirements into production code, owning modules from development and unit tests through deployment support, reviewing code, and troubleshooting production issues. The backend stack candidates describe is Java (Java 8 and later), SQL with MySQL, Spring Boot and Hibernate, with Hadoop or other big data experience and front-end integration listed as extras. Candidates also mention working with US-based counterparts and across time zones, so written and spoken clarity is part of the job as well as the code.

This guide is for Software Engineer candidates, mostly mid-level (candidates describe roughly two or more years of professional development). It covers the four reported stages, the sixteen questions candidates report across Java core and concurrency, Spring and Hibernate, relational databases, and project or debugging stories, how to prepare for the CCAT, and a seven-day plan. It does not cover pay or team-specific details, which vary.

Candidates report four stages over about three to five weeks: an application review, a CCAT aptitude test, a set of technical deep-dives mixing coding and architecture, and a final leadership or CEO conversation.

Focus areas

• Java
• Object-Oriented Programming (OOP)
• Dependency Injection

Overview

The reported work is building and maintaining parts of a data analytics platform. Candidates describe the day-to-day as converting product requirements into working code, owning a module through unit testing and deployment support, joining code reviews, and chasing down production problems. That shapes the loop: expect to show you can write correct Java, reason about how a database executes your queries, and explain what you did on a real project and why.

The question list is concentrated in four areas. Java core and concurrency covers the four OOP principles, synchronized versus Callable versus Future, ThreadPoolExecutor, lambdas and the Stream API, and Optional. Spring and Hibernate covers dependency injection, the Spring Boot application lifecycle, lazy versus eager fetching, and how Hibernate manages transactions. The database questions are ACID, the nth highest salary query, cursors and stored procedures, and practical uses of complex joins. The last group is a hard technical challenge, a project you led, and debugging a production issue. Candidates also describe stacks and queues, Big O, Singleton and Factory patterns, indexing and isolation levels as evaluation areas, and system design topics (microservices communication, API design, concurrent requests, load balancing, consistency) for more senior roles.

Candidates are told not to memorize answers and that the parameters of a question may change mid-answer, so rehearse the reasoning rather than a script. For each topic, be able to give a definition, a small piece of code or SQL you can write from memory, one trade-off, and one way it fails in production. The plan below follows that pattern, and it starts with CCAT practice because that test is reported as an early gate that no amount of Spring knowledge will help with.

The BizViz Technologies interview process

Candidates describe four stages. The technical stage is plural, and the mix of local and international engineering leads reportedly depends on the team.

Application Review

Candidates describe this stage as a review of your application against the role, before any test or conversation. No questions are reported for it. The role is described as needing Java 8 and later, SQL with MySQL, Spring Boot and Hibernate, with roughly two or more years of experience for mid-level roles, so your CV should make that match easy to see. The same CV then becomes material for later stages, since candidates are advised to be ready to explain the reasoning behind every technical choice in any project listed.

What to demonstrate

• How your listed experience lines up with the reported stack: Java 8+, SQL/MySQL, Spring Boot and Hibernate
• Whether your years of development experience fit the level you are applying for
• Whether each project entry states what you built and what you decided

How to prepare

• Rewrite each project entry so it names the language, framework, database and your own contribution, and cut anything you could not discuss in depth.
• For each project, write down two technical choices you made and the alternative you rejected, so the CV is something you can defend later.
• If you have Hadoop, big data or front-end integration experience, state it explicitly because those are listed as extras.

Cognitive Aptitude Assessment

Candidates report a CCAT (Criteria Cognitive Aptitude Test) as a frequent early hurdle, with 50 questions in 22 minutes. It is a general aptitude test of logic and basic quantitative reasoning, so none of your Java or SQL knowledge applies. The only way to prepare is timed practice that builds speed and accuracy together.

What to demonstrate

• Problem-solving potential, which candidates describe this stage as establishing a baseline for
• Logic puzzle and basic quantitative reasoning skills
• Pace: answering 50 questions inside a fixed 22-minute window

How to prepare

• Do full-length practice sets with a real timer in one sitting, and record your score and unfinished questions each time.
• Drill number series, percentages, ratios, word problems and verbal analogies until the routine ones take seconds.
• Decide a skip rule before test day, for example moving on from a question that is not yielding, and check whether wrong answers are penalised before you guess.

Technical Deep-Dives

Candidates describe multiple technical rounds that include coding challenges and architectural discussions, with local and international engineering leads involved depending on the team. The reported question pool for this role spans Java core and concurrency, Spring and Hibernate, SQL and transactions, and production debugging, and candidates describe data structures, Big O, design patterns and indexing as evaluation areas. Approach each question by clarifying requirements, stating constraints, then giving a solution and its trade-offs. For a coding exercise, write working code and trace it on a small input before declaring it done.

What to demonstrate

• Working, readable Java in a coding exercise, including stacks, queues and complexity analysis
• Framework and database fundamentals: dependency injection, Hibernate fetching and transactions, ACID, joins and indexes
• Architectural reasoning: API design, handling concurrent requests, and the trade-offs of your choices
• Ability to explain why you chose an approach, not only what it is

How to prepare

• Write from memory a thread-safe counter, a Callable submitted to a ThreadPoolExecutor, and the nth highest salary query in MySQL.
• Reproduce the lazy-loading N+1 problem in Hibernate and fix it with a join fetch, so you can explain fetching from an actual symptom.
• Practise a short architecture discussion: a small API for querying analytics data, how concurrent requests are handled, and how services talk to each other.
• Prepare a debugging walkthrough for a production issue that names what you check first, what you rule out, and how you confirm the fix.

Leadership or CEO Round

Candidates describe the final stage as a leadership or CEO conversation about alignment with the company's vision and your professional journey so far. It is the least technical stage on paper, and the stories you rehearse for the difficult-challenge and led-a-project questions are the natural material for it. Come with a coherent account of how your career got here, why this kind of data analytics work, and what you would want to own.

What to demonstrate

• The coherence of your career story and the reasons behind your moves
• Alignment with the company's direction, as candidates describe this stage
• Ownership: what you personally decided and delivered on past projects

How to prepare

• Write a short career narrative that links each role to the next and ends at why this role, naming specific projects.
• Prepare two project stories, one hard technical challenge and one project you led, each with your decisions, the obstacles and a measured result.
• Read the company's public material on its data visualization and analytics products so your interest in the work is specific, and prepare one question about the team you would join.
• Prepare an example of working with colleagues in other time zones, since candidates mention US-based counterparts.

Where candidates lose points

Reciting the four OOP principles or the definition of dependency injection with no code behind it

For each concept, keep one tiny Java example ready: an interface with two implementations for polymorphism, a private field with a validating setter for encapsulation, and a service whose repository is passed in through the constructor so a test can replace it. Say the benefit in terms of what the example lets you change without editing the caller.

Treating synchronized, Callable and Future as three alternatives for the same thing

Keep them in their layers: synchronized is mutual exclusion on a monitor, Callable is a task that returns a value and may throw a checked exception, and Future is the handle you get back when you submit it to a ThreadPoolExecutor. Write one example that uses all three, and be able to say what the pool's core size, queue and rejection policy do when work arrives faster than it completes.

An nth highest salary query that returns the wrong row when salaries are duplicated, or silently misbehaves when n exceeds the number of distinct salaries

Write it with DENSE_RANK and with DISTINCT plus LIMIT/OFFSET, run both on data containing ties, and state what your query returns when fewer than n distinct salaries exist. Mention the MySQL version your window-function answer depends on.

Describing lazy and eager fetching in Hibernate as a definition without its consequences

Tie each to a symptom: lazy loading can produce one query per parent row (N+1) and a LazyInitializationException once the session is closed, while eager fetching can pull large graphs you did not need. Know how a join fetch or a query tailored to the screen fixes the first, and where the transaction boundary sits.

Treating the CCAT as a formality and arriving without timed practice

Run complete 50-question, 22-minute practice sets in the days before, log which question types slow you down, and drill those. Accuracy and pace are both reported as important, so practise deciding quickly when to move on.

Questions & practice

Describe the four principles of Object-Oriented Programming (OOP).

Medium · Java Core and Concurrency

Approach

1. Name the four principles with a Java mechanism for each: encapsulation (private fields behind methods that enforce invariants), inheritance (extends for one class, implements for many interfaces), polymorphism (a supertype reference calling the subtype's override at runtime) and abstraction (abstract classes and interfaces that expose behaviour, not implementation).
2. Split polymorphism into its two forms: overloading is resolved at compile time from the static argument types, overriding is resolved at runtime by dynamic dispatch on the object's actual class.
3. Contrast abstract classes with interfaces after Java 8: interfaces can carry default and static methods but no instance state; an abstract class can hold fields and constructors, and a class can extend only one.
4. Show judgment, not just definitions: prefer composition when the relationship is 'has-a', keep subclasses substitutable for their base (Liskov), and note that a setter for every field defeats encapsulation.

Follow-up

• When would you pick an abstract class over an interface now that interfaces can have default methods?
• Which overload is called when you pass null to methods taking String and Object, and why?
• Give an example where inheritance broke encapsulation and how composition would fix it.

Explain the difference between synchronized, Callable, and Future in Java concurrency.

Medium · Java Core and Concurrency

Approach

1. Say first that these are different kinds of thing: synchronized is a locking mechanism, Callable is a task, Future is a handle to a task's result.
2. synchronized acquires the object's intrinsic monitor (the Class object for static methods), gives mutual exclusion and a happens-before edge so writes made inside the block are visible to the next thread that takes the same lock; it is reentrant and cannot be interrupted while waiting.
3. Callable<V>.call() returns a value and may throw a checked exception, unlike Runnable.run(), which returns void and cannot throw checked exceptions.
4. Submitting a Callable to an ExecutorService returns a Future<V>: get() blocks, get(timeout, unit) throws TimeoutException, cancel(true) interrupts the running thread, and an exception thrown by the task comes back wrapped in ExecutionException.
5. Tie them together: tasks run through Futures that touch shared mutable state still need synchronization (or atomics or concurrent collections), and CompletableFuture lets you chain results with thenApply or thenCombine instead of blocking on get().

Follow-up

• When would you use ReentrantLock instead of synchronized (tryLock, fairness, interruptible waits, several Conditions)?
• What does Future.get() do if the Callable threw an exception, and how do you get the original cause?
• Is volatile enough to make a counter++ thread-safe? Why not?

How do you utilize ThreadPoolExecutor, and why is it important for performance?

Medium · Java Core and Concurrency

Approach

1. List the constructor parameters and what each controls: corePoolSize, maximumPoolSize, keepAliveTime, workQueue, ThreadFactory and RejectedExecutionHandler.
2. Explain the submission order correctly: below core size a new thread is started; otherwise the task is queued; only if the queue is full does the pool grow toward the maximum; past that the task is rejected. With an unbounded LinkedBlockingQueue the maximum is never reached.
3. Name the trap in the Executors factories: newFixedThreadPool uses an unbounded queue, so a backlog grows memory without limit, and newCachedThreadPool can create threads without bound. Prefer an explicit bounded queue and a rejection policy such as CallerRunsPolicy for backpressure (the default AbortPolicy throws RejectedExecutionException).
4. Size it by workload: CPU-bound work near Runtime.getRuntime().availableProcessors(); I/O-bound work larger, roughly cores x (1 + wait time / compute time). The performance gain is thread reuse and bounded concurrency, not extra CPU.
5. Cover operations: name threads with a ThreadFactory, remember submit() captures exceptions in the Future while execute() lets them reach the uncaught handler, and shut down with shutdown() plus awaitTermination(), falling back to shutdownNow().

Follow-up

• What happens to a new task when the queue is full and the pool is already at maximum size?
• How would you size one pool that handles both database calls and CPU-heavy report generation?
• How would you monitor a pool in production to tell whether it is undersized?

What is Optional, and how does it prevent common runtime errors?

Medium · Java Core and Concurrency

Approach

1. Optional is a container that holds either a non-null value or nothing; it makes absence part of a method's return type so the caller has to handle it instead of forgetting a null check.
2. Know the factories: Optional.of(null) throws NullPointerException, ofNullable wraps a possibly null value, empty() is the absent case.
3. Use the combinators rather than isPresent()/get(): map, flatMap, filter, ifPresent, orElseThrow. orElse evaluates its argument eagerly even when a value is present; orElseGet takes a Supplier and runs only when empty.
4. Be precise about the limit: it reduces NullPointerExceptions but does not eliminate them, since get() on an empty Optional throws NoSuchElementException and an Optional reference can itself be null.
5. State the usage rules: return types only; not fields (Optional is not Serializable, which matters for entities and DTOs), not method parameters, and return an empty collection instead of Optional<List>. Use OptionalInt and its relatives for primitives.

Follow-up

• Show a case where orElse instead of orElseGet causes a real bug or a performance cost.
• When do you need flatMap instead of map on an Optional?
• Why is Optional a poor choice for a field on a Hibernate entity?

Write a query to find the nth highest salary in a table.

Medium · Database Management and SQL

Approach

1. Clarify first: does nth mean nth distinct salary when there are ties, and what should come back if fewer than n distinct salaries exist (usually NULL)?
2. Window-function answer (MySQL 8+): rank with DENSE_RANK() OVER (ORDER BY salary DESC) in a subquery or CTE, then filter rank = n. Explain why DENSE_RANK and not RANK (which leaves gaps after ties) or ROW_NUMBER (which breaks ties arbitrarily).
3. LIMIT answer: SELECT DISTINCT salary ORDER BY salary DESC LIMIT 1 OFFSET n-1, wrapped as a scalar subquery so an empty result becomes NULL. MySQL's LIMIT does not accept an expression, so inside a function compute n-1 into a variable first or use a prepared statement.
4. Portable fallback: a correlated subquery keeping the salary where COUNT(DISTINCT salary) of higher salaries equals n-1. It is O(n squared) in rows, so mention it only to show you know it.
5. Edge cases and cost: filter out NULL salaries (in MySQL they sort last in descending order but DENSE_RANK still ranks them), validate that n is at least 1, and note that an index on salary lets the ORDER BY ... LIMIT form avoid a full sort.

Follow-up

• Return the nth highest salary per department.
• Return every employee who earns the nth highest salary, not just the value.
• How does each version behave on a table with 50 million rows?

Explain the practical use cases for complex Join queries.

Medium · Database Management and SQL

Approach

1. Anchor each join type to a real report: INNER JOIN for matched rows (orders with their customers); LEFT JOIN to keep every row of the driving table (all products with sales, zero where none); LEFT JOIN ... WHERE right.id IS NULL or NOT EXISTS as an anti-join (customers with no orders). Avoid NOT IN against a nullable column: one NULL in the subquery makes it return no rows.
2. Self-joins for hierarchies (employee to manager) and for comparing rows of one table; non-equi joins for ranges, such as matching a transaction date to a price or tier validity window.
3. Chains for reporting (orders to order items to products to categories) and the fan-out trap: joining two one-to-many children multiplies rows and inflates SUMs, so aggregate each child in a subquery before joining.
4. For dashboard-style output, CROSS JOIN a calendar table with a dimension and LEFT JOIN the facts so missing days show as zero instead of disappearing; a filter on the outer-joined table belongs in ON, because in WHERE it turns the LEFT JOIN into an INNER JOIN.
5. Performance: index the join keys, read EXPLAIN for the join order and access type, and note that MySQL has no FULL OUTER JOIN (emulate it with a LEFT JOIN UNION a RIGHT JOIN) and has used hash joins for equi-joins since 8.0.18.

Follow-up

• Revenue doubled after you added a join to a report; how do you find and fix the cause?
• How would you emulate a FULL OUTER JOIN in MySQL?
• What would you look for in EXPLAIN output to decide whether a join needs a new index?

Describe the utility of lambda expressions and the Stream API compared to traditional collections.

Medium · Java Core and Concurrency

Approach

1. A lambda is a compact implementation of a functional interface (Function, Predicate, Consumer, Supplier or your own); method references are shorthand for the same; captured local variables must be effectively final.
2. A stream is a one-shot pipeline over a source: intermediate operations (filter, map, sorted) are lazy and nothing runs until a terminal operation (collect, reduce, count, forEach); reusing a consumed stream throws IllegalStateException.
3. Compare with loops on concrete cases: Collectors.groupingBy for a grouped count, short-circuiting with anyMatch, findFirst or limit, and Collectors.toMap, which throws IllegalStateException on a duplicate key unless you pass a merge function.
4. State the costs: per-element overhead for small collections, awkward checked exceptions inside lambdas, harder stack traces, and side effects in lambdas that break under parallel streams.
5. parallel() runs on the common ForkJoinPool and pays off only for large, CPU-bound work on sources that split well (arrays, ArrayList), not for I/O or a LinkedList.

Follow-up

• What is the difference between map and flatMap? Give a case that needs flatMap.
• Why is adding to a shared ArrayList inside forEach on a parallel stream a bug, and what do you write instead?
• How do you handle a method that throws a checked exception inside a stream pipeline?

Explain the concept of dependency injection and its advantages in Spring.

Medium · Enterprise Frameworks (Spring and Hibern

Approach

1. Define it: objects receive their dependencies from outside instead of constructing them; in Spring the IoC container (ApplicationContext) creates the beans and wires them by type.
2. Compare the three styles: constructor injection (final fields, required dependencies visible, easy to construct in a plain unit test; a single constructor needs no @Autowired since Spring 4.3), setter injection for optional dependencies, and field injection, which hides dependencies and needs reflection or a container in tests.
3. Give the concrete advantages: code depends on interfaces so implementations can be swapped (@Profile, @Qualifier, @Primary), mocks drop in for tests, the container manages scope (singleton by default, prototype, request, session) and wraps beans in proxies so @Transactional and other AOP work.
4. Cover the failure modes: two beans of one type raise NoUniqueBeanDefinitionException until you qualify one; a constructor-injection cycle fails at startup, and Spring Boot 2.6+ rejects circular references by default, which usually signals a class to split.

Follow-up

• Why is constructor injection preferred over field injection?
• You have two PaymentGateway implementations; how do you pick one per environment?
• A singleton bean needs a new prototype-scoped instance on each call; how do you get one?

How does the Spring Boot application lifecycle function?

Medium · Enterprise Frameworks (Spring and Hibern

Approach

1. Startup: main() calls SpringApplication.run, which works out the application type (servlet, reactive or none), loads initializers and listeners, prepares the Environment from application.properties or yml, profiles, environment variables and command-line arguments, then creates and refreshes the ApplicationContext.
2. Refresh: bean definitions come from component scanning and auto-configuration classes guarded by conditions such as @ConditionalOnClass and @ConditionalOnMissingBean; BeanFactoryPostProcessors run, then singletons are instantiated and the embedded web server starts.
3. Per-bean lifecycle in order: instantiate, inject dependencies, Aware callbacks, BeanPostProcessor before-initialization (which runs @PostConstruct), afterPropertiesSet, custom init method, BeanPostProcessor after-initialization (where AOP proxies are created), use, then @PreDestroy and destroy on shutdown.
4. After refresh, CommandLineRunner and ApplicationRunner beans run, then ApplicationReadyEvent fires; ApplicationFailedEvent fires if startup throws. Earlier events include ApplicationStartingEvent, ApplicationEnvironmentPreparedEvent and ContextRefreshedEvent.
5. Shutdown: a JVM shutdown hook closes the context and destroy callbacks run; with server.shutdown=graceful (Boot 2.3+) the server stops taking requests and lets in-flight ones finish first.

Follow-up

• Where would you put code that must run once every bean is ready, and why not in @PostConstruct?
• How do you find out which auto-configurations applied and why one backed off?
• Why does a @Transactional method not get a transaction when it is called from @PostConstruct?

Discuss the differences between lazy and eager fetching in Hibernate.

Medium · Enterprise Frameworks (Spring and Hibern

Approach

1. LAZY returns a proxy or an uninitialized collection that loads on first access while the session is open; EAGER loads the association together with its owner. JPA defaults are EAGER for @ManyToOne and @OneToOne and LAZY for @OneToMany and @ManyToMany.
2. Name the two classic failures: LazyInitializationException when a lazy association is touched after the session closes (for example while serializing in a controller), and N+1 selects when iterating parents and touching each child. EAGER does not fix N+1: a JPQL query ignores the mapping's join and issues secondary selects.
3. Default everything to LAZY and choose fetching per use case: JOIN FETCH in JPQL, @EntityGraph on a repository method, @BatchSize or hibernate.default_batch_fetch_size to load children in IN batches, or a DTO projection for read-only screens.
4. Know the edge cases: join-fetching two List (bag) collections throws MultipleBagFetchException, join fetch multiplies parent rows (deduplicate), and pagination combined with a collection join fetch makes Hibernate page in memory and log a warning.
5. Mention that Spring Boot enables open-session-in-view by default, which hides lazy-loading problems by running queries during view rendering; turning it off makes fetching explicit.

Follow-up

• How would you detect an N+1 problem in an existing service?
• You need a page of 20 orders with their line items; how do you avoid in-memory pagination?
• What are the downsides of leaving spring.jpa.open-in-view enabled?

How does Hibernate ORM manage database transactions effectively?

Medium · Enterprise Frameworks (Spring and Hibern

Approach

1. Describe the unit of work: the Session or EntityManager keeps a persistence context (first-level cache), tracks loaded entities, and on flush writes only what dirty checking finds changed; with the default AUTO flush mode it flushes before commit and before queries that touch affected tables.
2. Boundaries in a Spring app: @Transactional on service methods, applied through a proxy and the JpaTransactionManager; propagation REQUIRED joins an existing transaction, REQUIRES_NEW suspends it and starts another; by default rollback happens on unchecked exceptions and Errors, not checked exceptions, unless rollbackFor says so.
3. Concurrency: isolation comes from the database's isolation level; Hibernate adds optimistic locking with a @Version column (a stale update fails with an optimistic lock exception) and pessimistic locking via LockModeType.PESSIMISTIC_WRITE, which issues SELECT ... FOR UPDATE.
4. Name the pitfalls: self-invocation inside the same class bypasses the proxy so no transaction starts, @Transactional on private methods is ignored by proxy-based AOP, and long transactions hold connections and locks.
5. Performance: readOnly=true lets Hibernate skip dirty checking; for bulk writes set hibernate.jdbc.batch_size and flush and clear every N entities, and note that IDENTITY id generation prevents JDBC insert batching.

Follow-up

• A service method throws a checked exception after two saves; is anything rolled back?
• Two users edit the same record at once; how do you stop the second save from silently overwriting the first?
• Why does calling a @Transactional method from another method in the same class not start a transaction?

Explain ACID properties and their importance in transaction management.

Medium · Database Management and SQL

Approach

1. Define each with a mechanism, using a bank transfer as the example: Atomicity, both the debit and the credit commit or neither does (undo log, rollback); Consistency, constraints such as foreign keys, unique and check constraints hold before and after; Isolation, concurrent transactions do not see each other's partial work; Durability, a committed change survives a crash (write-ahead or InnoDB redo log flushed at commit).
2. Go deeper on isolation, the part with real trade-offs: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ and SERIALIZABLE, against the anomalies they allow (dirty read, non-repeatable read, phantom). MySQL InnoDB defaults to REPEATABLE READ; PostgreSQL defaults to READ COMMITTED.
3. Explain how InnoDB does it: MVCC gives consistent snapshot reads, while locking reads (SELECT ... FOR UPDATE) take row and next-key locks; stronger isolation costs more locking, waits, deadlocks or retries.
4. Point out that consistency is partly the application's job: the database enforces declared constraints, not business rules it does not know about.

Follow-up

• Show a lost update under READ COMMITTED and three ways to prevent it.
• Which durability setting would you relax to speed up bulk loads, and what do you risk?
• How do you keep two services consistent when one business action spans both databases?

How do you utilize cursors and stored procedures in database operations?

Medium · Database Management and SQL

Approach

1. Stored procedure: a named routine stored in the database and run with CALL, with IN, OUT and INOUT parameters. Use it to cut round trips for multi-statement work, keep a multi-step change inside one transaction, or grant EXECUTE instead of direct table access.
2. Call it from Java with a CallableStatement using {call proc(?, ?)} and registerOutParameter, or through Spring's SimpleJdbcCall or JPA's StoredProcedureQuery.
3. Cursor in MySQL: DECLARE the cursor for a SELECT, DECLARE CONTINUE HANDLER FOR NOT FOUND to set a done flag, then OPEN, FETCH INTO variables inside a LOOP, and CLOSE. MySQL cursors are read-only, forward-only and asensitive.
4. Argue against the cursor where you can: a set-based UPDATE ... JOIN or INSERT ... SELECT usually replaces a row-by-row loop and is far faster; keep cursors for per-row logic that cannot be expressed as one statement.
5. Give the trade-offs of logic in the database: harder to version, test and debug, vendor-specific, and it puts CPU load on the database. On the client, stream large result sets instead (Connector/J with setFetchSize(Integer.MIN_VALUE) or useCursorFetch=true).

Follow-up

• Rewrite a cursor loop that applies a per-customer discount as one set-based statement.
• How do you handle an error halfway through a procedure so its earlier writes roll back?
• When would you refuse to move business logic into stored procedures?

How do you approach debugging a complex, production-level issue?

Medium · Problem Solving and Behavioral

Approach

1. Mitigate before diagnosing: size the impact (which users, endpoints, since when), then roll back, switch off a feature flag or add capacity if that stops the damage, and say who you notify.
2. Build a timeline of what changed: deploys, config, traffic or data volume, dependency versions, infrastructure. Then line up the signals around the start time: error rate, p99 latency, GC pauses, thread-pool and connection-pool saturation, and logs filtered by correlation or request id.
3. Use JVM and database tools matched to the symptom: several thread dumps (jstack or jcmd Thread.print) for hangs, deadlocks and blocked threads; a heap dump (jmap or -XX:+HeapDumpOnOutOfMemoryError) analysed in a tool such as Eclipse MAT for memory growth; the MySQL slow query log with EXPLAIN, and SHOW ENGINE INNODB STATUS for lock waits and deadlocks.
4. Work by hypothesis: reproduce with production-like data in a lower environment, change one variable at a time, and check that the instrumentation is accurate before trusting a symptom.
5. Close the loop: confirm the fix against the same metric that showed the problem, add a regression test and an alert for that signal, and write up root cause versus trigger.

Follow-up

• Heap usage climbs for three days and then the service dies with OutOfMemoryError; what are your next steps?
• Only one tenant sees timeouts while everyone else is fine; where do you look first?
• How do you collect diagnostics in production without making the outage worse?

Suggested practice checklist

The plan starts with the CCAT and a CV audit, then works through the reported Java, Spring and Hibernate, and SQL questions with code you write yourself, and ends with debugging and the project stories for the final round.

Day 1 — Map the loop and baseline your CCAT

• Write the four reported stages on one page and, beside each, what you will be asked to show: CV defence, aptitude pace, technical depth, career story.
• Take a timed 50-question, 22-minute CCAT-style set and note which question types cost the most time.
• Rewrite each CV project entry to name the stack and your own decisions, and mark the two projects you can discuss most deeply.

Deliverable: A one-page loop map, a scored CCAT practice log showing slow question types, and a revised CV with stack-labelled project entries.

Day 2 — Java core: OOP, lambdas, Streams and Optional

• Write a small Java example that demonstrates abstraction, encapsulation, inheritance and polymorphism, and say in one sentence what each lets you change safely.
• Take a loop that filters, groups and sums a list and rewrite it as a Stream pipeline with collectors; note one case where the plain loop is clearer.
• Write Optional chains using map, filter and orElseGet, and explain why Optional suits return types better than fields or parameters.

Deliverable: A Java file holding the OOP example, the loop-to-Stream rewrite and an Optional chain, plus spoken answers to the three matching questions.

Day 3 — Concurrency: synchronized, Callable, Future and thread pools

• Write a shared counter that is unsafe, then fix it with synchronized, and say what the monitor protects.
• Submit Callable tasks to a ThreadPoolExecutor, collect results through Future.get, and handle an exception thrown inside a task.
• Construct a ThreadPoolExecutor by hand with core size, maximum size, a bounded queue and a rejection policy, and explain what happens when the queue fills.

Deliverable: A runnable class with the unsafe and fixed counter and the pool example, plus a spoken answer comparing synchronized, Callable and Future and another on why a pool helps performance.

Day 4 — Spring and Hibernate

• Wire a service with constructor injection, then replace its repository with a test double and show the caller is unchanged.
• Write out the Spring Boot lifecycle in order, from starting the application and creating the context and beans through startup runners to shutdown, and name where you would hook in.
• Reproduce an N+1 query with a lazy association, fix it with a join fetch, and describe when you would keep fetching lazy.
• Mark a service method transactional, explain where the transaction starts and ends and what triggers a rollback by default, and say how Hibernate's session relates to the transaction.

Deliverable: A wired example with a test double, a one-page lifecycle sequence, an N+1 before-and-after, and spoken answers to the four framework questions.

Day 5 — SQL, transactions and joins

• Write the nth highest salary query three ways (DENSE_RANK, DISTINCT with LIMIT/OFFSET, correlated subquery) in MySQL and test each against ties and an n larger than the data.
• Explain each ACID property with an example, then list the isolation levels with the anomaly each prevents.
• Write a stored procedure that uses a cursor, then rewrite it as one set-based statement and say when the cursor is justified.
• Practise inner, left, self and anti-joins on a small schema and check with EXPLAIN which index each uses.

Deliverable: A SQL file with the three nth-highest queries and test data, the cursor procedure with its set-based rewrite, join examples with EXPLAIN output, and an ACID and isolation-level cheat sheet in your own words.

Day 6 — Coding fundamentals, design and production debugging

• Implement a stack and a queue in Java, array-backed and linked, with the Big O of each operation.
• Write a thread-safe Singleton and a Factory, and say when each is the wrong tool.
• Sketch an API for querying analytics data: endpoints, how concurrent requests are handled, and how two services communicate.
• Write your production debugging routine as ordered steps: what changed, what the logs and metrics show, how you reproduce, how you narrow the cause, and how you confirm the fix.

Deliverable: Two working Java data structures with complexity, a Singleton and Factory example, a one-page API sketch, and a numbered debugging routine you can say aloud.

Day 7 — Stories and a full rehearsal

• Write STAR outlines for your hardest technical challenge and a project you led, with your decisions, a measurement and a lesson in each.
• Prepare your career narrative and your reasons for wanting this kind of analytics work, using the company's public material.
• Run a full rehearsal aloud: CV walkthrough, two technical answers chosen at random from days 2 to 5, then both stories.

Deliverable: Two STAR outlines, a written career narrative, and a recorded rehearsal you have reviewed for vague or 'we'-only passages.

Project stories for the final conversation

The behavioral questions candidates report are about the hardest technical challenge you have faced, a project you led, and how you debug a production problem. The final leadership or CEO stage is described as covering alignment with the company's vision and your professional journey, so your stories should show your own decisions, the obstacles, a measured result, and why you want this kind of work.

1. How do you approach debugging a complex, production-level issue?
2. Walk me through your career so far and what led you to this role.
3. Tell me about a time you explained a technical trade-off to a product manager or to a colleague in another time zone.
4. Which project on your CV would you redo, and what would you change?

What is the most difficult technical challenge you have faced in your career?

Medium · Problem Solving and Behavioral

Approach

1. Choose a challenge where you made the key technical decision, and which is real for your stack: a slow query on a large table, a thread pool that exhausted under load, an N+1 loading pattern, a deadlock, or a memory leak. A story about a tight deadline alone is not a technical challenge.
2. Use STAR but weight it: two sentences of Situation and Task, then most of your time on Action. Say what you measured first, what hypotheses you ruled out and why, which options you weighed, and why you picked the fix you did.
3. Quantify the result with a before-and-after measurement from the same source, for example query latency, error rate or throughput, and say how you confirmed your change caused the improvement rather than a coincident deploy.
4. Say what the cost of the fix was (extra complexity, a migration, a trade-off against maintainability) and what you would change if you ran the project again. The stories that fall flat use only 'we' with no personal action, stop at the symptom, or give no measurable outcome.

Follow-up

• What alternatives did you consider and why did you reject them?
• How did you confirm your change was the cause of the improvement?
• What would you do differently if you hit the same problem today?

Describe a project you led; what were the primary obstacles and how did you overcome them?

Medium · Problem Solving and Behavioral

Approach

1. Pick a project where you led decisions, not just coordinated tasks. In your first two sentences give the goal, the team size and your role, so the scope of your leadership is clear.
2. Name two or three distinct obstacles and give each a different type: a technical one such as a design or performance choice, a scope or requirements one such as shifting asks from product managers, and a delivery one such as dependencies on another team or a different time zone. For each, say what you did, not what the team did.
3. Show your lead mechanics: how you split the work, agreed interfaces between modules, ran code reviews, tracked risk and reported status to stakeholders. This matters for a role that includes ownership of modules and cross-location collaboration.
4. Close with the result and one lesson. Admit something that went wrong or was cut and how you handled it, because a story where every obstacle dissolves cleanly sounds rehearsed, and one with no result sounds unfinished.

Follow-up

• How did you handle a teammate who disagreed with your design?
• What did you cut or delay, and who did you tell?
• How did you keep people in different locations aligned during the project?

Ship under a deadline and bound the debt you chose

Medium · pagination · technical debt · tradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach

1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.

Follow-up

• At what page depth does the offset version breach your latency budget, given your page size and row counts?
• What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?