Avepoint Software Engineer Interview Guide

The 60-second brief

Candidates describe Avepoint's products as enterprise cloud and data management platforms that organisations use to manage and govern their digital workspaces. The Software Engineer role, as candidates describe it, covers backend work, user-facing features and infrastructure, with some engineers building core platform features and others putting together quick prototypes. The topics candidates report being tested on are Solutions Consulting, SharePoint Integration, Full-Stack Engineering, Prototyping / Building PoCs and Infrastructure Solutions. The requirements candidates describe list C#, Java, JavaScript/TypeScript or Python, relational and non-relational databases, cloud platforms and RESTful API design. Docker, Kubernetes and experience with enterprise collaboration platforms are listed as a plus.

This guide is for software engineers preparing for Avepoint's Software Engineer loop, whether your background is backend, full-stack or infrastructure. It covers the four rounds candidates report, worked approaches to every reported question (cloud and SharePoint integration experience, state management, distributed-system performance, legacy debugging, delivery scenarios and behavioral stories) and a plan that links each day to those questions and to the reviewed practice set.

Candidates report four rounds over about 3-5 weeks: Resume Screen, Recruiter Call, Technical Evaluations and Panel Presentations. They say the panel presentation shows up in some loops and not others, depending on department and region.

Focus areas

• Solutions Consulting
• SharePoint Integration
• Full-Stack Engineering

Overview

Most of the reported questions are about your own experience and how you would handle a situation, not named algorithm puzzles. The technical group asks you to walk through cloud, SharePoint and CRM integration work, to explain state and data flow in a full-stack app, to talk about distributed-system performance and to describe how you debug a legacy codebase. The scenario group covers compressed timelines, vague feature requests, applications that fall over under load and the trade-off between technical debt and features. The behavioral group covers disagreement, code review, ownership and juggling several tasks at once.

Your preparation should therefore rest on concrete material from your own work. For every system you name, be ready to say what you built, which API and auth model you used, how you dealt with throttling and failures, and what you would change now. A loose answer to the integration walk-through, or a scaling answer that stops at 'add servers', gives nobody anything to follow up on. Pick the two or three projects you know best and rehearse them until you can explain the design, the trade-offs and the numbers without notes.

Candidates also report coding assessments in the Technical Evaluations stage, so working code still matters. Practise in the language from the listed stack (C#, Java, JavaScript/TypeScript or Python) that you write fastest. Focus on problems that look like integration work: parsing and reshaping nested payloads, deduplicating records, grouping by tenant, paging through an API. Candidates' example scenarios include a backend API for a multi-tenant cloud application and a real-time sync service for cloud workspaces, so practise multi-tenant data isolation and sync conflict handling as well.

If your loop includes the Panel Presentations stage, it tests something the other rounds don't: presenting a solution design to a group and taking their questions. Treat it as its own deliverable. Build a short deck or diagram covering problem, constraints, architecture, trade-offs and rollout, and rehearse it out loud with someone who will push back.

The Avepoint interview process

Candidates report four rounds in this order, over about 3-5 weeks. Ask your recruiter whether your team's loop includes the panel presentation and which format the technical stage uses.

Resume Screen

Candidates report that the process starts with a resume review that checks your qualifications and fit for the role. They also report that an active GitHub profile with working, documented repositories helps at this stage. Use the resume to show, in its own terms, that you match the listed stack: name the languages (C#, Java, JavaScript/TypeScript, Python), the databases, the cloud platform and any REST APIs you designed. List integration work with collaboration platforms or CRM systems explicitly, because SharePoint Integration and Solutions Consulting are among the reported topics.

What to demonstrate

• Whether your experience matches the listed languages, databases, cloud and REST API requirements
• Evidence of shipped software or personal projects, including public code

How to prepare

• Rewrite each resume bullet as system + your change + result, and name the integration targets (SharePoint, a CRM, a cloud provider) where they apply.
• Pick two GitHub repositories, add a README with setup steps and a short design note to each, and make sure both build from a clean clone.
• Keep one line per project ready that you can expand into the cloud, SharePoint and CRM walk-through if the reviewer follows up.

Recruiter Call

Candidates describe a phone call with a recruiter or HR that checks your qualifications, your interest in the role and logistics. Two answers matter here: a short tour of your relevant experience and a specific reason for wanting Avepoint. Use the call to collect what you need for the rest of the loop. Candidates suggest confirming the interview format (remote or in person) and the office location, and since the panel presentation varies by department and region, ask whether yours includes one.

What to demonstrate

• Whether your qualifications match the role
• Your interest in Avepoint specifically
• Logistical fit: location, format and availability

How to prepare

• Rehearse a short version of the cloud, SharePoint and CRM experience walk-through: one project per platform, what you built, and the result.
• Write a why-Avepoint answer that links its data management and governance products to something you have actually built.
• Write down your questions for the recruiter: coding assessment format and language, whether there is a panel presentation and on what topic, remote or on-site, and timeline.

Technical Evaluations

Candidates report that this stage includes coding assessments, discussions of practical scenarios and in-depth technical interviews with engineering leads. Prepare all three formats. For coding, write working, tested code in one language from the listed stack and state its complexity. For scenarios, have a structured process ready for questions such as an application failing under load or an exception in legacy code. For the in-depth interviews, choose one project you can defend down to the schema, the API contracts and the failure modes. The reported technical and scenario questions are the right practice material for this stage.

What to demonstrate

• Working, readable code in the coding assessments
• Structured reasoning on practical scenarios such as scaling and debugging
• Depth and honesty about the systems you have built

How to prepare

• Solve integration-shaped coding problems: flatten and transform a nested JSON payload, dedupe records by a composite key, aggregate events per tenant.
• Rehearse the scaling-failure and legacy-debugging scenarios as step-by-step processes: measure, contain, isolate, fix, prevent.
• Outline a REST API for a multi-tenant application: resource paths, tenant isolation in every query, auth, pagination and rate limits.
• Pick your deep-dive project and write one page on it: architecture, the hardest bug, the trade-off you would revisit.

Panel Presentations

Candidates describe face-to-face or virtual presentations that assess communication and solution design. They report it in some loops depending on department and region, so confirm it early. If yours has one, ask whether the topic is given in advance or is your own past project. Organise the talk as problem, constraints, options considered, the chosen design, trade-offs and rollout, and leave room for questions. Rehearse with a listener who interrupts, because handling questions from several people is part of what this stage tests.

What to demonstrate

• How clearly you explain a technical solution to a group
• Solution design: whether the architecture fits the stated constraints and the trade-offs are named

How to prepare

• Build one architecture diagram for a project of yours or for a workspace data-sync service, and practise explaining it from the top down.
• Prepare a slide that lists rejected alternatives and why, plus what you would do with more time.
• Do two full run-throughs out loud with a colleague who asks questions mid-talk, and tighten whatever confused them.

Where candidates lose points

Answering the cloud, SharePoint and CRM walk-through with a list of tool names and no integration details.

For each platform, prepare one project with the API you called, the auth model, how you handled paging and throttling, how sync conflicts were resolved and the measurable result. If one platform is new to you, say so and explain how you would approach it.

Treating the sudden-load scenario as 'add more servers' with no diagnosis.

Rehearse the order: scope with metrics, mitigate (shed load, scale stateless tiers, roll back), find the real bottleneck (connection pools, locks, downstream throttling), then the permanent fix and postmortem. Explain why scaling out can make a database bottleneck worse.

Describing legacy debugging as reading the code until the bug turns up, or rewriting the module.

Explain containment first, then reproduction from the stack trace and recent changes, then a characterization test before any change, then a minimal fix with a regression test. Tie it to a real incident.

Showing a clean architecture in the panel presentation with no constraints, alternatives or trade-offs, then struggling with questions.

Organise the talk as problem, constraints, options, decision, trade-offs and rollout. Include a slide of rejected options, and rehearse with someone who interrupts so you get practice answering mid-talk.

Giving a why-Avepoint answer that would fit any employer.

Read the company's public product pages and connect its data management and governance products to specific things you have built, such as integrations, migrations, permissions features or multi-tenant services. Have one specific question ready about a product area.

Questions & practice

How do you maintain code quality and personal productivity when managing multiple concurrent tasks?

Medium · Behavioral and Mindset

Approach

1. This is a work-habits question despite its filing. Answer with a concrete system and an example, not with personality traits.
2. Prioritisation: rank tasks by impact and committed dates, limit work in progress, finish before starting, and tell stakeholders early when two commitments collide instead of quietly slipping both.
3. Quality guardrails that don't depend on attention: automated tests, linters and CI checks, small PRs, a personal pre-merge checklist and a separate branch per task.
4. Context switching: leave a note at each stopping point, batch interruptions such as reviews and messages into set blocks, and protect focus time for the hardest task.
5. Give a time quality slipped under load, what you changed afterwards, and how you would notice it happening again.

Follow-up

• Two people each say their task is the most urgent. What do you do?
• Tell me about a time something you shipped under pressure had a bug. What changed afterwards?
• How do you know when you have taken on too much?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

How would you approach building and prototyping software solutions for a rapid deployment cycle?

Medium · Technical and Domain Knowledge

Approach

1. Start with the question the prototype has to answer and its success criterion, for example 'can I sync 10k documents from a source system with permissions intact', and fix scope to that.
2. Build a thin vertical slice end to end (UI or CLI, API, storage, one real integration) first, before polishing any single layer. Use scaffolding, managed services and existing libraries to save time.
3. Even in a PoC, set up a CI pipeline, a container image if Docker is in your stack, feature flags and one-command deploys, so every iteration can ship and be rolled back.
4. Decide up front what is throwaway and what is kept. Put interfaces at the integration and storage boundaries so the code you keep can be hardened without a rewrite. Never take shortcuts on secrets handling, auth or customer data.
5. Name the trade-off: speed now versus extensibility later, and the signal (a stakeholder demo, usage, a load test) that tells you when to stop prototyping and harden.

Follow-up

• How do you decide between an open-source library and building the component yourself?
• What has to change before this prototype can go to production?
• How do you roll back a bad deploy when you ship several times a day?

Can you explain how you manage state and data flow in a complex full-stack application?

Medium · Technical and Domain Knowledge

Approach

1. Split state into kinds and give each one an owner: server state (data fetched from the API, cached on the client), local UI state (inside a component), shared client state (a store or context), URL state (filters, pagination) and persisted state (database, session).
2. Keep one source of truth for each piece of data and send changes in one direction: user action, API call, server update, cache invalidation, re-render. Don't copy server data into a global store where it can go stale.
3. On the backend, keep services stateless so they scale horizontally, and put state in the database, a cache or a session store. Say how you invalidate caches when data changes.
4. Cover concurrency: optimistic updates with rollback on failure, version numbers or ETags to detect conflicting edits (412 on mismatch), and discarding out-of-order responses when several requests are in flight.
5. Edge cases to raise: stale data across tabs or users, partial failure of a multi-step save, and real-time updates through WebSockets or server-sent events versus polling.

Follow-up

• Two users edit the same record at once. What does each of them see?
• When would you introduce a global store, and when is it overkill?
• How would you push live updates from the server to open clients?

What is your familiarity with infrastructure solutions, and how do you optimize performance for distributed sy

Medium · Technical and Domain Knowledge

What is your familiarity with infrastructure solutions, and how do you optimize performance for distributed systems?

Approach

1. Answer the familiarity half honestly and specifically: which cloud, which container or orchestration tools (Docker and Kubernetes are listed as a plus), and what you operated yourself versus used.
2. Describe the method: measure before changing anything. Look at p50/p95/p99 latency, throughput, error rate and saturation (CPU, memory, connections, queue depth), and use distributed tracing to find where the time goes.
3. Name the levers and when each one applies: caching (cache-aside with TTL, and how you invalidate), connection pooling, batching and removing N+1 calls, async work through queues, indexes and read replicas, partitioning by tenant or key, horizontal scaling of stateless tiers.
4. Cover resilience, since tail latency in a distributed system often comes from slow dependencies: timeouts, retries with exponential backoff and jitter, circuit breakers and bulkheads.
5. State the trade-off for each optimisation, for example caching or replicas give lower latency but stale reads, and give one real before-and-after number from your own work.

Follow-up

• Your cache hit rate is low. How do you work out why?
• A request fans out to five services and p99 is bad. What do you change?
• How do you tell whether a service is CPU-bound or I/O-bound?

How would you handle a situation where a project timeline is compressed and client expectations are unrealisti

Medium · Problem-Solving and Scenarios

How would you handle a situation where a project timeline is compressed and client expectations are unrealistic?

Approach

1. Quantify the gap before negotiating: break the scope into estimated pieces so you can show where the timeline doesn't fit, rather than just saying it is too tight.
2. Offer options instead of a refusal: cut scope to the must-haves, deliver in phases with the riskiest or most valuable part first, add people where the work can actually be split, or move the date.
3. Put the trade-off in writing and agree with the product manager or account owner on what 'done' means for the first release, so expectations change through an explicit decision.
4. Protect quality where failure would be expensive (data integrity, security, migrations) and say openly what you are deferring, such as polish, nice-to-have features or a non-essential report.
5. Back it with a real example if you have one, including how the client relationship ended up, and close with the check-ins you used to catch slippage early.

Follow-up

• The client rejects every option. What do you do?
• Your manager already committed to the date. How do you raise the problem?
• What would you refuse to cut, even under pressure?

Describe how you break down a vague feature request into actionable engineering milestones.

Medium · Problem-Solving and Scenarios

Approach

1. Clarify first: who the user is, what problem they have today, how success will be measured and what is explicitly out of scope. Turn the answers into acceptance criteria.
2. List the unknowns (an external API, data volume, permissions model) and schedule a time-boxed spike on the riskiest one as the first milestone.
3. Cut the work into vertical slices that each deliver something demoable end to end, starting with a walking skeleton, rather than horizontal layers like 'database done', 'API done'.
4. For each milestone give its scope, dependencies, an estimate with a confidence level and a demo point for stakeholder feedback. Use a concrete example, such as a permissions report for workspace admins: export first, then filters, then scheduling.
5. Say how you handle change: re-plan at each demo, and keep the cut list visible so scope trade-offs are explicit.

Follow-up

• The stakeholder changes the requirement after the second milestone. What happens to your plan?
• How do you estimate a milestone that depends on an API you have never used?
• Which milestone would you drop first if the date moved earlier?

What steps do you take when an application fails to scale under sudden enterprise loads?

Medium · Problem-Solving and Scenarios

Approach

1. Confirm and scope: which endpoints, which tenants, since when. Read latency, error rate and saturation dashboards, and check whether the load is real traffic, a retry storm or a single noisy tenant.
2. Mitigate before you fix: scale out the stateless tier, rate-limit or shed lower-priority traffic, serve cached or degraded responses, pause non-essential background jobs, or roll back if a deploy coincided with the failure.
3. Find the actual bottleneck, which is often not CPU: exhausted database connection pools, lock contention, thread or worker pool saturation, a downstream dependency throttling you, memory pressure and GC pauses.
4. Long-term fixes, tied to what you found: queue-based load levelling and back-pressure, autoscaling on the right signal (queue depth or concurrency rather than CPU alone), per-tenant quotas, caching, query and index fixes, and regular load tests at peak-plus-margin.
5. Close with a blameless postmortem: timeline, root cause, action items with owners, and an alert that would have caught it earlier.

Follow-up

• Autoscaling added instances but latency got worse. Why might that happen?
• How would you load test for a sudden spike rather than steady traffic?
• One tenant generates most of the load. How do you protect the others?

How do you prioritize technical debt versus new feature development when resources are limited?

Medium · Problem-Solving and Scenarios

Approach

1. Make debt visible and costed: list the items with their effect on incidents, delivery speed, onboarding time or security exposure, so they can be compared with features.
2. Prioritise by interest rate: debt in code the team changes every sprint costs more than ugly code nobody touches. Security and data-integrity risks come first regardless.
3. Pay debt down alongside features: refactor the area a planned feature is about to change, and agree a standing share of capacity with the product manager instead of asking case by case.
4. Argue in business terms: 'this flaky deploy costs about a day per release' persuades better than 'the code is messy'. Then show the payoff afterwards with the same metric.
5. Give a real example where you made this call, including something you chose not to fix and why.

Follow-up

• The product manager refuses any debt work this quarter. What do you do?
• When would you rewrite a component instead of refactoring it?
• How do you show that the debt work paid off?

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 targets one reported round or one group of reported questions. Days 2-4 use reviewed practice problems that match the multi-tenant, data-reshaping and scaling themes in candidates' reports.

Day 1 — Resume, GitHub and the experience walk-through

• Rewrite your resume bullets as system + change + result and make sure the listed languages, databases, cloud and REST work are visible.
• Clean up two GitHub repositories: README, setup steps, a short design note, and a passing build from a clean clone.
• Write and say out loud your cloud, SharePoint and CRM walk-through, one project per platform with API, auth, failure handling and result.
• Write a why-Avepoint answer tied to your own integration or data work.

Deliverable: An updated resume, two documented repositories, a written integration walk-through and a why-Avepoint answer.

Day 2 — Coding assessment practice on data-shaped problems

• Solve the heaviest-tenants-in-a-window problem in your strongest listed language, with tests and a complexity statement.
• Solve the request-canonicalisation and idempotency-fingerprint problem, covering key order, nested objects and number formats.
• Write a function that flattens and transforms a nested JSON payload into flat records, with tests for missing fields and empty arrays.

Deliverable: Three working, tested solutions, each with its time and space complexity written at the top.

Day 3 — Full-stack state, multi-tenant APIs and prototyping

• Draw the state map for an app you built: server, UI, shared, URL and persisted state, with the owner of each and how caches are invalidated.
• Outline a REST API for a multi-tenant application: resources, tenant isolation in every query, auth, pagination, rate limits and versioning.
• Work the tenant denormalisation backfill and the window-function version-gap problems.
• Write your prototyping answer: question the prototype answers, vertical slice, CI and rollback, what is throwaway.

Deliverable: A state diagram, a one-page API outline, two SQL solutions and a written prototyping approach.

Day 4 — Distributed performance and scaling under load

• List the performance levers you have used (caching, pooling, batching, queues, indexes, replicas, partitioning) with one before-and-after number each.
• Rehearse the sudden-load scenario as a numbered runbook: scope, mitigate, find the bottleneck, fix, postmortem.
• Work the stalled-log-partition debugging problem and write down the diagnosis order you used.

Deliverable: A levers table with real numbers, a scaling-incident runbook and a written debugging diagnosis.

Day 5 — Debugging and delivery scenarios

• Write the legacy runtime-exception story in STAR form, focusing on containment, reproduction, characterization test and fix.
• Split a vague feature (for example, an admin permissions report) into vertical-slice milestones with a spike first.
• Outline answers to the compressed-timeline and tech-debt-versus-features scenarios, each with the options you would put to a stakeholder.
• Say all four answers out loud and cut anything that doesn't describe a step or a decision.

Deliverable: Four structured scenario answers, one with a written milestone breakdown.

Day 6 — Behavioral stories

• Write STAR stories for disagreement, code-review feedback, end-to-end ownership and learning a technology quickly, each with a measurable result.
• Write your system for juggling concurrent tasks: prioritisation, quality guardrails, a time quality slipped.
• Rehearse each story out loud and prepare an answer to the most likely follow-up for each.

Deliverable: Five behavioral stories, each with its result and its likeliest follow-up answered.

Day 7 — Panel presentation rehearsal and loop check

• Build a solution-design presentation, on your own project or a workspace data-sync service: problem, constraints, options, architecture, trade-offs, rollout.
• Run it twice for a listener who interrupts, and revise the parts that confused them.
• Confirm with your recruiter the remaining format, language and location details, and reread your day 1 and day 5 notes.

Deliverable: A rehearsed presentation with an architecture diagram and rejected-options slide, plus a confirmed list of loop logistics.

Behavioural preparation

The behavioral questions candidates report for this role cover disagreement with a technical lead or product manager, taking code-review critique, owning a project end to end, learning a technology under deadline and keeping quality up across several tasks. Prepare one specific story per prompt with a decision you made and a measurable result.

1. How do you maintain code quality and personal productivity when managing multiple concurrent tasks?

Walk me through your experience with cloud platforms, SharePoint integration, and enterprise CRM systems.

Medium · Technical and Domain Knowledge

Approach

1. Organise the answer by platform rather than by employer: one concrete project each for cloud, SharePoint and CRM, and say plainly if one of them is thin in your background.
2. For cloud, name the provider and the services you ran in production (compute, storage, queues, identity) and one decision you made, such as managed database versus self-hosted, with the reason.
3. For SharePoint, describe the integration surface you used (SharePoint REST API, Microsoft Graph or a client SDK), the auth flow (app registration, delegated or app-only permissions), and how you handled paging, large lists, throttling (HTTP 429 with Retry-After) and permission mapping.
4. For CRM, explain the sync pattern: one-way or two-way, which system wins on conflict, the dedupe key, and how failed records were retried or quarantined instead of being silently dropped.
5. Finish with what the integration delivered (records synced, manual steps removed, errors reduced) and one thing you would build differently now.

Follow-up

• How did you handle API throttling or rate limits during a large backfill?
• How did you map permissions between two systems that model access differently?
• What happened when the same record was changed in both systems at once?

How do you handle debugging when a legacy codebase encounters unexpected runtime exceptions?

Medium · Technical and Domain Knowledge

Approach

1. Tell it as a real incident (situation, task, action, result) and spend most of the answer on the debugging sequence, not the background.
2. Contain first if users are affected: roll back, toggle a feature flag or route around the failing path, then investigate without time pressure.
3. Reproduce: read the full stack trace and logs, line up the first occurrence with recent deploys, config changes or new input data, and get a failing case running locally or in a test.
4. Isolate: in code with no tests, write a characterization test that pins current behaviour, then narrow down with git bisect, extra logging or a debugger. Separate the root cause (an unexpected null from a new data shape, a race, an environment difference) from the symptom.
5. Fix with the smallest safe change and a regression test, then prevent a repeat: input validation, an alert, a runbook entry. Show the result and what changed in the codebase.

Follow-up

• The exception only happens in production and you can't reproduce it. What next?
• How do you change legacy code that has no tests without breaking something else?
• How did you make sure the bug class couldn't come back?

Walk me through a time when you had to quickly learn a new technology or API to complete a task.

Medium · Problem-Solving and Scenarios

Approach

1. Pick a story with a real deadline and a technology that was actually new to you, such as an unfamiliar SDK, a cloud service or a collaboration-platform API, and say why you couldn't avoid it.
2. Show the method, not just 'I read the docs': official quickstart, a tiny spike that exercised the risky part (auth, paging, error handling), reading reference implementations or the library source, and asking someone who had used it.
3. Say how you checked your understanding before relying on it: tests against a sandbox, comparing behaviour with the documented limits, a reviewer who knew the technology.
4. Give the result (what shipped and when) and one mistake from learning fast, such as a missed rate limit or a wrong default, and how you caught it.
5. Avoid answers with no struggle and no method. The story should show a process you could repeat.

Follow-up

• How did you know you understood it well enough to ship?
• What would you do differently the next time you have to learn something fast?
• How did you pass what you learned on to the team?

Why are you interested in joining Avepoint, and what do you know about our core product ecosystem?

Medium · Behavioral and Mindset

Approach

1. Cover three points: what you understand the products do (candidates describe enterprise cloud and data management, including governance of digital workspaces), why that problem interests you, and how your experience fits it.
2. Tie it to something you have built: an integration with a collaboration platform, a data migration, a permissions or compliance feature, or multi-tenant backend work. The fit should be specific to you.
3. Read the company's public product pages before the call and name one product area you would like to work on and a question you have about it.
4. Avoid generic praise of culture or growth. If an answer would work for any software company, rewrite it.

Follow-up

• Which product area would you want to work on first, and why?
• What do you think is technically hard about managing and governing data across cloud workspaces?
• Why this company rather than a larger platform vendor?

Tell me about a time you disagreed with a technical lead or product manager and how you resolved it.

Medium · Behavioral and Mindset

Approach

1. Choose a disagreement about technical substance or priorities, for example design choice, scope or release readiness, where you had a real position and something was at stake.
2. Show how you understood the other side's constraints before arguing, then how you settled it with evidence: a prototype, a benchmark, incident data or a written comparison of options.
3. Be clear about the outcome, including if you were overruled. Committing fully to a decision you argued against is a strong ending if you explain how you did it.
4. Close with the working relationship afterwards and what you changed in how you raise disagreements.
5. The answer that sinks you: you were simply right, the other person was simply wrong, and you never say what you learned from their view.

Follow-up

• What would you have done if the decision had gone against you?
• Did you ever consider escalating? Why or why not?
• What did their perspective teach you?

How do you handle feedback and critique during code reviews?

Medium · Behavioral and Mindset

Approach

1. Give a specific review where feedback changed your code, and say what the comment was, why it was right and what you now do differently by default.
2. Explain how you take critique: assume good intent, ask clarifying questions when a comment is unclear, and separate the code from yourself.
3. Explain how you push back when you disagree: reply with a reason, a test or a benchmark, and move long threads to a quick call, then record the outcome in the PR.
4. Show you make code easy to review: small, focused PRs, a description with context and testing notes, and self-review before asking for others' time.
5. Avoid 'I always accept all feedback'. It sounds rehearsed and suggests you don't weigh the comments.

Follow-up

• Tell me about a review comment you disagreed with. How did it end?
• How do you respond to feedback that is harsh in tone?
• What do you look for when you review someone else's code?

Describe a project where you took complete ownership from conception to deployment.

Medium · Behavioral and Mindset

Approach

1. Choose a project you carried through every phase: problem definition, design, build, testing, deployment and running it after launch. Be precise about what you owned and what others did.
2. For each phase name one decision you made and why, for example a schema choice, a build-versus-buy call or a rollout strategy such as a feature flag or staged release.
3. Include something that went wrong after launch and how you handled it. Ownership that ends at merge is a weak story.
4. Quantify the result (users, latency, manual hours saved, incidents) and say what monitoring told you it was working.
5. Finish with what you would change, which shows you kept assessing the project after it shipped.

Follow-up

• How did you decide it was ready to ship?
• What broke after deployment, and how did you find out?
• What would you do differently if you started it again?