Advanced Wireless Technology Group Software Engineer Interview Guide

The 60-second brief

Candidate reports place this Software Engineer role in wireless communications, describing it as work on the systems behind wireless networks. RAN (Radio Access Network) comes up as a domain, and candidates describe working with RAN Engineers and Network Architects. The role is described as based in London.

This guide is for engineers preparing for the Software Engineer loop at Advanced Wireless Technology Group. It covers the six reported rounds, the fifteen questions candidates report (five on networking and domain knowledge, five on systems and infrastructure, five behavioral), and a plan that spends time on fundamentals the whiteboard round relies on. Candidates describe C++ or Python, Linux and TCP/IP as the baseline, with 5G or LTE, real-time operating systems and cloud-native practice as extras, and experience of roughly two to three years in software development.

Candidates report six stages over roughly four to six weeks: Technical Screening, Deep-Dive Sessions, Whiteboard Coding Challenges, System Design Discussions, Behavioral Interviews and Final Panel Interviews, with the last held onsite or virtually.

Focus areas

• Wireless Networks (RAN)
• Networking Fundamentals
• System Engineering

Overview

The work as candidates describe it sits between network infrastructure and software. You write and test code that interacts with network hardware, work with RAN Engineers and Network Architects on requirements, and help debug integration-testing failures. That mix explains the shape of the reported questions: a block on networking and domain knowledge (RAN architecture, latency troubleshooting, low-level driver optimisation, TCP versus UDP over wireless, high availability), a block on systems and infrastructure (monitoring base stations, updates without downtime, performance against power, consistency across nodes), and a block of behavioral prompts about failures, trade-offs, fast learning and disagreement.

Preparation therefore has two halves. The first is fundamentals you can reproduce without an IDE: data structures and algorithms in C++ or Python, the TCP/IP stack, what happens to throughput and latency when the radio link loses packets, and how a service stays up across upgrades and node failures. The second is the ability to tie each answer to a layer: say which layer you are reasoning about (radio, transport, application, operations) and what you would measure there.

None of the reported questions is a coding problem, even though a whiteboard coding round is reported. Do not read that as a lighter round. Treat it as a gap in the question list, and cover it with ordinary algorithm practice done on paper in your strongest of C++ or Python, with edge cases written out. The reported example scenarios for network and systems design, a failover mechanism for a critical network node and an optimised packet-processing pipeline, are worth rehearsing aloud alongside the design questions.

If your background is web or cloud rather than telecom, say so plainly and bridge from it. The design questions reward answers built on principles you already know (replication, rolling upgrades, consistency models, metrics pipelines) applied to base stations and radio links, plus honest statements about where your RAN knowledge ends. Candidates report that explaining your reasoning clearly matters even when the final answer is uncertain.

The Advanced Wireless Technology Group interview process

These stages are what candidates report, with no published schedule behind them. Reports put the whole process at about four to six weeks, so confirm the format of each stage with your recruiter.

Technical Screening

Candidates describe this as the first assessment of coding capability and technical skill. Reported advice says the fundamentals carry this stage: data structures, algorithms and core networking concepts. Prepare to write correct code in C++ or Python and to explain basic network behaviour precisely, for example what changes between TCP and UDP when the link is lossy.

What to demonstrate

• Working code in the language you choose, including edge cases
• Command of networking fundamentals such as the TCP/IP layers
• Clear explanation of your reasoning while you work

How to prepare

• Solve a handful of array, hash map and graph problems in C++ or Python, then re-read each solution for empty input, duplicates and overflow
• Write a half-page on TCP versus UDP over a lossy radio link: retransmission, congestion control reacting to loss, ordering and when an application would choose UDP
• Be ready to say, in a sentence per layer, where the Linux kernel, a driver and an application each sit in a packet's path

Deep-Dive Sessions

Candidates describe in-depth discussions with engineering leads about systems-level architecture. Expect to defend design choices from your own past work, and to reason about how software components relate to hardware in a RAN setting. Reported tips say to explain the why behind choices and the trade-offs you weighed.

What to demonstrate

• Depth of systems-level architecture knowledge
• Ability to justify design choices and name the trade-offs you accepted
• Honest boundaries on what you know about wireless systems

How to prepare

• Choose two projects you built and write the architecture, the alternatives you rejected and the cost of what you picked
• Sketch a RAN-style stack from memory (radio, baseband processing, transport, management and automation) and mark where software you have written would sit
• Rehearse the reported question on optimising code that interacts with low-level network drivers: measure first, then batching, copies, interrupts and cache behaviour

Whiteboard Coding Challenges

Candidates report coding problems solved on a whiteboard, with advice to practise writing code and diagrams without an IDE, whether the session is virtual or in person. No specific problems are reported, so prepare broadly in the language you know best and write complete, runnable-looking code with the edge cases handled.

What to demonstrate

• Problem-solving shown through code written by hand
• Clean, maintainable code that handles edge cases and performance bottlenecks
• Communication of your approach before and during writing

How to prepare

• Do several problems on paper or a plain text editor with no autocomplete, then trace each solution on a small input and one edge case
• State complexity for time and space after each solution, and practise one improvement step beyond the first working answer

System Design Discussions

Candidates report open-ended discussions about system design and architecture. Reported tips say to use ambiguity to clarify requirements and iterate. Reported question topics that suit a design discussion include monitoring a network of base stations, updates without downtime, performance against power and consistency across nodes, so build a repeatable structure you can apply to any of them.

What to demonstrate

• Requirement clarification before design
• Trade-offs between latency, throughput, availability and consistency
• How the design behaves under failure and increased load

How to prepare

• Write a design template: requirements and scale, data flow, storage, failure modes, rollout and observability; fill it in for base-station monitoring
• Rehearse the reported scenarios 'Design a failover mechanism for a critical network node.' and 'Explain how you would optimize a packet-processing pipeline.' aloud, with a diagram each
• Prepare rolling-upgrade and drain-then-restart answers, and a consistency answer that names a model (leader-based, quorum or eventual) and its price

Behavioral Interviews

Candidates describe interviews on collaboration, debugging approach and team-based problem solving, with a recommendation to structure answers using STAR. The reported behavioral-style prompts are worth rehearsing for this round: scaling for concurrent users, a critical failure and its root cause, explaining trade-offs to non-engineers, learning something quickly, architectural disagreement and competing priorities.

What to demonstrate

• Collaboration and handling of disagreement
• A methodical debugging approach told through a real incident
• Team-based problem solving and communication with non-engineers

How to prepare

• Write one STAR story per reported prompt, six in total, and check each uses I for your actions and ends with a measured result
• Add a debugging story with a timeline: detection, mitigation, evidence, root cause, prevention
• Practise explaining one trade-off, such as power use against latency, in two sentences with no jargon

Final Panel Interviews

Candidates describe a final assessment, onsite or virtual, to evaluate overall fit. Reported advice says to arrive rested and ready to move between deep technical work and broader situational discussion, so plan to revisit every earlier theme: fundamentals, design reasoning and your stories.

What to demonstrate

• Overall fit across technical and situational discussion
• Consistency between your design reasoning and your stories
• Ability to switch between detail and big picture

How to prepare

• Run a full mock in one sitting with an explanation of a RAN question, a design discussion and two stories, so the switch between modes is familiar
• Reread your notes on latency troubleshooting, high availability and update strategies, and prepare a closing question about how the team works with RAN Engineers and Network Architects
• Confirm the format (onsite or virtual) and rehearse diagramming in that medium

Where candidates lose points

Describing a RAN system as a generic block diagram with no sense of where software meets hardware

Practise a layered walk-through (radio, baseband processing, transport, management and automation) and say which parts your own code has touched. Where your experience stops, say so and reason from networking principles instead of guessing at vendor specifics.

Answering TCP versus UDP as a textbook list that ignores the wireless link

Tie each difference to radio conditions: loss from interference is not congestion, yet TCP may slow down in response; retransmission adds latency; ordering and head-of-line blocking matter for real-time data; UDP leaves reliability to the application. Give one case where you would choose each.

Troubleshooting latency by guessing a cause instead of narrowing it down

Present a sequence: confirm the symptom and when it began, measure per hop or per layer, compare against a baseline, check what changed, then bisect. Name the tools or counters you would use at each step.

Answering high-availability, update and consistency questions with 'add replicas' and stopping there

Cover failure detection, failover time, state that must survive, rolling or drained upgrades, and the consistency model you accept. State what happens to in-flight sessions during a failover or update.

Behavioral stories told with 'we', vague actions and no measured result

Write each story with I for your decisions, the evidence you used, and a number or concrete outcome. Rehearse the failure and disagreement stories especially, because they need concrete evidence.

Questions & practice

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

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

Approach

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

Follow-up

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

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

Easy · hashing · at-least-once · aggregation

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

Approach

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

Follow-up

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

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads 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?

Explain the architecture of a RAN system and how software components interact with the hardware.

Medium · Technical and Domain Expertise

Approach

1. Walk the path end to end: UE over the air to the radio unit (RU: RF, low PHY), then the distributed unit (DU: high PHY, MAC, RLC), then the central unit (CU: PDCP, RRC, SDAP), then backhaul to the core. In LTE the eNodeB is the same idea as a baseband unit plus remote radio head.
2. Name the interfaces: fronthaul DU to RU (O-RAN split 7.2x over eCPRI), F1 between CU and DU, NG to the 5G core (N2 control to the AMF, N3 user plane to the UPF), Xn between gNBs. LTE equivalents are S1 and X2.
3. Separate control plane from user plane: the CU splits into CU-CP and CU-UP, so signalling and packet forwarding scale independently and can run as software on general-purpose servers.
4. Explain where software meets hardware: the MAC scheduler must decide every slot (1 ms at 15 kHz NR numerology, 0.5 ms at 30 kHz), so the DU runs on real-time tuned Linux and offloads heavy PHY work such as LDPC decoding to FPGA or ASIC accelerators; the RU needs precise timing from PTP and SyncE.
5. Mention the O-RAN control layers if relevant: the near-real-time RIC talks to RAN nodes over E2, the non-real-time RIC sits in the SMO and uses A1, and O1 carries management and configuration.

Follow-up

• Why split the CU from the DU at all, and what latency budget does each split point impose on the transport?
• What happens to the cell if fronthaul latency or timing sync drifts out of budget?
• Where would you put a new scheduling optimisation: in the DU, or as an xApp on the near-real-time RIC, and why?

Describe your process for optimizing code that interacts with low-level network drivers.

Medium · Technical and Domain Expertise

Approach

1. Anchor the answer in one real optimisation you did: name the hardware, the bottleneck you found, the change you made and the before-and-after packets per second or p99 latency, so it is told as experience and not only as a technique checklist.
2. Show the method behind it: profile before optimising, measuring packets per second and cycles per packet at the worst case (64-byte frames; 10 GbE line rate is about 14.88 Mpps, roughly 67 ns per packet) with perf and flame graphs, under a repeatable traffic generator such as pktgen or TRex.
3. Remove per-packet overhead: batch syscalls (recvmmsg and sendmmsg), rely on NAPI polling instead of an interrupt per packet, and avoid copies with PACKET_MMAP rings, AF_XDP, or a DPDK poll-mode driver that bypasses the kernel.
4. Keep data local: RSS to spread flows across queues, one queue per core with pinned threads, single-producer single-consumer lock-free rings between stages, preallocated buffer pools with no allocation on the hot path, hugepages to cut TLB misses, and the NIC on the same NUMA node as its cores.
5. Use hardware offloads (checksum, TSO, GRO and GSO) and tune interrupt coalescing, stating the trade-off: more coalescing raises throughput but adds latency, and busy polling cuts latency but burns a core and power. Guard correctness too (byte order, DMA buffer ownership, barriers around descriptor rings) and confirm each change with an A/B run.

Follow-up

• When would you not use kernel bypass, and what do you lose by bypassing the kernel stack?
• Your throughput doubled but p99 latency got worse: what changed and how do you find out?
• How do you test driver-facing code without the real hardware on your desk?

What are the primary differences between TCP and UDP in the context of wireless transmission?

Medium · Technical and Domain Expertise

Approach

1. Start with the basics: TCP is connection-oriented, reliable and ordered, with flow control and congestion control and a 20-byte minimum header; UDP sends independent datagrams with no delivery, ordering or congestion guarantees and an 8-byte header.
2. Explain the wireless problem: loss-based congestion control (Reno, CUBIC) reads any loss as congestion and cuts its window, so random radio loss lowers throughput; in LTE and NR, HARQ and RLC retransmissions hide most of that loss but turn it into delay jitter, which can trigger spurious retransmission timeouts.
3. Cover head-of-line blocking: one lost TCP segment stalls delivery of everything behind it, which hurts real-time traffic; that is why voice and video run RTP over UDP and recover or conceal loss in the application.
4. Name the mitigations: model-based congestion control such as BBR, split-TCP proxies at the network edge, and QUIC over UDP, whose independent streams avoid transport-level head-of-line blocking and whose connection IDs let a session survive an IP address change.
5. Tie it to the mobile network itself: GTP-U carries user traffic over UDP (port 2152) between RAN and core, while signalling such as S1AP and NGAP runs over SCTP.

Follow-up

• Why was QUIC built on top of UDP instead of as a new transport protocol?
• What happens to a long-lived TCP flow during a handover, and how could the network reduce the damage?
• If UDP has no congestion control, what stops a UDP video stream from flooding a congested cell?

How do you ensure high availability in distributed network systems?

Medium · Technical and Domain Expertise

Approach

1. Set a target and a failure model first: 99.99% availability allows about 52.6 minutes of downtime a year, and you need to say which failures you survive (process, host, link, rack, site) and which RTO and RPO you accept.
2. Remove single points of failure with redundancy (N+1, active-active or active-standby) and spread replicas across racks, power feeds and sites with anti-affinity so one event does not take out every copy.
3. Detect failure quickly and correctly: heartbeats with timeouts (shorter means faster failover but more false positives), load-balancer health checks, and BFD for sub-second link failure detection; VRRP or ECMP for gateway and path redundancy.
4. Fail over safely: use a quorum (odd node counts), leases and fencing tokens so an old primary cannot keep writing, which avoids split brain; replicate state synchronously if you cannot lose writes, asynchronously if you can trade a little data for latency.
5. Contain partial failures with timeouts, retries with exponential backoff and jitter, circuit breakers, idempotent operations and graceful degradation, then prove it with fault-injection tests.

Follow-up

• With only two nodes, how do you avoid split brain?
• How does an in-progress stateful session survive a failover to the standby?
• How would you measure availability as users experience it rather than as uptime of each box?

How would you design a monitoring system for a distributed network of base stations?

Medium · Systems and Infrastructure

Approach

1. Scope it with numbers: how many sites and cells, which KPIs (PRB utilisation, throughput, RRC setup success, call drops, alarms, hardware health), sample interval and retention. For example, 10,000 sites with 500 metrics every 15 seconds is about 333,000 samples per second.
2. Collect at the edge: a site agent that pushes (works through NAT and intermittent links) using streaming telemetry such as gNMI rather than slow SNMP polling, buffers locally during a backhaul outage, and replays with original source timestamps.
3. Ingest through a partitioned log such as Kafka keyed by site ID so per-site order holds, into a time-series store with downsampling and retention tiers; keep label cardinality bounded (per cell is fine, per UE is not).
4. Alert on the stream: threshold and rate-of-change rules, an absence alert when a site goes silent, deduplication, and topology-aware suppression so one failed transport link raises one alarm instead of hundreds.
5. Handle the awkward cases: counter resets and rollovers when computing rates, clock skew between sites, late data after an outage, and mutual TLS with certificate rotation for thousands of agents.

Follow-up

• A backhaul ring fails and 300 sites go silent at once: what does the on-call engineer see?
• How do you keep the monitoring pipeline itself from being the thing that fails during an incident?
• How would you add per-UE troubleshooting data without blowing up storage and cardinality?

What strategies do you use to manage system updates without causing network downtime?

Medium · Systems and Infrastructure

Approach

1. Pick the strategy by component: rolling updates behind health checks with connection draining for stateless services, blue-green when you need an instant switch back, and canaries on a small share of nodes with automatic rollback when KPIs regress.
2. Keep mixed versions compatible: versioned interfaces and messages, expand-then-contract schema and config changes, and feature flags so new code can ship dark and be turned on separately from the deploy.
3. For network elements, upgrade the standby of a redundant pair first, switch over, then upgrade the other; use in-service software upgrade and graceful restart so forwarding continues while the control plane restarts.
4. For base stations, use A/B firmware partitions with automatic fallback if the new image fails to boot, schedule the change at low traffic, and rely on neighbouring cells for coverage while one site restarts.
5. Make rollback a tested path, not an assumption: define the KPIs and thresholds that stop a rollout, and stage it in waves across regions so a bad release has limited blast radius.

Follow-up

• The new version writes a config format the old version cannot read: how do you roll back?
• How would you choose which cells or sites go into the canary group?
• What do you do with long-lived sessions on a node you need to restart?

How do you balance performance requirements with power consumption constraints in mobile systems?

Medium · Systems and Infrastructure

Approach

1. Frame it as energy, not just power: energy is power times time, so finishing quickly at high frequency and then sleeping (race to idle) can beat running slowly, while DVFS saves energy because dynamic power scales roughly with C times V squared times f.
2. Treat the radio as the main cost on a device: after a transfer the modem stays in a high-power connected state for a tail period, so batch and coalesce network requests; DRX cycles and the NR RRC_INACTIVE state trade wake-up latency for battery.
3. On the network side, mention cell or carrier sleep at low load, muting antennas or MIMO layers, and NR bandwidth parts that let a UE operate on a narrower bandwidth when demand is low.
4. In software, prefer interrupts or adaptive polling over busy polling, coalesce timers, offload work to hardware accelerators and place background work on efficiency cores.
5. Decide with measurements: set a latency target and an energy budget, measure energy per operation with a power profiler rather than CPU percentage, and choose the operating point that meets the latency target at the lowest energy.

Follow-up

• When does race to idle use more energy than running at a lower clock?
• A DPDK app busy-polls and hits its latency target but draws too much power: what would you change?
• How would you measure the energy cost of a single network request on a phone?

Explain how you would handle data consistency in a multi-node network environment.

Medium · Systems and Infrastructure

Approach

1. Classify the data first: configuration and ownership records usually need strong consistency, while counters and telemetry tolerate eventual consistency; say which you are designing for, because the mechanism follows from it.
2. For strong consistency, use a consensus log (Raft or Paxos): a majority quorum commits each write, 2f+1 nodes tolerate f failures, and a partitioned minority stops accepting writes instead of diverging.
3. For replicated stores without consensus, explain quorums: with N replicas, write to W and read from R with R + W > N so every read overlaps the latest write; lower values buy latency and availability at the cost of stale reads.
4. Resolve conflicts deliberately where you accept eventual consistency: last-writer-wins silently loses writes under clock skew, so prefer version vectors or CRDTs, and repair divergence with anti-entropy (for example Merkle-tree comparison).
5. Make delivery safe: at-least-once messaging needs idempotent handlers and sequence numbers; leases need fencing tokens; avoid two-phase commit across many nodes because it blocks if the coordinator fails, and consider an outbox or saga instead.

Follow-up

• A five-node Raft cluster splits three and two: what can each side do?
• Why is last-writer-wins dangerous when node clocks are not synchronised?
• How would you detect and repair two replicas that have silently diverged?

How would you troubleshoot a latency issue in a high-traffic wireless network?

Medium · Technical and Domain Expertise

Approach

1. Pin down the symptom before touching anything: which metric (RTT, one-way delay, p50 versus p99), which cells or UEs, since when, and whether it tracks load. A tail-only problem points at queueing or retransmission, a uniform shift at a path or configuration change.
2. Segment the path and measure each hop: air interface, fronthaul and backhaul transport, core user plane (UPF or S-GW), then the internet. Timestamped captures at each interface (for example tcpdump on the GTP-U side) show where the delay is added.
3. On the radio side check PRB utilisation, scheduler queue depth, SINR, BLER and HARQ or RLC retransmission counts; high load fills buffers (bufferbloat) and poor radio turns loss into retransmission delay.
4. On the hosts check CPU saturation, IRQ and core affinity, softirq drops in /proc/net/softnet_stat and NIC ring overflows in ethtool -S; packet-processing nodes often add latency when a single core is pinned at 100%.
5. Change one thing, re-measure the same percentile on the same cells, and keep a control group so a traffic dip is not mistaken for the fix.

Follow-up

• How would you tell radio-side delay apart from transport delay using only counters you already collect?
• Latency rises only at peak hour in one cluster of cells: what is your first hypothesis and how do you test it?
• How do you distinguish a cause from a coincidence when a software release went out the same day?

Suggested practice checklist

Each day targets a reported round or question group: networking fundamentals, latency and drivers, whiteboard coding, systems design, then behavioral stories and a full mock. Questions are named by subject, so you can practise them aloud.

Day 1 — Map the loop and sketch a RAN system

• Write the six reported rounds in order and mark the one you are least ready for
• Sketch the architecture of a RAN system from memory and label where software meets hardware
• List what you could not explain, such as 5G or LTE terms or RTOS basics, as a study queue for the week

Deliverable: A one-page loop map, one RAN architecture sketch with software and hardware boundaries labelled, and a written study queue.

Day 2 — Transport behaviour and latency troubleshooting

• Write a comparison of TCP and UDP over a lossy wireless link covering retransmission, congestion control, ordering and use cases
• Write a latency troubleshooting runbook: confirm symptom, measure per hop, compare baseline, check changes, bisect
• Answer both reported questions aloud with a diagram and record yourself

Deliverable: A TCP versus UDP comparison, a latency runbook, and two recorded spoken answers.

Day 3 — Low-level performance, real-time basics and the power trade-off

• Profile a small packet or buffer-handling loop in C++ or Python, then record the hotspots and one change made
• Write a driver-level optimisation checklist: measure, avoid copies, batch work, reduce interrupts, check cache behaviour
• Study real-time scheduling basics: priority inversion, deterministic latency, and how PREEMPT_RT Linux on a DU differs from an RTOS
• Prepare a spoken answer on balancing performance with power consumption in mobile systems, with two concrete levers

Deliverable: A profiling result with before and after numbers, a driver optimisation checklist, a half-page on real-time scheduling, and a two-lever power versus performance answer.

Day 4 — Whiteboard coding without an IDE

• Solve three problems by hand in C++ or Python, including one using hash maps and one using a graph or queue
• After each, trace a small input and one edge case and write time and space complexity

Deliverable: Three hand-written solutions with traces and complexity notes, plus two practice-set solutions.

Day 5 — Distributed systems design for a network

• Design monitoring for a network of base stations: metric collection, aggregation, alerting and storage, with failure behaviour
• Write answers on high availability, updates without downtime and consistency across nodes, each naming a mechanism and its cost
• Rehearse the failover and packet-pipeline scenarios aloud with diagrams

Deliverable: A monitoring design diagram, three one-paragraph mechanism answers, and two recorded scenario walk-throughs.

Day 6 — Behavioral stories

• Write six STAR stories, one per reported behavioral prompt, using I for your actions
• Add a measured result to each story and cut any sentence that describes the team rather than you
• Say each story aloud and trim it until the reasoning, not the setup, takes most of the time

Deliverable: Six written STAR stories with a measured result in each, and a trimmed spoken version of each.

Day 7 — Full mock of the final panel

• Run one sitting: a RAN architecture explanation, a design discussion, a hand-written coding problem, then two stories
• Review the recording for places where you stated a layer or measurement versus places you stayed vague
• Prepare two questions about how the team works with RAN Engineers and Network Architects

Deliverable: A recorded mock, a list of the weakest answers to rework, and two questions for the panel.

Stories for a networks-and-systems loop

Candidates report interviews on collaboration, debugging approach and team-based problem solving, with advice to use STAR. For a software engineer working beside RAN Engineers and Network Architects, the strongest stories show you owning a decision, using evidence to find a fault or settle a disagreement, and explaining trade-offs to people who do not write code.

Describe a time you had to scale a system to handle a significant increase in concurrent users.

Medium · Systems and Infrastructure

Approach

1. Choose a system you owned where concurrent load really grew, and open with numbers: peak concurrent users, sessions or connections, p95 and p99 latency, error rate, and the load at which it began to degrade. If the unit was network sessions or packets per second, say so rather than saying users.
2. Show how you located the bottleneck instead of guessing: load tests or production metrics, a profiler, queue depth, connection-pool saturation, lock contention, and a clear split between CPU-bound, I/O-bound and memory-bound.
3. Give the changes in order with reasons: fix the cheapest bottleneck first (connection pooling, caching, batching, an index), scale stateless components horizontally, then partition state if needed. Add back-pressure, rate limits or graceful degradation so overload sheds work instead of collapsing the service.
4. Explain how you derisked it: load test at a multiple of expected peak, canary or staged rollout, rollback plan, and the headroom you left.
5. Close with measured results and what remained the next limit. The mistake that sinks this story is vague claims such as 'it scaled fine' with no before-and-after numbers.

Follow-up

• What was the first component to fail under load, and how did you know?
• How would your design change at ten times that load?
• How did you show the improvement came from your change and not from a quieter traffic day?

Describe a time you encountered a critical system failure. How did you identify the root cause?

Medium · Behavioral and Problem Solving

Approach

1. Pick a failure with real impact where you drove the response. Open with two sentences on what failed, who or what was affected, and how it was detected.
2. Separate mitigation from root cause. Say what you did first to stop the damage (rollback, failover, shifting traffic, disabling a feature flag), then how you investigated.
3. Walk the investigation as hypotheses and evidence: what changed recently, logs and metrics around onset, correlation with deploys, configuration or traffic, reproduction in a test environment, bisecting changes. For a network problem, mention counters and packet captures from both ends. Name the evidence that confirmed the cause and one hypothesis you ruled out.
4. Distinguish trigger from underlying cause (a config push triggered it; a missing timeout or validation made it possible). Then give the fix and the prevention: an alert, a test, a runbook entry, a blameless review.
5. A story where the cause was found by luck, by someone else, or by blaming a person will not show a debugging approach.

Follow-up

• How did you know you had found the root cause and not a symptom?
• What would have detected the problem sooner?
• Was there a moment you considered a rollback and decided against it, and why?

How do you communicate complex technical tradeoffs to stakeholders who may not have an engineering background?

Medium · Behavioral and Problem Solving

Approach

1. Use a real case where a technical trade-off had a cost a non-technical person felt: higher availability costing more infrastructure, a faster release carrying a known test gap, lower latency drawing more power.
2. Structure it as decision needed, two or three options, what each costs in their terms (money, schedule, customer impact, risk), then your recommendation and why. Lead with the recommendation and the consequence, and bring the mechanism in only as needed.
3. Swap jargon for a number or an analogy: 'some calls drop during each upgrade, about this share of users' lands better than 'no connection draining'. A one-page summary or simple diagram helps.
4. Check understanding by asking them to restate the decision, then record the accepted risk and the date you will revisit it with data.
5. Two mistakes sink it: oversimplifying until the downside disappears, and delivering the full technical analysis so the decision never gets made.

Follow-up

• Tell me about a time the stakeholder disagreed with your recommendation.
• How did you convey a risk without either alarming people or understating it?
• What did you do when they chose the option you advised against?

Tell me about a time you had to learn a new technology or protocol quickly to complete a project.

Medium · Behavioral and Problem Solving

Approach

1. Pick a specific technology or protocol with a deadline that depended on it. State the adjacent knowledge you already had, so the ramp-up is believable.
2. Describe your method: read the primary source first (specification, RFC or vendor documentation), build a minimal experiment, observe real behaviour with logs or packet captures, then ask an experienced colleague specific questions. Say what 'enough' meant for the project.
3. Show how you checked your understanding: tests against known-good behaviour, review by someone experienced, a list of failure modes you studied, and what you deliberately chose not to learn.
4. State the outcome: what you shipped, its quality, and how you passed the knowledge on (a short document, a walkthrough for the team).
5. A weak version is 'I read the docs and it worked' with no obstacle and no gap admitted. Name a misunderstanding you had and how you corrected it.

Follow-up

• What misconception did you have to unlearn along the way?
• How did you decide you knew enough to ship?
• How would you ramp up on a standard such as 5G or LTE if the team needed it?

How do you handle disagreements within your team regarding architectural choices?

Medium · Behavioral and Problem Solving

Approach

1. Choose a disagreement on a real architectural decision where both options were reasonable: build versus adopt, synchronous versus asynchronous messaging, one service versus several, strong versus eventual consistency.
2. State the other person's position in its strongest form and name the criteria that mattered: latency, operability, cost, delivery risk, how reversible each option was.
3. Show how evidence settled it: a benchmark or small prototype, a written design document listing trade-offs, and an agreed decision owner such as the tech lead. Where evidence could not settle it, say you favoured the more reversible option and set a point to revisit.
4. Show that you committed to the outcome even if it was not your preferred one, and how the working relationship stood afterwards.
5. The mistake is a story where you were simply right and the other person was not, or one where you avoided the conflict.

Follow-up

• What if no benchmark could have settled it?
• What did you give up by accepting the outcome?
• Describe a time you changed your mind in a design discussion.

Describe a project where you had to balance competing priorities under a tight deadline.

Medium · Behavioral and Problem Solving

Approach

1. Lay out the competing priorities concretely: what each was, who owned it, and what the deadline was tied to.
2. Show your prioritisation method: impact, cost of delay, effort, dependencies and what cannot be undone. Separate must-haves from deferrable work, and cut scope rather than quality on paths where reliability matters.
3. Show the negotiation: you took options to stakeholders, agreed what would move, communicated early, tracked progress and re-planned when facts changed.
4. Give the result: what shipped, what was deferred, what that cost, and what you changed in planning afterwards.
5. The answer fails when it amounts to 'I worked longer hours' or 'I did everything', with no explicit decision about what to drop.

Follow-up

• What did you drop, and who was unhappy about it?
• How did you notice that the deadline was at risk?
• What would you plan differently next time?