Wireless Systems Engineer Interview Questions and Strong Answers

What is the difference between RSRP, RSRQ, and SINR?

RSRP is the average power of the measurement reference symbols — SS-RSRP from the SS/PBCH block in 5G NR, CRS-based in LTE — a coverage metric, independent of load. RSRQ is RSRP relative to the total received power (N·RSRP/RSSI over the same resource blocks), so it folds in cell loading and interference: RSRP can be strong while RSRQ collapses in a loaded or interference-heavy cell. SINR is the signal-to-interference-plus-noise ratio the receiver actually experiences, and it is the closest predictor of achievable MCS and throughput. The diagnostic use: weak RSRP suggests a coverage problem; good RSRP with poor RSRQ or SINR usually points at interference or loading — though beam mismatch or a receiver impairment can mimic it — and the two cases call for different fixes.

Why can a device have good RSRP but low throughput?

Good RSRP only means the signal power is strong. Throughput can still be limited by interference, low SINR, conservative MCS selection, BLER, HARQ retransmissions, low MIMO rank, scheduler constraints, thermal throttling, or network bottlenecks.

How do you debug high BLER in a 5G NR link?

Split the question first: is the link operating beyond its channel (SINR too low for the selected MCS — link adaptation should be backing off, so check whether CQI reporting and MCS selection are tracking each other), or failing within it (adequate SINR but errors anyway — which points at channel estimation, synchronization, beam tracking, or an RF impairment like phase noise or IQ imbalance)? The logs make the split visible: compare reported CQI against assigned MCS and watch whether BLER is uniform or bursty. Bursty errors correlate with mobility, beam switches, or interference bursts; uniform errors at modest MCS widen the suspect list to implementation, test setup, or stable wideband interference — and can also just be link adaptation holding its BLER target, which is why the CQI-vs-MCS comparison comes first.

How do modem logs help diagnose wireless issues?

Modem logs show what the device measured, selected, requested, decoded, retransmitted, or rejected. They help connect a KPI failure to the underlying PHY, MAC, protocol, or RF behavior instead of guessing from the symptom alone.

How do you separate a lab pass from a field failure?

I compare the controlled lab assumptions against field conditions such as mobility, interference, antenna blockage, thermal state, real traffic, band combinations, and network configuration. Then I use logs to find where the KPI first starts to degrade.

How does carrier aggregation affect observed throughput and debugging?

Carrier aggregation combines multiple component carriers to raise peak throughput, but each carrier has its own radio conditions, scheduling, and activation state. When throughput is below expectation, I check whether the expected carriers are configured and active, whether the secondary cell is being scheduled, and whether one carrier is dragging the aggregate down before assuming a single-carrier problem.

Why does MIMO rank matter as much as SINR for throughput?

SINR sets how high an MCS the link can sustain on one stream, but rank sets how many independent streams the channel can carry. A rich, well-conditioned multipath channel supports higher rank and multiplies throughput; a line-of-sight or correlated channel may have great SINR yet only rank 1. Diagnosing low throughput means checking both the per-stream quality and the achievable rank.

How do you approach a mobility or handover failure?

I trace the measurement reports, the configured thresholds and offsets, and the handover command timing in the logs. The failure is usually a too-late or too-early trigger, a missing neighbor relation, a target cell that is loaded or unreachable, or a radio-link failure during the gap. The logs show which step in the handover sequence broke and under what radio conditions.

How does HARQ work, and how does it change what BLER means?

HARQ retransmits failed transport blocks and the receiver combines the attempts: chase combining repeats the same bits, effectively raising the SNR of the combined decode, while incremental redundancy sends new parity bits that lower the effective code rate. That is why throughput-oriented link adaptation commonly targets roughly 10% BLER on the first transmission — HARQ cleans up the residue cheaply — while latency-critical services target far lower. The reading consequence: initial BLER near the target is healthy link adaptation, not a problem; the numbers that matter are residual BLER after HARQ (far lower in a healthy link, with how far set by the retransmission budget) and the retransmission count, because both translate directly into latency.

Why is the uplink often the limiting direction of a link?

Asymmetry of transmit power and antennas: a typical handset transmits at around 23 dBm (the common power class — high-power UEs go higher, and FR2 is specified as radiated EIRP instead) from one or two antennas next to a human body, while the base station radiates from a high-gain antenna array at far higher EIRP. So at cell edge the uplink usually runs out of link budget first — the device can hear the network but cannot reach back. That is why coverage planning is often uplink-driven, why TDD slot configuration matters for uplink-heavy traffic, and why a "no throughput" complaint at cell edge should make you check the uplink before the downlink.

What changes when debugging FR2 (mmWave) compared to FR1?

At FR2 the link is directional by design: coverage is beam-shaped — including reflected non-line-of-sight beams — so beam management (sweep, refinement, beam failure recovery) becomes part of every debug, and blockage from a hand, head, or passing vehicle produces tens of dB of loss with abrupt onset, with fades often lasting hundreds of milliseconds as the blocker moves through. Lab-to-field gaps widen too: FR2 testing is over-the-air, so geometry, device orientation, and even how a phone is held move results that conducted FR1 measurements would hold stable. The debugging habit that transfers: log beam indices and switch events alongside the usual KPIs, because a throughput cliff at FR2 is often a beam event — rule that out before scheduling theories.