5G is a hardware problem too: the RF and edge realities behind the software
5G gets talked about as a software story — slicing, orchestration, containerized cores. Underneath it is a layer of physics that doesn't care about your API. Here's the tour I give candidates to see if they've actually stood in front of the hardware.
Spectrum is a tradeoff, not a feature list
5G spans two physical regimes. Sub-6 GHz behaves close enough to LTE that most RF engineering carries over — decent propagation, real building penetration, macro sites spaced kilometers apart. mmWave (roughly 24 GHz and up) buys huge bandwidth and multi-gigabit peaks, but the physics bill comes due immediately: free-space path loss scales with the square of frequency, so a mmWave link bleeds signal fast, before foliage, rain, or a blocked line of sight even enter the picture. That's why mmWave deployments look nothing like macro cellular — you can't out-amplify path loss that severe, so you get there with density: small cells every few hundred feet. It's a capacity tool for stadiums and dense corridors, not a coverage blanket.
Massive MIMO turns antennas into a computation
Massive MIMO panels carry dozens of antenna elements, and the base station shapes the radiation pattern in real time via beamforming — constructive interference toward one user, destructive elsewhere. Done well, this is spatial multiplexing: the same time-frequency resource serves multiple users because the energy is aimed differently for each. But beamforming lives on channel state information, constantly re-estimated against multipath and mobility. A stale estimate points the beam at where the user used to be.
The RAN split most software people never see
O-RAN's disaggregation into Radio Unit, Distributed Unit, and Centralized Unit is usually framed as an openness story. It's also a timing story. The RU-to-DU fronthaul link carries synchronized traffic on a budget measured in microseconds, and the split point determines how much real-time PHY processing stays at the antenna versus moves to a centralized DU. Get the fronthaul jitter wrong and you don't get a software bug — you get failed scheduling or a radio that won't sync with its own baseband.
Edge compute exists because latency is physical
MEC gets pitched as an application-layer play — run the workload closer to the user, cut round-trip time. The reason it has to be physically closer is worth sitting with: light in fiber travels at roughly two-thirds the speed of light in vacuum, on the order of 5 microseconds per kilometer, each way. A round trip to a data center a few hundred kilometers off adds low-single-digit milliseconds of unavoidable propagation delay — enough to eat the whole budget for control loops and other sub-10-millisecond use cases. No software fixes a speed-of-light problem; MEC exists because distance is the only lever left.
Power, thermal, and timing: the site nobody tours
A cell site is a power and thermal problem wearing a software hat. Massive MIMO radios draw more power than legacy panels, and much of it turns into heat that has to be managed in an outdoor enclosure sitting in direct sun. PA efficiency and thermal derating shape what the radio delivers in the field versus what the datasheet claims in the lab. Underneath it all sits synchronization, the domain I see most underestimated: coordinated radios need a shared sense of time for handover and interference coordination, typically distributed via GPS and refined with PTP. Lose GPS lock — a rooftop issue, jamming, a bad cable — and PTP has to hold the fabric together alone. Timing errors rarely announce themselves as timing errors; they surface as intermittent handovers or interference that looks environmental.
Why this is the screen, not the trivia
None of this is exotic — it's the baseline for deploying or debugging a 5G network, not just configuring it. It's easy to fake on a resume and easy to miss in a screen that stays at the protocol-stack level.
- RF fundamentals. Can they reason about link budget and path loss, not just recite band names?
- MIMO and beamforming. Do they know what channel state information depends on, and what breaks it?
- RAN split and fronthaul. Have they worked a timing budget, or just read about O-RAN?
- Edge and latency. Do they treat MEC placement as a physics decision first?
- Power and thermal. Have they seen a site, or only a spec sheet?
- Sync and timing. Can they diagnose a GPS/PTP failure, or chase it as a software bug for a week?
That's why I screen technical candidates myself: it catches the difference between fluency in vocabulary and having reasoned across the hardware/software boundary under production pressure.
Hiring for a role where the hardware actually matters?
If the seat requires reasoning across RF, RAN, and software — not just one layer — tell us the seat and we'll screen for the whole stack.
Tell us the seat