Role descriptions for Software Engineers at Palo Alto Networks tie the work to teams behind products such as Prisma Cloud, Wildfire, Cortex XSOAR and NGFW. The listed work ranges from network datapath engineering and distributed systems to high-throughput microservices and UI components. Backend code is written in languages such as Java, Python, C++ or Go.
The reported questions reflect that range. There are standard data structure problems (LRU cache, Min Stack, grouping anagrams, N-Rooks by backtracking). There are systems questions on processes and threads, BSS, stack and heap segments, page tables, the TCP 3-way handshake, TLS termination and the OSI model. And there are design questions: a distributed rate limiter, logging and alerting with clock synchronisation across nodes, and ingesting a large live data stream across many client nodes.
In practice, algorithm drills alone will not cover this process. Also prepare to explain OS and networking mechanics step by step, to make a working data structure thread-safe when a new constraint is added mid-problem, and to walk through a past project in terms of the decisions you made. Emphasis reportedly depends on the team: some lean on networking protocols (TCP/IP, DNS, TLS), others on cloud infrastructure (Docker, Kubernetes, IaC). Ask your recruiter which team the role is on and adjust your preparation.
Online Assessment
reportedCandidates report an automated online assessment, hosted on platforms such as Codility or HackerRank. It focuses on algorithmic problem-solving, string parsing, array manipulation and basic debugging. The reported questions are not tied to a specific round, but the shorter string and array problems in the bank (grouping anagrams, checking two strings are anagrams, reversing a string in place, iterative Fibonacci) are good practice for this format. In an automated setting nobody can ask what you meant, so the code has to be correct on inputs you never saw. When a result is wrong, find the smallest input that reproduces it and trace the state by hand before editing anything.
What to demonstrate
- Correct, complete solutions to algorithm problems built on string parsing and array manipulation
- Whether you can find and fix a defect in existing code, since the reported scope includes basic debugging
- Handling of empty, single-element and duplicate-heavy inputs, where string and array solutions most often break
- Whether you choose an approach with the right complexity first, instead of optimising a brute force after it works
How to prepare
- Practise grouping anagrams with a sorted-string or character-count key, valid anagram with a frequency array, and in-place string reversal with two pointers until you can write each without references
- Solve a handful of problems in a Codility- or HackerRank-style browser editor without your usual IDE, so unfamiliar tooling does not cost you anything on the day
- For every solution, write three edge-case inputs before running it and predict each output
- Do one fix-the-bug exercise a day: find a broken solution, name the failing input, expected value and actual value, then fix it
Technical Recruiter Call
reportedCandidates report a short conversation with a technical recruiter about their background and fit for the role. This is the cheapest place to learn which team the role sits on, and the team reportedly changes the technical emphasis: networking protocols for some teams, cloud infrastructure such as Docker and Kubernetes for others. Candidates report that role-specific positions such as kernel or datapath work may require C++ or C; confirm this on the call. Be accurate about which parts of the posting you have done and which you have not.
What to demonstrate
- Whether your background summary maps clearly onto the work in the posting
- Whether you describe your experience honestly, including what you have not done
- Whether your language and stack experience match what the team needs
How to prepare
- Write a short background summary that names your main language, the kind of systems you have built, and one project you can go deep on later
- Ask which team the role is on (for example Prisma Cloud, Wildfire, Cortex or NGFW) and whether the technical rounds lean towards networking or cloud infrastructure
- Ask whether the coding rounds allow any language or require C++ or C for this position
- Mark each line of the posting as done, adjacent or new, so scope questions get specific answers
Hiring Manager Screen
reportedCandidates describe the hiring manager screen as a discussion of previous architectural implementations, code quality and technical stack fit. Prepare to walk through a past project's architecture, your own contribution and its trade-offs; a reported behavioral question asks exactly this, so the same preparation serves both. The common failure is describing the system without the decisions, which sounds like you were present rather than responsible. Say which option you rejected, why, and what you would change now.
What to demonstrate
- Whether you can explain a past system's architecture clearly and say which parts you personally built
- Whether you can name the trade-offs behind your design decisions and the alternatives you turned down
- How you think about code quality: testing, review and maintainability in the code you shipped
- Whether your stack experience fits the team's work
How to prepare
- Draw the architecture of one project on a single page and practise explaining it aloud: components, data flow, and where it broke or was slow
- For two decisions in that project, write down the rejected option, the constraint that ruled it out, and the evidence that would have changed your mind
- Replace every 'we' in your project story with 'I' or a named role, and check the story still holds up
- Use the bank's 'Present a Past Architecture' and 'Introduce yourself and discuss resume details' questions as practice prompts
Technical and Behavioral Rounds
reportedCandidates report three to five rounds here, covering live coding, system design, code refactoring or debugging, and leadership or behavioral evaluation. Be ready for a constraint added partway through a coding problem, such as making a class thread-safe or handling input that no longer fits in memory. Reported questions span data structures (LRU cache, Min Stack, N-Rooks), systems fundamentals (process vs thread, memory segments, TCP and TLS, the OSI model, concurrency vs parallelism) and design (distributed rate limiting, logging and alerting with clock synchronisation, stream ingestion and caching). Candidate reports do not tie any of them to a specific round, so prepare every category.
What to demonstrate
- Working code with stated time and space complexity, plus how cleanly it adapts when a new constraint such as thread safety is added
- Understanding of OS, memory, concurrency and networking mechanics, explained step by step rather than by name
- System design trade-offs: SQL vs NoSQL storage, Redis caching, rate limiting, and behaviour under failure
- Behavioral answers about projects, disagreements, incidents and initiative with clear personal ownership
How to prepare
- Implement an LRU cache and a Min Stack, then add a lock to each and explain which operations need it and what contention it causes
- Practise explaining process vs thread, BSS/stack/heap and page tables, the TCP 3-way handshake, and TLS termination aloud with a diagram
- Design a distributed rate limiter end to end: the algorithm, where counters live, how updates stay atomic, and what happens when the cache is unavailable
- Prepare four behavioral stories (initiative under ambiguity, a technical disagreement, a production incident, AI tools in your workflow) with your own decisions named
9 candidate reports. Individual accounts describe a particular role and hiring cycle.
Palo Alto Networks Software Engineer interview: three-hour mixed evaluation
I began with an online HackerRank completed on my own. Next came behavioral questions on HireVue, without video recording. A recruiter call followed with the usual request to walk through myself and similar basics, meant to confirm fit and direction before the deeper stages. The next step was the largest one. The recruiter said it would take around three hours, and that was how it played out: rou…
Read full experiencePalo Alto Networks Software Engineer interview experience: missed interview follow-up
The technical content was not what defined this process for me. Recruiter contact started well, then communication stopped. My emails and phone outreach went unanswered, and even an interview that had been scheduled did not happen as expected. There was a no-show situation where I was left waiting without follow-up. That missed interview felt secondary to the larger problem: I never received any…
Read full experiencePalo Alto Networks Software Engineer interview: project decisions and AI
After applying, I had a recruiter phone screen about my experience and the technologies I had used. Soon afterward, the technical discussion focused on how I had built real projects: one project in depth, the design decisions I made, and the trade-offs behind them. That conversation also included how I had considered adopting AI in my current work. Coding-related exchanges were woven into the pro…
Read full experienceSoftware Engineer interview at Palo Alto Networks: interview experience
I started with an online assessment and then had three virtual technical rounds. The first was a system-design-and-coding-style prompt where I implemented a solution. It soon turned into debugging existing code to fix a bug, with the focus on making the code work under constraints rather than on theory. In the final round, I had to modify the code again in an object-oriented way, changing both it…
Read full experienceAccount Executive interview at Palo Alto Networks: cut-off Zoom call
What began as a normal Zoom interview stopped abruptly after about forty minutes. I tried to reconnect and followed up repeatedly, but heard nothing for roughly a week. When someone finally responded, it was simply to say they were no longer considering candidates. The early cutoff and lack of closure left me confused about whether the interview had ended properly on their side or whether I was s…
Read full experiencePracHub editorial advice for the preparation topics above.
Practising only named algorithm problems and losing time in the online assessment to string parsing, array edge cases or a debugging task
The reported assessment scope includes string parsing, array manipulation and basic debugging, not just algorithm selection. Practise problems where most of the work is handling input correctly: splitting, trimming, empty strings, repeated characters. Before submitting, write down the empty, single-element and duplicate-heavy cases and predict each output. For the debugging part, find the smallest failing input first and state what it should return. Editing code without a failing case you understand is how a small bug eats your time.
Writing a working LRU cache or Min Stack as one tangled function, so a follow-up asking to make it thread-safe forces a rewrite
Candidates report thread-safety follow-ups, such as converting a single-threaded implementation into a thread-safe one, so prepare for it from the first line. Keep shared state behind a small set of methods (get, put, push, pop, getMin) so you can guard those methods with a lock and point to exactly where it goes. Know the trade-off you are making: one coarse lock is simple and correct, but it serialises reads. A read-write lock helps only if reads do not change state, and an LRU get does change state because it moves the key to the front of the recency list. Say that before you choose.
Naming OS and networking concepts (OSI layers, TCP handshake, heap vs stack) without being able to explain how they work
The reported fundamentals questions ask for mechanism: what a thread shares with its process and what it does not, what lives in BSS vs the stack vs the heap, how page tables map virtual to physical addresses, the SYN, SYN-ACK, ACK sequence, and where TLS terminates. Practise tracing one concrete scenario from start to finish, such as what happens between typing a URL and getting a 'Connection Refused' error. Say which layer and which component acts at each step. If you can only list the seven OSI layers, expect the follow-up to expose it.
Answering the rate limiter or stream ingestion design with 'put it in Redis' and no failure or consistency reasoning
Some reported design questions name Redis, but naming it is not a design. For a distributed rate limiter, choose the algorithm (token bucket, sliding window) and say why. Explain how you keep each counter update atomic under concurrent requests, and decide whether to fail open or closed when the cache is unreachable. For logging and alerting across nodes, say how you order events when node clocks disagree. For stream ingestion, separate the write path from the read path and say where data can be stale. Each of these is a decision you can defend, which is more convincing than a component list.
Walking through a resume project as a system description without saying which decisions were yours
The reported behavioral questions ask for your individual contributions and trade-offs, and candidates describe the hiring manager screen as a discussion of past architectural work. For each project you plan to discuss, write down the part you built, one alternative you rejected and the constraint that ruled it out, and one thing that failed or needed rework. When asked 'who decided?', answer with a person or role, not 'we'. A story that stays plural under that question is heard as someone else's work.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Implement a custom Min Stack data structure supporting $O(1)$ minimum …
Implement a custom Min Stack data structure supporting $O(1)$ minimum value retrieval.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- What is the worst case, and how likely is it on real data?
- How does this change if the input no longer fits in memory?
Given a list of strings, group and print all valid anagrams.
Given a list of strings, group and print all valid anagrams.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- State the target complexity and say which constraint rules the naive version out.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Given a matrix of $N$ size, return all valid configurations for $N$-Ro…
Given a matrix of $N$ size, return all valid configurations for $N$-Rooks on the board using backtracking.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- Which test case would catch an off-by-one here?
- What is the worst case, and how likely is it on real data?
Implement a Least Recently Used (LRU Cache) with $O(1)$ lookup and eje…
Implement a Least Recently Used (LRU Cache) with $O(1)$ lookup and ejection mechanics.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- Name the brute-force solution and its complexity before improving on it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Seal an hour under late data with bounded memory
Metering ingest reads 256 partitions at 10,000 to 40,000 events/second. Events carry occurred_at and ingested_at, and during a producer replay the gap between them is hours. Seal each UTC hour once no more than 50 parts per million of that hour's eventual quantity can still arrive, using memory that does not grow with the size of the replay. Define the watermark, the lateness parameter and how you measure it, the structure holding open hours, and the write that performs the seal. State what an idle partition does to your watermark.
Approach
- Two clocks, two jobs. Bucket by
occurred_at, because that is the hour the customer is billed for, and advance the watermark oningested_at, because that is what the fold has consumed and whatsource_max_ingested_atrecords. Conflating them is what makes late data invisible. - The global watermark is the min over partitions of each partition's committed
ingested_at, not the max: the fold is trustworthy only as far as the slowest partition. The consequence is that one idle partition pins the watermark forever and nothing seals, so an idle partition must promote its watermark to wall clock after a stated idle timeout, and that timeout becomes a correctness parameter, because a partition that is slow rather than idle gets sealed past. - Choose the lateness L from the measured distribution of
ingested_at - occurred_at, weighted by quantity rather than by event count. The target is 50 ppm of the hour's quantity, and a replay is rare in events while carrying disproportionate mass, so an event-weighted quantile picks an L that is comfortably wrong at exactly the moment it matters. - Measure that quantile in bounded memory. A Greenwald-Khanna summary gives epsilon-approximate quantiles in O((1/epsilon) log(epsilon n)) space; a t-digest costs more per merge but has relative error that tightens at the tails, which is the half of the distribution you are reading at p99.99. Keep a separate summary per tenant class, because one tenant's batch importer is not the population.
- Hold open hours in a min-heap keyed by
hour_start. When the watermark advances, pop every hour withhour_end + L < Wand seal it: O(log H_open) per advance and O(1) amortised per event to touch its bucket. Memory is open hours multiplied by distinct(tenant, workspace, sku)keys, so cap the number of simultaneously open hours and spill the oldest intousage_rollup_hourlyasstatus='open'with arevisionbump. While an hour is open the row is upsertable, so the store is your overflow. - The seal itself is a conditional write:
update ... set status='sealed', sealed_at=now() where status='open' returning .... Two sealers race on every restart, and the loser must see zero rows and stop rather than write a second value. After the seal, an event for that hour is not an upsert but an adjustment, andsource_max_ingested_atis what proves it arrived afterwards.
Worked solution 40 min
- Replay a day of events with a synthetic lateness distribution: 99.9% under two minutes, plus a 0.05% tail at four to six hours that carries 3% of total quantity.
- Compute the p99.99 lateness two ways, event-weighted and quantity-weighted, and put the two numbers side by side.
- Implement the min-heap of open hours with the watermark as the min over 256 partitions, then stall one partition for 20 minutes and observe what seals.
- Set the idle-partition timeout to 60 seconds, repeat the stall, and measure how much quantity arrives after the seal.
- Attempt the seal from two workers at once and confirm the conditional update lets exactly one through.
Follow-up
- A replay starts during the sealing window for a period you are about to close. What do you do, and what is the customer-visible consequence of each option?
- Your measured quantity-weighted p99.99 lateness is six hours and the invoice must be issued at 02:00 UTC on the first. How do you reconcile those two numbers?
- How would you detect that L has drifted before it costs you an hour's quantity?
Paginate a tenant's delivery export without skipping rows
A customer exports webhook_delivery: delivery_id (bigint identity), subscription_id, tenant_id, event_id, status, attempt_count, next_attempt_at, created_at, delivered_at, updated_at. The endpoint runs select ... where tenant_id = $1 order by created_at desc limit 100 offset $2, and customers report rows missing from exports taken while new deliveries are being inserted. Write the replacement query and the index that supports it, paging a tenant's deliveries newest first at constant cost per page. State why updated_at cannot be the cursor column.
Approach
- Name the defect precisely. OFFSET is a position in a result set that is recomputed on every request, so a row inserted ahead of the window shifts everything back by one and the next page starts after a row the client never received. Nothing errors and no identifier gap appears, so the loss is silent.
- Replace the position with a value predicate over a stable, unique, indexed ordering:
where tenant_id = $1 and (created_at, delivery_id) < ($2, $3) order by created_at desc, delivery_id desc limit 100. The row comparison is load-bearing: created_at alone is not unique, so ties straddling a page boundary are dropped or repeated, which is the same bug in a smaller window. - Index
(tenant_id, created_at, delivery_id). PostgreSQL scans a btree in either direction, so an all-DESC ORDER BY is served by an ASC index read backwards and no DESC modifiers are needed; they only matter when the ORDER BY mixes directions. Confirm the plan has no Sort node above the index scan, or the LIMIT stops being an early exit. - Price both forms: keyset is one index descent plus 100 adjacent leaf entries per page, constant regardless of depth, while OFFSET still produces and discards every skipped row, so page N costs time proportional to N times the page size and a deep page on a large table goes from milliseconds to seconds.
- Rule out updated_at as the cursor from the precondition, not from taste: a cursor column must never change value for a row already paged past. updated_at moves on every delivery attempt, so a row the client already emitted re-enters a later page and is exported twice. created_at and delivery_id are immutable, which is the whole qualification.
Follow-up
- The client wants a snapshot as of one instant rather than a live tail. Compare a repeatable-read transaction held open, an added
created_at <= $snapshotbound, and a materialised export table. - A retention job deletes deliveries older than 90 days. What does a client mid-walk see, and does keyset pagination help at all?
- The customer wants to resume an export from yesterday's last cursor. What must be true of the cursor for that to be safe?
Decide which facts an invoice line copies instead of joining
invoice_line_item already denormalises tenant_id, which is reachable through invoice_id, and stores amount_minor even though quantity times unit_price_micros would recompute it. A reviewer asks you to normalise both away, and separately asks whether the tenant's legal name and billing address should be copied onto the invoice header. Decide each case. For every field you keep denormalised, name the read pattern or the invariant that justifies it, the anomaly the copy can develop, and the mechanism that prevents that anomaly here.
Approach
- Split the question into two kinds of copy, because they fail differently. A copy of a currently mutable fact is a cache: it drifts and needs invalidation. A copy of a fact frozen at write time is not a cache at all, it is the record of what happened, and normalising it away destroys information the source no longer holds.
- Keep tenant_id on the line. It costs 8 bytes, it leads every index on the table so no read is ever accidentally cross-tenant, and it turns a wrong join into an empty result rather than another tenant's money. Prevent the drift structurally: a unique constraint on invoice (invoice_id, tenant_id) plus a composite foreign key from the line on (invoice_id, tenant_id) makes a mismatched pair impossible, so the database enforces agreement instead of a code review.
- Keep amount_minor. Rounding must happen exactly once, at a named site, with a stated mode (half-even here). If readers recompute from quantity and unit_price_micros, every reader owns a rounding decision, and half-up and half-even diverge systematically across thousands of lines rather than cancelling out. A check constraint can bound the stored value but deliberately cannot re-derive it.
- Copy the legal name and billing address onto the invoice header, written once and never updated. The statement must show what was true when it was sealed, and the tenant record will change afterwards. This is a snapshot for the same reason
source_rollup_watermarkis stored per line: without it, nobody can reconstruct what the customer was told. - Name the read pattern that pays for all of it. Rendering, dispute response and export are per-tenant, per-period reads over thousands of lines that would otherwise join back to slowly changing dimensions that no longer hold the historical value. The write side is a once-per-period batch, so the extra columns cost nothing that matters.
- Concede the case where the reviewer is right: a mutable operational attribute such as the tenant's current plan name has no business on a line. If a report wants it, join. If a statement needs the plan as of the period, that is another snapshot and it belongs on the header with the rest.
Worked solution 25 min
- Write the DDL: unique (invoice_id, tenant_id) on invoice, the composite FK from the line, and a comment on each denormalised column saying whether it is a snapshot or a cache.
- Attempt to insert a line whose tenant_id differs from its invoice's and confirm the foreign key rejects it.
- Rename a tenant, re-render a sealed invoice, and confirm the rendered name is the one stored on the header.
- Recompute amount_minor from quantity times unit_price_micros for a thousand synthetic lines rounding half-up, sum both ways, and record the divergence from the stored half-even values.
Follow-up
- Write the composite foreign key and the unique constraint it requires on the parent. What does it cost on every line insert, and what does it do to a bulk load?
- A tenant is renamed after being invoiced. Which rows change, and what does the customer see on last quarter's PDF?
- Where does currency live, and what breaks if a tenant's billing currency changes between two periods?
Outline the architecture for ingesting, caching, and processing a 15 G…
Outline the architecture for ingesting, caching, and processing a 15 GB live data stream that updates every 15 minutes across 100 client nodes.
Approach
- Name the read and write paths separately; they rarely have the same bottleneck.
- State the consistency you need, and where you are willing to be stale.
- Name the failure you are designing for, then the recovery path.
Follow-up
- What would you drop to keep the system up under load?
- How does this behave when that dependency is down for an hour?
How would you design a high-throughput logging and alerting mechanism …
How would you design a high-throughput logging and alerting mechanism with clock synchronization across distributed nodes?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the failure you are designing for, then the recovery path.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What would you drop to keep the system up under load?
- How does this behave when that dependency is down for an hour?
Explain the key differences between concurrency and parallelism, and w…
Explain the key differences between concurrency and parallelism, and write pseudo-code to synchronize access across multi-threaded datastores.
Approach
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Clarify what is being asked and what a complete answer contains.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Metering ingest that survives a six-hour producer replay
metering-ingest consumes usage events at-least-once - 250M/day, 10-40k/second at peak - and folds them into usage_rollup_hourly keyed (tenant_id, workspace_id, sku, hour_start). usage_event is partitioned daily on ingested_at with unique (ingested_day, tenant_id, idempotency_key). A producer outage ends in a six-hour replay that re-sends events already ingested, some of whose originals crossed midnight. Design the consumer: partitioning, where the acknowledgement sits relative to the commit, the deduplication horizon and its storage cost, and how the rollup watermark advances. Nothing may be double-counted and nothing may be silently dropped.
Approach
- Choose the acknowledgement position deliberately and name what each choice costs. Acknowledging after the fold commits makes the consumer at-least-once: a crash between the two replays the batch and produces duplicates, which are ordinary and absorbable. Acknowledging first makes it at-most-once: a crash between the two drops revenue with no error raised anywhere and no way to detect it later. Take at-least-once and design everything downstream to absorb duplicates.
- Put the dedup and the fold in one transaction so there is no window between them. Insert the batch into usage_event with ON CONFLICT DO NOTHING, take the rows actually inserted, and fold only those into usage_rollup_hourly with an upsert on (tenant_id, workspace_id, sku, hour_start) bucketed by occurred_at, not ingested_at. A batch of about 2,000 rows is one round trip and one index probe per event.
- Attack the partition-key flaw head on: the unique index includes ingested_day because a unique index on a partitioned table must contain the partition key, so the same (tenant_id, idempotency_key) re-sent after midnight is a different index entry and passes. Deduplicate instead against a store keyed (tenant_id, idempotency_key) with no date component, whose horizon exceeds the producer's maximum retry window plus the longest replay you intend to support. At 14 days that is 250M x 14 = 3.5 billion keys, which is a dedicated key-value store, not a larger index on the same table. The alternative - partitioning usage_event on (tenant_id, occurred_day) so the natural key is stable - fixes dedup but loses pruning on ingest time and makes retention by dropping partitions awkward.
- Partition the consumer by hash of tenant_id so one tenant's replay stalls only its own partitions, and give replay traffic a separate lower-priority lane so live ingest keeps its latency. The cost is explicit: that tenant's watermark lags while the replay drains, and everything gated on the watermark waits for it.
- Define the watermark as a property of committed work, not of wall-clock time: per partition it is the largest occurred_at such that every event with a smaller occurred_at has committed, and the sealing decision uses the minimum across partitions. Record source_max_ingested_at on every rollup row so any number can prove what it did and did not include, and keep restatement legal only while status = 'open' - after sealed_at the value is frozen and a late event becomes an invoice adjustment instead.
Worked solution 40 min
- Write the consumer loop in pseudocode with the acknowledgement after the commit, then annotate each line with what is lost or duplicated if the process dies exactly there.
- Size the dedup store: events/day x horizon_days keys, bytes per key including the tenant prefix, and the resulting memory or disk. Compare that cost against simply extending retention on the partitioned table and say why the latter does not fix the problem.
- Take one event ingested at 23:59:58 and replayed at 00:00:04 and work out its fate under (a) the partitioned unique index alone and (b) the separate dedup store.
- Write the per-partition watermark formula, then what the seal uses, then what a single stalled partition does to sealing.
Follow-up
- The dedup store is lost entirely. What can you still guarantee, and how do you rebuild it from what remains?
- A replay delivers events for an hour that is already sealed. Trace exactly what happens to them, row by row.
- One partition is stuck on a poison message, so the minimum-across-partitions watermark never advances and no tenant can be sealed. What is your escape hatch and what does it cost in correctness?
Regional error rate explodes after a dependency merely slows
A control-plane read replica in one region degrades from 4 ms to 120 ms. Within ninety seconds that region's gateway error rate rises from 0.01% to 40% and its p99 becomes bimodal, one mode near the old p99 and one at the client timeout. The other two regions are unaffected. The gateway retries control-plane reads three times with exponential backoff and no jitter. Give an ordered checklist that separates trigger from amplifier, the offered-load arithmetic, and the controls that break the loop.
Approach
- Split the incident into three questions before touching a control: what started it, what amplified it, and what would make recovery slow. Here they are the replica slowdown, the retry policy interacting with queueing, and a synchronised unjittered herd at recovery. They are different mechanisms and each needs its own control.
- Read the distribution rather than the mean. A bimodal p99 with one mode pinned at the client timeout is two populations, not one degraded path; split latency by cache hit and miss and confirm the fast mode is hits and the timeout mode is misses that reached the replica.
- Do the load arithmetic. Three retries turn one client request into up to four upstream requests, so offered load reaches roughly 4x on a dependency that is already slower, and it arrives at the worst moment. With utilisation approaching one, queueing delay grows superlinearly, which is why a 30x latency increase upstream does not produce a 30x increase downstream, it produces timeouts.
- Break the loop with controls that bound offered load rather than with more attempts: a concurrency limit on the control-plane client so at most N calls are in flight and the remainder fail fast, a circuit breaker scoped per dependency and region, and a retry budget capping retries at a small fraction of base traffic so amplification has a ceiling that does not depend on how many clients are retrying.
- Add full jitter to whatever retries survive, sleeping uniformly in [0, min(cap, base x 2^attempt)], so attempts de-correlate instead of arriving in waves aligned to the moment of failure.
- Decide the unreachable-dependency behaviour in advance, because it is the actual product decision underneath: serving from an expired credential cache keeps the product available while extending a revoked key's life past the stated bound, and failing closed converts a dependency degradation into a total outage. State the mode and the staleness number rather than letting the timeout choose.
Follow-up
- The replica recovers. Describe what happens in the first ten seconds with your controls in place versus without them.
- Which single metric would have paged before the error rate moved, and why is upstream latency by itself not it?
- Requests that fail fast under the concurrency limit still need an answer. What does the gateway return, and what does it do to the usage event it would otherwise have emitted?
For someone fluent in a dynamic language who has shipped real work but has never had to say what the runtime is doing underneath. The week is built on measuring and deliberately breaking things, because the questions that expose this background are the ones where the interviewer asks why a second time.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Online assessment: strings, arrays and a debugging drill
- In a browser-based editor with a timer, solve: group anagrams (sorted-string or character-count key), valid anagram with a frequency array, in-place string reversal with two pointers, and the first n Fibonacci numbers in constant space
- For each problem, write the empty, single-element and duplicate-heavy inputs before running, and predict the output
- Take one of your solutions, plant a bug, then find it by naming the failing input, expected value and actual value before editing
- Write the time and space complexity next to each solution and state the brute force you avoided
Deliverable: Four timed solutions with written edge cases and complexities, plus one debugging log with the failing input named.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Data structures from scratch, then thread-safe
- Implement an LRU cache with a hash map and a doubly linked list, O(1) get and put, and test eviction at exactly capacity and at capacity plus one
- Implement a Min Stack with O(1) getMin using a second stack or stored minimums, and test with repeated minimum values
- Add a lock to both structures. Explain why an LRU get is a write to the recency order, and what one coarse lock costs under many readers
- Solve a linked-list palindrome check (midpoint plus in-place reversal) and mirror a binary tree, stating the complexity of each
Deliverable: LRU cache and Min Stack implementations, each with boundary tests and a thread-safe version with a written note on where the lock goes and why.
Practice prompt ↗Practice prompt ↗03Backtracking and harder coding problems
- Solve N-Rooks by backtracking: place one rook per row, track used columns in a set, and state the output size (N!) and why pruning cannot beat it
- Solve maximum rectangle in a histogram with a monotonic stack, and explain why each bar is pushed and popped at most once
- Take one solved problem and add a constraint mid-way (input streams in and no longer fits in memory) and adapt the solution out loud
- Practise explaining one solution in pseudocode before writing code, the way a reported question on explaining logic asks
Deliverable: Three solved problems with complexity arguments and one written adaptation to a mid-problem constraint change.
Practice prompt ↗Practice prompt ↗04Systems fundamentals and concurrency
- Write a one-page explanation of process vs thread: what is shared (address space, file descriptors) and what is per-thread (stack, registers)
- Explain BSS, stack and heap with an example variable for each, and how page tables map virtual to physical addresses
- Explain concurrency vs parallelism, then write pseudocode that synchronises reads and writes to a shared in-memory store without a lost update
- Review ownership and reference counting with C++ shared_ptr, and explain polymorphism with an example of why you would use it
Deliverable: A set of spoken-aloud explanations you can give without notes, plus synchronised-store pseudocode with the race it prevents written underneath.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Networking: OSI, TCP, TLS and DNS
- Draw the OSI model with one protocol and one device per layer, and place RIP, OSPF, ICMP and IGMP correctly
- Trace the TCP 3-way handshake and explain where TLS termination happens and what the terminating component can see
- Trace a URL typed into a browser through DNS resolution to a 'Connection Refused' error, naming the layer and component at each step
- Compare REST and GraphQL for one API you have built, and state one trade-off each way
Deliverable: An annotated packet-journey diagram and a written trace of the 'Connection Refused' scenario.
Practice prompt ↗Practice prompt ↗06System design: rate limiting, logging and stream ingestion
- Design a distributed, thread-safe, high-QPS rate limiter: choose the algorithm, where counters live, how updates stay atomic, and the fail-open or fail-closed decision
- Design a high-throughput logging and alerting system and explain how you order events when node clocks disagree
- Outline ingesting, caching and processing a large live data stream that refreshes on a schedule across many client nodes, separating the read and write paths
- Work the 'Metering ingest that survives a six-hour producer replay' exercise for practice with deduplication, acknowledgement position and watermarks
- Work the retry-storm debugging drill and explain how retries amplify load on a slowed dependency
Deliverable: Three one-page designs, each naming its main trade-off and its behaviour when a dependency fails, plus the completed ingest exercise.
Practice prompt ↗Practice prompt ↗07Hiring manager screen, recruiter call and behavioral stories
- Draw one past project's architecture and rehearse the walkthrough: components, your individual contribution, two decisions with rejected alternatives
- Prepare stories for: initiative under ambiguous requirements, a technical disagreement, a mistake or production incident and what you did next, and AI tools in your coding workflow
- Replace every 'we' in each story with 'I' or a named role, and check the story still holds up
- Write the questions for your recruiter: which team, whether the rounds lean towards networking or cloud infrastructure, and which languages are allowed
Deliverable: A one-page architecture walkthrough, four behavioral stories with personal ownership stated, and a list of recruiter questions.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Reported behavioral questions focus on project deep dives: the architecture of something on your resume, the part you personally built, and the trade-offs you weighed. Others cover initiative under ambiguous requirements, a technical disagreement, how you handle a mistake or a production incident, and how you use AI development tools. Prepare each answer as a specific incident with your own decisions named, and expect follow-ups asking who decided, what you measured and what you would change.
Describe how you have integrated AI development tools into your daily …
Describe how you have integrated AI development tools into your daily coding workflow to improve development velocity and code quality.
Approach
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- What did you decide not to do, and why?
Tell me about a time you took the initiative to drive a technical solu…
Tell me about a time you took the initiative to drive a technical solution forward despite ambiguous requirements.
Approach
- Give the blast radius: what could have broken, and what you measured.
- Pick a story where you made the decision, not one where you watched it.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that again?
Reverse a webhook ordering decision after measuring its cost
You argued for strict per-subscription ordering in webhook-delivery, which means one in-flight attempt per subscription. It shipped. Three months later a single unresponsive endpoint holds one subscription's queue at a six-hour backlog, and two customers report events arriving out of order anyway once their own retries are counted. Describe a decision you reversed: what you originally optimised for, the measurement that changed your mind, what the reversal cost in engineering time and customer change, and how you told the people who had already built on the original guarantee.
Approach
- State the original decision as a trade you made knowingly. Ordering across a network requires a single in-flight attempt per subscription, and its price is head-of-line blocking whenever one endpoint is slow. 'We priced it wrong' is a much stronger opening than 'we did not realise', and it is usually the true one.
- Bring the measurement that flipped it, not the anecdote: backlog age at the ninety-ninth percentile per subscription, the share of subscriptions where one slow endpoint gated an otherwise healthy queue, and the delivery throughput lost to serialisation. A reversal justified by complaints is indistinguishable from a reversal justified by fatigue.
- Name what you learned about the guarantee itself, which is the engineering content of this story. At-least-once delivery means a retried event already arrives after newer ones and the consumer already must be idempotent, so a guarantee the customer has to defend against anyway was never worth what it cost to provide.
- Describe the migration, because reversing a published contract is the hard half and the part candidates skip. Parallel attempts behind a per-subscription flag, a monotonically increasing sequence number added to the envelope so order-sensitive consumers can sort or discard, documentation that states at-least-once and unordered in those words, and a deprecation measured in quarters because the client is a pinned SDK inside a build pipeline you cannot see or redeploy.
- Give the cost in the two currencies that matter: engineer-weeks, and how many customers had to change code. Then say who you told before it shipped rather than in a changelog afterwards, and which large customer you left on the old behaviour and for how long.
- Close with the signal you now weight differently, stated as something you would do earlier next time: measuring the blocking cost on the slowest decile of endpoints before committing to the guarantee, rather than after a customer noticed.
Follow-up
- A customer insists they need ordering. What do you offer them that is not global serialisation?
- How did you choose the deprecation window given that you cannot see or redeploy the clients?
- What would have to be true for you to reverse back?
- 01
Walk through a complex project on your resume: explain the overall architecture, your individual contributions, key design decisions, and the technical trade-offs considered.
- 02
Tell me about a time you took the initiative to drive a technical solution forward despite ambiguous requirements.
- 03
Describe a situation where you faced a significant conflict or technical disagreement within your team. How did you resolve it?
- 04
How do you handle technical mistakes or system outages, and what concrete steps do you take immediately following a production incident?
- 05
Describe how you have integrated AI development tools into your daily coding workflow to improve development velocity and code quality.
- 06
Introduce yourself and discuss the details of your resume.
Is this an official Palo Alto Networks interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Palo Alto Networks. Rounds and questions reflect what candidates have reported, not a process Palo Alto Networks has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult are the technical interviews at Palo Alto Networks?
Candidate reports describe them as moderate to challenging. The emphasis is on computer science fundamentals, practical coding, and networking protocols. Expect systems questions, multi-threading follow-ups and changes to your code during the interview, rather than purely theoretical puzzles.
PracHub interview research ↗What programming languages can I use in the coding rounds?
According to candidate reports, you can generally use your strongest language, such as Python, Java, C++ or Go, for algorithm and data structure rounds. Role-specific positions such as kernel or network datapath work may require C++ or C, so confirm with your recruiter for the specific position.
PracHub interview research ↗How much networking knowledge does a Software Engineer candidate need?
Candidate reports stress networking even for general backend roles. Reported questions cover the OSI model and the protocols at each layer, the TCP 3-way handshake, and TLS termination, and DNS resolution also comes up. Prepare to trace a request through these layers step by step, not just list them.
PracHub interview research ↗What are the stages of the interview process?
Candidates report four stages over roughly three to five weeks: an online assessment, a technical recruiter call, a hiring manager screen, and then three to five technical and behavioral rounds. Those later rounds include live coding, system design, code refactoring or debugging, and leadership evaluation.
PracHub interview research ↗What is in the online assessment?
Candidates report an automated assessment on platforms such as Codility or HackerRank, focused on algorithmic problem-solving, string parsing, array manipulation and basic debugging. Practise in a browser editor without your usual IDE, and write out edge cases before you submit.
PracHub Software Engineer practice ↗How do the drill questions and worked exercises relate to the reported questions?
The reported questions (LRU cache, Min Stack, N-Rooks, rate limiting, logging with clock synchronisation, OSI and TCP fundamentals) come from candidate reports. The drill questions and worked exercises are original practice set in other domains, such as deduplicated ingestion, pagination and retry storms. They train the same skills: correctness under concurrency, failure handling and defending trade-offs. They are not predictions of what you will be asked.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
Zscaler Software Engineer Interview Guide
Concurrency exercises for Zscaler candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
Verkada Software Engineer Interview Guide
Prepare for the software engineer interview at Verkada with original coding, system design and debugging exercises, each paired with a worked solution and the reasoning behind it.
Vanta Software Engineer Interview Guide
Caching exercises for Vanta software engineer candidates: deciding what staleness a feature tolerates, choosing between expiry and explicit invalidation, and handling the stampede when a hot key expires.
Omnissa Software Engineer Interview Guide
Concurrency exercises for Omnissa candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.