PURVIEW Software Engineer Interview Guide

The 60-second brief

As a Software Engineer at PURVIEW, you are at the intersection of technical innovation and practical application. You will be responsible for designing, building, and maintaining robust software solutions that drive our core business objectives. Whether you are working on front-end interfaces or back-end infrastructure, your code directly influences the scalability and reliability of the products we deliver to our users. This role is critical to PURVIEW because it demands a balance of high-level architectural thinking and meticulous implementation. You will work within cross-functional teams to solve complex engineering challenges, ensuring that our technical roadmap aligns with the evolving needs of our market. Expect a fast-paced environment where your ability to translate requirements into clean, maintainable, and efficient code will be your most valuable contribution.

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

Focus areas

• React JS
• Node JS
• Full-Stack Development

The PURVIEW interview process

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

Initial Screening

The first phase where candidates are screened for basic qualifications and fit for the role.

What to demonstrate

• The first phase where candidates are screened for basic qualifications and fit for the role
• Depth in React JS

How to prepare

• Be able to walk your CV end to end in two minutes, and say why this company specifically.
• Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Assessments

Candidates undergo assessments to verify their core competency in their chosen technology stack.

What to demonstrate

• Candidates undergo assessments to verify their core competency in their chosen technology stack
• Depth in React JS

How to prepare

• Answer aloud and timed: What are the advantages of using Python for backend services in a large-scale system?
• Answer aloud and timed: How do you ensure your code is optimized for performance and scalability?

Final Technical Evaluation

The concluding assessment that evaluates candidates' practical, hands-on problem-solving abilities.

What to demonstrate

• The concluding assessment that evaluates candidates' practical, hands-on problem-solving abilities
• Depth in React JS

How to prepare

• Answer aloud and timed: Describe a situation where you had to debug a complex issue in a production environment.
• Work React JS until you can explain it without notes

Where candidates lose points

Structure your answers

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

Ask questions

At the end of your interview, ask thoughtful questions about the team's current challenges to demonstrate your genuine interest.

Be honest about your limits

If you don't know the answer to a specific technical question, explain how you would go about finding the solution.

Prepare your environment

For remote coding sessions, ensure your workspace is quiet and your internet connection is stable.

Questions & practice

How would you approach building a responsive component using React JS?

Medium · Technical Proficiency and Problem Solvin

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Can you explain the difference between synchronous and asynchronous programming in Node JS?

Medium · Technical Proficiency and Problem Solvin

Approach

1. Say what the runtime actually does before reasoning about the code.
2. Name what is shared across threads and what owns each piece of state.
3. Identify the window where an invariant is briefly untrue.
4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

• What happens if two callers reach this at the same time?
• Where could this allocate more than you expect?

What are the advantages of using Python for backend services in a large-scale system?

Medium · Technical Proficiency and Problem Solvin

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

How do you ensure your code is optimized for performance and scalability?

Medium · Technical Proficiency and Problem Solvin

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. 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?

Relay committed events to the log without gaps or reordering

Medium · transactional outbox · at-least-once · ordering

outbox_event rows are written in the same transaction as the state change and carry aggregate_type, aggregate_id, aggregate_version, payload and status, with a partial index on (created_at, event_id) WHERE status = 'pending'. The relay publishes about 4k events/second to a partitioned append-only log keyed by aggregate_id, with one leader per partition range holding a lease. Consumers must never miss an event; they may see one twice. Design the claim-publish-mark loop, and state exactly what consumers observe when a leader's lease expires while it is mid-batch.

Approach

1. Claim with SELECT ... WHERE status='pending' ORDER BY created_at, event_id LIMIT $batch FOR UPDATE SKIP LOCKED inside a transaction. SKIP LOCKED lets several relay workers share a range without serialising on each other's rows, and the partial index keeps the claim proportional to the backlog rather than to a table that is overwhelmingly published rows. At 4k/second a batch of 500 is eight claims per second, each an index scan of 500 entries.
2. Publish before marking, never the reverse, and say why it is a choice. Marking first loses the event outright if the process dies in the gap, and the loss is silent - nothing remains to retry, and it surfaces later as a projection missing a row. Publishing first can repeat the event, and repetition is what every consumer is already built to survive. That single ordering is the whole at-least-once guarantee.
3. Preserve the only ordering on offer. Partition by aggregate_id and never publish two events for one aggregate concurrently: claim in (created_at, event_id) order and publish sequentially within an aggregate, or hash aggregate_id to a worker slot. Order across aggregates is not available at any price here, which is why the event carries aggregate_version and the full fact rather than a delta - a consumer can then discard what it has already applied without coordinating with anyone.
4. State the failover behaviour precisely, because it is the consistency-versus-availability decision in this design. A lease expires because the holder is slow, and no mechanism distinguishes that from dead, so for the length of the lease window two leaders can publish the same claimed batch. The system accepts duplicates to avoid stalling publication for every aggregate in the range whenever one worker pauses. Consumers deduplicate on (aggregate_id, aggregate_version) and drop anything at or below what they have applied.

Follow-up

• The relay is down 40 minutes and 9.6 million rows are pending. What does catch-up do to the primary, and what changes in the claim loop to survive it?
• A consumer insists it never received an event. Which single query settles whether the relay lost it, and what does each answer look like?

Describe a situation where you had to debug a complex issue in a production environment.

Medium · Technical Proficiency and Problem Solvin

Approach

1. Establish what changed and when, before forming any theory.
2. Pick a bisection that eliminates candidates whichever way it turns out.
3. Check the instrumentation before believing the symptom.
4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

• What would you look at first, and what would it rule out?
• How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics PURVIEW candidates report.

Day 1 — Map the PURVIEW loop

• Write out the reported sequence: Initial Screening, Technical Assessments, Final Technical Evaluation.
• 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 3 reported rounds, with the weakest marked.

Day 2 — Work React JS

• Spend the session on React JS, which PURVIEW candidates report being tested on.
• Write one worked example in React JS and time yourself on it.

Deliverable: One timed worked example in React JS.

Day 3 — Work Node JS

• Spend the session on Node JS, which PURVIEW candidates report being tested on.
• Write one worked example in Node JS and time yourself on it.

Deliverable: One timed worked example in Node JS.

Day 4 — Work Full-Stack Development

• Spend the session on Full-Stack Development, which PURVIEW candidates report being tested on.
• Write one worked example in Full-Stack Development and time yourself on it.

Deliverable: One timed worked example in Full-Stack Development.

Day 5 — Answer out loud: Technical Proficiency and Problem Solving

• Answer aloud, timed: How would you approach building a responsive component using React JS?
• Answer aloud, timed: Can you explain the difference between synchronous and asynchronous programming in Node JS?

Deliverable: Spoken answers to 2 reported Technical Proficiency and Problem Solving question(s), under time.

Day 6 — Rehearse your own examples

• Prepare three examples from your own work where you made the decision, each with the outcome you can quantify.

Deliverable: Three examples written out, each with a number attached.

Day 7 — Dry run for PURVIEW

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

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

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

Approach

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

Follow-up

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

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

• What in that decision was irreversible, and did you know it was irreversible when you made it?
• How did you tell the people who had already built on top of the original decision?