Arrcus · Software Engineer
Updated · 2026-10-02

Arrcus Software Engineer
Interview Guide

THE 60-SECOND BRIEF

Candidates describe Arrcus as a company working on network infrastructure software, with routing, switching and cloud-native networking named as the areas. A Software Engineer there is described as designing, building and testing features for routing and switching code, taking a module from first design through deployment, reviewing teammates' changes, debugging low-level system problems and joining architecture discussions. The listed must-haves are C or C++, data structures and algorithms, networking protocols and system-level debugging.

This guide is for candidates interviewing for a Software Engineer position at Arrcus. It covers the two reported rounds, the twelve questions candidates report (classic coding problems, networking and systems fundamentals, and verbal problem solving), and a seven-day plan. Because the reported requirements centre on C or C++ and networking protocols, the preparation here assumes you will write and explain low-level code. Cloud-native networking, high-throughput or low-latency experience and scripting for automation are listed as nice-to-haves, so they get less room than the fundamentals.

Candidates report two stages over roughly 2-4 weeks: a Technical Assessment that sets a baseline for coding skill, then back-to-back Technical Interviews covering breadth and specific expertise.

Data StructuresAlgorithmsProblem Solving

34 min read

Browse Software Engineer questions

See the practice prompts

17Practice promptsAcross five skill areas

The work candidates describe is network software: code that sits close to the operating system and the network interface, where memory use, pointer handling and per-packet cost matter. That shapes the interview preparation. Expect the conversation to move from a short algorithm to what the machine is doing underneath it, so a solution that is correct but unaware of allocation, cache behaviour or buffer limits will feel incomplete.

The twelve reported questions fall into three groups. The coding group is short and classic: why Quicksort suits arrays while Merge Sort suits linked lists, printing the left view of a binary tree, reversing each word in a string, summing the elements of a matrix and computing the distance between two points. The fundamentals group covers what happens after a URL is typed into a browser, how network layers interact, memory management strategies in C and optimizing for high-throughput network environments. The problem-solving group covers debugging a memory leak in a production system, an algorithm for concurrent data requests and data structure trade-offs in a real-time system.

Several of the coding questions are small, which makes the details the whole question: empty input, repeated spaces, integer overflow in a sum, a null pointer, an off-by-one in a loop bound. Practise them in C or C++ and say your assumptions before you type. Candidates also report that solutions may be worked on a whiteboard or explained aloud, so rehearse without an editor, compiler or autocomplete.

The fundamentals and problem-solving questions are open-ended and are answered by talking. Build each answer as a short chain of concrete steps (which layer, which system call, which data structure, which measurement) rather than a list of buzzwords. Candidates report that networking theory is a core part of the technical rounds, so give it real study time alongside the algorithms.

The Arrcus interview process

01

Technical Assessment

reported

Candidates describe the Technical Assessment as the opening stage, used to set a baseline for your coding skill. A coding stage tests working code, so treat it as a place to produce correct, compilable solutions and explain their cost. The coding questions in this guide (sorting trade-offs, the binary tree left view, reversing words, matrix sum, point distance) are the practice material for this kind of stage. Pick C or C++, the languages the role lists first, and stay in one language so you are not searching for syntax.

What to demonstrate

  • Working code in a systems language, including the edge cases of the input
  • Choosing a data structure to fit the access pattern and stating its time and space cost
  • Explaining why one approach beats another, for example array versus linked list for sorting

How to prepare

  • Write the left view of a binary tree twice in C or C++, once with a level-order queue and once with a depth-first walk that records the first node seen at each depth, and compare their space use.
  • Implement reverse-each-word on a mutable char buffer in place, handling leading, trailing and repeated spaces and an empty string, and state that it runs in O(n) time with O(1) extra space.
  • Write a one-minute spoken answer for why Quicksort is preferred for arrays and Merge Sort for linked lists, naming random access, cache locality, stability and worst case.
Arrcus Software Engineer candidate reports ↗
02

Technical Interviews

reported

Candidates describe the Technical Interviews as back-to-back sessions testing breadth of knowledge and specific expertise, with networking and systems fundamentals reported as a core component and some problems solved verbally while you explain your reasoning. Prepare to move between topics without warming up: a packet's path through the stack, how C manages memory, where a service loses throughput, how you would chase a leak. Answer each by naming the concrete mechanism, then the trade-off, then how you would measure it.

What to demonstrate

  • Networking theory: protocol stacks, the OSI model and how packets move through a network
  • System internals: how OS-level processes interact with network interfaces, and how memory is managed in C
  • Systems-level debugging and concurrency reasoning
  • Clear verbal problem solving, with stated assumptions and trade-offs

How to prepare

  • Prepare a layer-by-layer walkthrough of what happens after a URL is typed into a browser: DNS lookup, TCP handshake, TLS, HTTP request and response, with the frame, packet and segment headers added at each layer.
  • Write out a debugging sequence for a growing-memory production process: confirm the growth from resident memory over time, separate a true leak from a cache or fragmentation, then use a heap profiler or sanitizer on a reproduction.
  • Sketch a concurrent request handler (bounded queue, worker threads, sharded locks) and list where it contends, what it does when the queue is full, and how you would check it with a load test.
  • List six data structures with their worst-case operation cost and allocation behaviour, to answer real-time trade-off questions with numbers.
Arrcus Software Engineer candidate reports ↗

Where candidates lose points

PracHub editorial advice for the preparation topics above.

01

Answering the Quicksort versus Merge Sort question with "Quicksort is faster" and nothing else

Give the properties that decide it. Quicksort partitions in place and walks contiguous memory, which suits arrays; its worst case is O(n^2) without a good pivot choice. Merge Sort needs no random access, merges linked nodes by relinking pointers with O(1) extra space, is stable and keeps O(n log n) in the worst case. End with when you would flip the choice.

02

Writing the small string and matrix problems as if the input were always well-formed

Say your assumptions first, then handle the empty string, runs of spaces, a null pointer, a zero-row matrix, and a sum that can overflow int (use a wider accumulator). In C, also state who owns the buffer and whether the function may modify it.

03

Naming the networking layers as a list without showing how data moves through them

Follow one request from the browser to the server and back: name resolution, connection setup, what each layer adds to the packet, how the next hop is chosen, and where the receiving operating system hands the data to a process. A traced example shows you understand the interaction between layers.

04

Answering the production memory-leak question with "run Valgrind"

Open with how you confirm and bound the problem: resident memory over time, which process, whether it tracks load. Separate leaks from caches and fragmentation, use a low-overhead heap profiler or allocation snapshots on a live process, move to a sanitizer on a reproduction, and say how you would verify the fix.

05

Saying "add a mutex" for the concurrent data requests question

Identify the shared state first and whether reads dominate. Then pick the mechanism: a reader-writer lock, sharded locks, a bounded work queue with a thread pool, or per-thread data merged later. State the behaviour under overload and the cost of each choice under contention.

Questions & practice

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

14 technical prompts0 include a worked solution

Why is Quicksort preferred for arrays and Merge Sort for linked lists?

medium
Data Structures and Algorithms

Why is Quicksort preferred for arrays and Merge Sort for linked lists?

Approach
  1. Arrays: quicksort partitions in place with sequential, cache-friendly scans and small constants. Recursing into the smaller partition and looping on the larger keeps the stack at O(log n). Merge sort on an array needs an O(n) auxiliary buffer plus copying.
  2. Linked lists: there is no random access, so median-of-three or random pivot selection costs a walk, and Hoare-style two-ended partitioning does not fit a singly linked list. Merge sort only relinks nodes, so merging needs no buffer. Bottom-up merge sort uses O(1) extra space, top-down uses O(log n) recursion.
  3. Guarantees: merge sort is O(n log n) in every case and stable. Quicksort averages O(n log n) but degrades to O(n^2) on bad pivots, for example sorted input with a first-element pivot. Randomised or median-of-three pivots make that unlikely, and introsort removes it by switching to heapsort past a depth limit proportional to log n.
  4. Edge cases to name: many duplicate keys (use three-way Dutch-flag partitioning), already-sorted input, and finding a list's midpoint with slow/fast pointers, which costs O(n) per level and leaves the total at O(n log n).
Follow-up
  • Write merge sort for a singly linked list in C, including the split and the merge.
  • How does introsort bound quicksort's worst case, and what does std::sort use in practice?
  • When would you still choose merge sort for an array, for example when you need stability or are sorting data that does not fit in memory?

Print the left view of a binary tree.

medium
Data Structures and Algorithms

Print the left view of a binary tree.

Approach
  1. Define the output first: the first node visible at each depth when the tree is viewed from the left. That node can sit in the right subtree when the left subtree is shallower, so following only left pointers is wrong.
  2. BFS: run a level-order traversal with a queue, read the queue size at the start of each level, and output the first node dequeued at that level. O(n) time and O(w) space, where w is the maximum width.
  3. DFS: do a preorder visit (node, left, right) carrying the depth and a max-depth-seen value, and output a node whenever its depth exceeds that maximum. O(n) time and O(h) stack, which becomes O(n) on a skewed tree.
  4. Edge cases: an empty tree (NULL root), a single node, and a right-only skewed tree, where every node is in the view. In C, size the BFS queue as an array of node pointers with capacity n, or use the recursive DFS.
Follow-up
  • How would you print the right view, and what changes in each version?
  • The tree is deep enough to overflow the recursion stack. How do you make the DFS iterative?
  • How would you print the top view, where nodes are grouped by horizontal distance instead of depth?

Reverse each word in a given string.

medium
Data Structures and Algorithms

Reverse each word in a given string.

Approach
  1. Clarify the transformation: reverse the characters inside each word but keep the word order ("hello world" becomes "olleh dlrow"). Also ask how multiple, leading and trailing spaces, tabs and punctuation should be treated.
  2. Do it in place with two pointers: scan for the start and end of each word, then swap characters inward from both ends. O(n) time and O(1) extra space on a mutable buffer.
  3. C pitfalls: modifying a string literal is undefined behaviour, so copy it into a char array first. Stop at the NUL terminator, and cast to unsigned char before calling isspace.
  4. Related trick: to reverse the word order instead, reverse the whole string and then reverse each word. Note that byte-wise reversal corrupts multi-byte UTF-8 characters, so Unicode input needs reversal by code point.
Follow-up
  • Reverse the order of the words in place, with O(1) extra space.
  • Collapse runs of spaces to a single space in the same pass.
  • How would you handle UTF-8 input without breaking multi-byte characters?

Find the sum of elements in a matrix.

medium
Data Structures and Algorithms

Find the sum of elements in a matrix.

Approach
  1. Baseline: a nested loop is O(rows x cols), and that is optimal because every element has to be read once. Say so instead of searching for a faster single-query algorithm.
  2. Correctness: accumulate into a wider type (int64_t or long long) so the sum of many ints cannot overflow. For floating point, mention Kahan or pairwise summation to limit rounding error.
  3. Performance in C: 2D arrays are row-major, so put rows in the outer loop and columns in the inner loop. Column-first traversal strides by the row length and misses cache on large matrices.
  4. Representation and edge cases: a true 2D array, an int** of separately allocated rows, or a flat array indexed as i*cols + j. Handle zero rows or columns, jagged rows and NULL input.
  5. Extension: for many sub-rectangle queries, build an (r+1)x(c+1) prefix-sum table in O(rc). Answer each query in O(1) as P[r2+1][c2+1] - P[r1][c2+1] - P[r2+1][c1] + P[r1][c1].
Follow-up
  • Elements are also updated between queries. What structure keeps both operations fast? (A 2D Fenwick tree gives O(log r x log c) each.)
  • The matrix is mostly zeros. How would you store it and sum it?
  • How would you split the sum across threads without false sharing on the partial sums?

Calculate the distance between two points.

medium
Data Structures and Algorithms

Calculate the distance between two points.

Approach
  1. Clarify the metric and the space: Euclidean sqrt(dx^2 + dy^2), Manhattan |dx| + |dy|, Chebyshev max(|dx|, |dy|), how many dimensions, and whether the points are latitude/longitude, which needs the haversine great-circle formula.
  2. Numerics in C: hypot(dx, dy) avoids intermediate overflow and underflow. With integer coordinates, compute dx*dx in a 64-bit type, because squaring a large int32 difference overflows.
  3. When only the ordering matters, as in nearest-point checks, compare squared distances and skip sqrt. When comparing floating-point results, use a tolerance instead of ==.
  4. Show where the primitive leads: the k closest points to an origin with a size-k max-heap in O(n log k), and the closest pair among n points, O(n^2) brute force or O(n log n) divide and conquer.
Follow-up
  • Return the k points closest to a given point, and state the complexity.
  • Find the closest pair among n points faster than O(n^2).
  • How does the computation change for points on the Earth's surface?

Discuss memory management strategies in C.

medium
System Design and Networking Fundamental

Discuss memory management strategies in C.

Approach
  1. Lay out the storage durations: automatic (stack, freed on return, so returning a pointer to a local is undefined behaviour), static (lives for the whole program), and allocated (malloc, calloc, realloc, free). malloc returns uninitialised memory. calloc zeroes it, and mainstream implementations check the count*size multiplication for overflow.
  2. Ownership discipline: document who frees each allocation, free on every error path (a single cleanup label with goto is common in C), and set pointers to NULL after free. free(NULL) is a no-op. Never write p = realloc(p, n), because the original block leaks if realloc fails; assign to a temporary first.
  3. Name the failure classes and the tools that catch them: leaks, double free, use-after-free, buffer overruns and uninitialised reads. Use AddressSanitizer and LeakSanitizer in tests and Valgrind memcheck when you can't rebuild.
  4. Strategies for hot paths: preallocate at startup; use fixed-size pools or slabs whose free lists give O(1) allocation and free with no fragmentation (a natural fit for packet buffers); use arenas freed all at once per request; use reference counting for buffers shared between stages.
Follow-up
  • Implement a fixed-size block pool allocator in C with alloc and free.
  • Why can a process's memory usage stay high after it frees most of its allocations?
  • How would you make an allocator scale across threads without one global lock?

Discuss the trade-offs of using specific data structures in a real-time system.

medium
Technical Problem Solving

Discuss the trade-offs of using specific data structures in a real-time system.

Approach
  1. Frame the deciding metric: a real-time path needs a bounded worst-case latency, not a good average. Judge every structure by its worst single operation and by whether it allocates.
  2. Hash tables give O(1) average lookups, but a resize is an O(n) pause and collisions can degrade lookups. Pre-size the table or rehash incrementally. Dynamic arrays push in amortised O(1) with occasional O(n) reallocation, whereas a fixed-capacity ring buffer is O(1) on every operation and never allocates.
  3. Balanced trees (red-black, AVL) guarantee O(log n) per operation and keep keys ordered. Tries bound lookup by key length, as in longest-prefix match. Linked lists give O(1) insertion when you already hold the node, but pointer chasing misses cache, so arrays often win in practice.
  4. Timers and scheduling: a binary heap gives O(log n) insertion and removal of the minimum. A timing wheel gives O(1) insertion and cancellation at the cost of coarser resolution. Hierarchical wheels extend the range.
  5. Memory and synchronisation: keep malloc off the hot path by using preallocated pools, and avoid garbage-collected runtimes for strict deadlines. With locks, account for priority inversion, which priority-inheritance mutexes address.
Follow-up
  • Design a structure to manage a million connection timeouts with cheap insert and cancel.
  • How would you make a hash table resize without a long pause?
  • When is a lock-free structure worse than a lock in a real-time system?

Suggested practice checklist

The plan begins with the reported coding questions in C or C++, moves to memory and networking fundamentals, and finishes with throughput, debugging, concurrency and a full spoken rehearsal.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Sorting trade-offs in C
  • Write Quicksort for an int array in C with a random or median-of-three pivot and Hoare or Lomuto partitioning, and test it on sorted, reversed and all-equal inputs to see the worst case.
  • Write Merge Sort for a singly linked list, using slow and fast pointers to split and relinking nodes to merge, and note the recursion depth and extra space.
  • Write a half-page answer for why Quicksort is preferred for arrays and Merge Sort for linked lists, covering random access, cache locality, stability, worst case and memory.

Deliverable: Two working C programs (array Quicksort, linked-list Merge Sort) and a written comparison answering the sorting question.

Practice prompt ↗
02Trees and strings
  • Implement the left view of a binary tree with a level-order queue, then with a recursive walk that tracks the deepest level printed so far; run both on a skewed tree and a complete tree.
  • Reverse each word of a string in place on a char array without library calls, then check an empty string, one word, leading and trailing spaces and repeated spaces.
  • State the time and extra-space cost of each solution, and what changes if the input is a read-only string literal.

Deliverable: Working code for the left view (two versions) and for in-place word reversal, with a test list of edge cases for each.

Practice prompt ↗Practice prompt ↗
03C memory management, matrices and distance
  • Write notes comparing stack, heap, static and memory-pool allocation in C, and list the failure modes of each: leaks, double free, use after free, dangling pointers, fragmentation, buffer overruns.
  • Allocate a matrix as one contiguous block and as an array of row pointers, sum it in row-major order, and explain the cache effect and the freeing of each layout.
  • Write the point-distance function, decide between sqrt and comparing squared distances, and handle integer coordinates that overflow when squared.

Deliverable: A memory-management cheat sheet, a matrix-sum program in two layouts, and a distance function with its overflow cases noted.

Practice prompt ↗Practice prompt ↗Practice prompt ↗
04Network layers and a packet's path
  • Write the sequence for typing a URL: DNS resolution and caching, TCP three-way handshake, TLS handshake, HTTP request and response, connection close.
  • Draw the encapsulation of one request: application data, TCP segment, IP packet, Ethernet frame, and mark the addresses and ports used at each layer.
  • Explain how a host picks the next hop: its own subnet versus the default gateway, ARP, and longest-prefix match in a routing table, then how the operating system hands received data to a socket and a process.

Deliverable: One annotated diagram of a request's path through the stack, plus a spoken walkthrough of it you can give without looking at the diagram.

Practice prompt ↗Practice prompt ↗
05Throughput and real-time data structures
  • List the levers for a high-throughput network path: batching, avoiding copies, preallocated buffers in place of per-packet allocation, a lock-free single-producer ring buffer, per-core sharding, and measuring first with a profiler.
  • Build a table of array, linked list, hash table, balanced tree, heap and ring buffer with worst-case cost per operation, allocation behaviour and cache behaviour.
  • Explain which structure you would use for a fixed-size packet queue and for a lookup table that must never pause for a rehash, and why.

Deliverable: A throughput checklist and a data structure trade-off table with a chosen structure and reason for two scenarios.

Practice prompt ↗Practice prompt ↗
06Memory leaks and concurrent requests
  • Write a short C program with a deliberate leak, find it with AddressSanitizer or Valgrind, and note what each tool does and costs.
  • Write a production leak runbook: confirm growth from resident memory, tie it to load, separate leak from cache or fragmentation, take allocation snapshots, bisect by build, verify the fix.
  • Implement a bounded queue with a mutex and condition variables in C or C++, run it with a pool of worker threads, and decide what happens when the queue is full.

Deliverable: A leak runbook and a working bounded queue with worker threads, with the overload behaviour written down.

Practice prompt ↗Practice prompt ↗
07Full spoken rehearsal
  • Work through one coding problem and then three spoken answers back to back (sorting trade-offs, the URL walkthrough, the memory leak), with no editor or notes, and record yourself.
  • Replay the recording and mark any answer that stated no assumption, no complexity or no trade-off, then redo those answers.
  • Prepare one real story of a bug you chased in low-level code, using PracHub's practice question on narrating an outage you owned as a structure.

Deliverable: A recording of the rehearsal, a list of answers to redo, and one rehearsed debugging story.

Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗

Expand any day for tasks and deliverables. Your progress is saved on this device.

Explaining your own systems work

Candidates report two technical rounds and no separate behavioral stage. Questions like the memory-leak and real-time trade-off ones are still easiest to answer with a real experience behind them, and the role includes code review, module ownership and system-level debugging. Rehearse a few stories that show concrete evidence, such as what you measured, what you changed and what the result was.

Tell callers you do not own that their integration breaks

medium
deprecationcompatibilitystakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach
  1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
  2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
  3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
  4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
  • How would you detect a consumer that reads the field only during a monthly export?
  • One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?

Estimate work you have never done and defend the range

hard
estimationbackfillsexpand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach
  1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
  2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
  3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
  4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.
Follow-up
  • How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
  • Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?

Narrate an outage you owned from page to postmortem

hard
incident responseblast radiuspostmortems

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?
  • 01

    Tell me about a memory, pointer or concurrency bug in C or C++ code that you tracked down. How did you find it, and how did you confirm the fix?

  • 02

    Describe a time you made code measurably faster. What did you measure before and after, and what did you decide not to optimise?

  • 03

    Walk me through a decision where you chose one data structure over another. What did the alternative cost you?

  • 04

    Tell me about a module you owned from design to deployment. Which decision would you make differently now?

  • 05

    Describe a code review where you found a problem with error handling or memory use. How did you raise it?

PracHub preparation framework ↗

Frequently asked questions

How many rounds are there and how long does the process take?

Candidates report two stages: a Technical Assessment that sets a baseline for coding skill, then back-to-back Technical Interviews on breadth and specific expertise. The whole process is reported as roughly 2-4 weeks. Treat this as what candidates describe rather than a published schedule.

Arrcus Software Engineer candidate reports ↗
Which language should I use for the coding questions?

The reported requirements list C or C++ first, with scripting listed as a nice-to-have for automation and testing. Use C or C++ for the sorting, tree, string and matrix problems, so your code shows the memory and pointer handling the role describes.

Arrcus Software Engineer candidate reports ↗
What topics do the reported questions cover?

Three groups. Coding and algorithms: sorting trade-offs, the binary tree left view, reversing words, matrix sum and point distance. Systems and networking: a URL typed into a browser, network layer interaction, memory management in C and optimizing for high-throughput networks. Problem solving: debugging a production memory leak, concurrent data requests and data structure trade-offs in a real-time system.

Arrcus Software Engineer candidate reports ↗
How much networking do I need to know?

Candidates report networking theory as a core part of the technical rounds. Know the OSI and TCP/IP layers, what each adds to a packet, how DNS, TCP and TLS set up a connection, how a host chooses a next hop and how the operating system delivers data to a process. Trace a single request through them rather than memorising layer names.

PracHub Software Engineer practice ↗
How should I practise the coding rounds?

Candidates report that problems may be solved on a whiteboard or explained verbally, so practise without an editor and speak while you write. State assumptions, write the solution in C or C++, give time and space complexity, and walk through edge cases such as empty input, repeated spaces and overflow.

Arrcus Software Engineer candidate reports ↗
Do I need cloud-native networking experience?

It appears among the nice-to-have skills, next to high-throughput or low-latency work and scripting, not among the must-haves. Spend most of your preparation on C or C++, data structures and algorithms, networking protocols and debugging. If you have relevant experience, bring it into your answers on throughput and system design.

PracHub Software Engineer practice ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.

Browse Software Engineer questions