Interview guides · Protiviti

Protiviti Software Engineer Interview Guide

Protiviti Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Protiviti, you operate at the intersection of high-level business strategy and technical execution. You are not merely a coder; you are a solution architect tasked with solving complex problems for a diverse range of global clients. Whether you are developing AI-driven solutions, architecting cloud-native environments, or managing Microsoft Dynamics 365 integrations, your work directly impacts the digital transformation journeys of major enterprises. This role requires a unique blend of technical proficiency and professional maturity. You will be expected to translate vague business requirements into robust, scalable software, often working within cross-functional teams that include consultants, data scientists, and business analysts.

This guide is scoped to a Software Engineer candidate at Protiviti.

Focus areas

SQL
Coding Interview Preparation
PL/SQL

The Protiviti interview process

Protiviti candidates report 4 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Online Assessment

Initial screening to verify core programming skills through an online assessment.

What to demonstrate

Initial screening to verify core programming skills through an online assessment
Depth in SQL

How to prepare

Answer aloud and timed: Explain a project where you designed a cloud architecture from scratch.
Answer aloud and timed: How do you ensure high availability and fault tolerance in an Azure or Cloud environment?

Technical Interviews

A series of technical interviews, which may include group discussions or whiteboard sessions.

What to demonstrate

A series of technical interviews, which may include group discussions or whiteboard sessions
Depth in SQL

How to prepare

Answer aloud and timed: What are the common challenges you have encountered in cloud migrations, and how did you resolve them?
Answer aloud and timed: Describe your experience with SQL and PL/SQL—specifically regarding cursors, exceptions, and complex joins.

Managerial Round

Interview with a managerial or directorial level professional to assess fit and skills.

What to demonstrate

Interview with a managerial or directorial level professional to assess fit and skills
Depth in SQL

How to prepare

Answer aloud and timed: How do you optimize query performance in a large-scale database?
Answer aloud and timed: Tell me about your background and your motivation for joining Protiviti.

HR Discussion

Final discussion focused on behavioral fit and logistical alignment.

What to demonstrate

Final discussion focused on behavioral fit and logistical alignment
Depth in SQL

How to prepare

Answer aloud and timed: Describe a time you had to explain a complex technical concept to a non-technical stakeholder.
Answer aloud and timed: How do you handle disagreements within a project team regarding technical implementation?

Where candidates lose points

Structure your answers

Use the STAR method (Situation, Task, Action, Result) for behavioral questions to keep your responses concise and impactful.

Be honest about limitations

If you don't know an answer, explain how you would go about finding it rather than guessing. This shows a "consultant mindset."

Focus on the "Why

When discussing projects, explain why you chose a specific technology over an alternative. This demonstrates critical thinking.

Prepare for group discussions

If your process includes a group discussion, focus on being a collaborative contributor rather than trying to dominate the conversation.

Questions & practice

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

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

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.
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.
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.
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?

Describe your experience with SQL and PL/SQL—specifically regarding cursors, exceptions, and complex joins.

Medium · Technical & Domain Expertise

Approach

Name the grain you start from and join outward from it.
Check whether any join is one-to-many before aggregating, or the sums inflate.
Say which index the query would use, and what makes it unusable.
Handle the rows that do not match: that is usually the actual question.

Follow-up

How does the query change if that join becomes one-to-many?
What happens to this when the table is ten times larger?

How do you optimize query performance in a large-scale database?

Medium · Technical & Domain Expertise

Approach

Name the grain you start from and join outward from it.
Check whether any join is one-to-many before aggregating, or the sums inflate.
Say which index the query would use, and what makes it unusable.
Handle the rows that do not match: that is usually the actual question.

Follow-up

How does the query change if that join becomes one-to-many?
What happens to this when the table is ten times larger?

Explain a project where you designed a cloud architecture from scratch.

Medium · Technical & Domain Expertise

Approach

Fix the scope first: who calls this, how often, and what they do when it fails.
Name the read and write paths separately; they rarely have the same bottleneck.
Choose a partition key and say what query it makes expensive.
State the consistency you need, and where you are willing to be stale.

Follow-up

What breaks first when traffic grows ten times?
How does this behave when that dependency is down for an hour?

How do you ensure high availability and fault tolerance in an Azure or Cloud environment?

Medium · Technical & Domain Expertise

Approach

Fix the scope first: who calls this, how often, and what they do when it fails.
Name the read and write paths separately; they rarely have the same bottleneck.
Choose a partition key and say what query it makes expensive.
State the consistency you need, and where you are willing to be stale.

Follow-up

What breaks first when traffic grows ten times?
How does this behave when that dependency is down for an hour?

What are the common challenges you have encountered in cloud migrations, and how did you resolve them?

Medium · Technical & Domain Expertise

Approach

Clarify what is being asked and what a complete answer contains.
State your assumptions explicitly before working the problem.
Say what you would check first and why it is the highest-information step.
Work from the requirement backwards to the design.

Follow-up

What assumption would you test first?
How would you know your answer was wrong?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

Built from the rounds and topics Protiviti candidates report.

Day 1 — Map the Protiviti loop

Write out the reported sequence: Online Assessment, Technical Interviews, Managerial Round, HR Discussion.
For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 4 reported rounds, with the weakest marked.

Day 2 — Work SQL

Spend the session on SQL, which Protiviti candidates report being tested on.
Write one worked example in SQL and time yourself on it.

Deliverable: One timed worked example in SQL.

Day 3 — Work Coding Interview Preparation

Spend the session on Coding Interview Preparation, which Protiviti candidates report being tested on.
Write one worked example in Coding Interview Preparation and time yourself on it.

Deliverable: One timed worked example in Coding Interview Preparation.

Day 4 — Work PL/SQL

Spend the session on PL/SQL, which Protiviti candidates report being tested on.
Write one worked example in PL/SQL and time yourself on it.

Deliverable: One timed worked example in PL/SQL.

Day 5 — Answer out loud: Technical & Domain Expertise

Answer aloud, timed: Explain a project where you designed a cloud architecture from scratch.
Answer aloud, timed: How do you ensure high availability and fault tolerance in an Azure or Cloud environment?

Deliverable: Spoken answers to 2 reported Technical & Domain Expertise question(s), under time.

Day 6 — Answer out loud: Behavioral & Situational

Answer aloud, timed: Tell me about your background and your motivation for joining Protiviti.
Answer aloud, timed: Describe a time you had to explain a complex technical concept to a non-technical stakeholder.

Deliverable: Spoken answers to 2 reported Behavioral & Situational question(s), under time.

Day 7 — Dry run for Protiviti

Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.