Design Thread-Safe Primitives

Two prompts recur in Qualcomm's low-level design round more than almost any other, and both are C++ primitives. Implement a thread-safe Singleton. Implement a smart pointer with a reference count. They pass for syntax exercises. Each hides a specific hazard that a firmware engineer meets for real. An interviewer checks whether you name that hazard before you reach for a keyword. The Singleton is a question about the memory model and a data race on one pointer. The smart pointer is a question about who owns what and when the last owner frees it. Say the hazard out loud, then write code that closes it. Engineers who have shipped concurrent C++ answer this way.

These two primitives are the purest form of the low-level design signal, and they pair because they exercise the same instinct from opposite ends. The Singleton is about construction. A single object must be built exactly once even when many threads race to build it, and no thread may ever see a half-built one. The smart pointer is about destruction. A shared object must be freed exactly once, by the last owner, no sooner and no later. Both live or die on ownership and ordering, the two things this round tests. Neither has any architecture to draw. There is nowhere to hide behind a diagram.

The Qualcomm angle

Qualcomm ships C++ that runs close to the metal, so these primitives are daily tools of the codebase. The engineers grading you write firmware and drivers. There a data race is a field bug that reproduces once a week, and a leaked object on a constrained device is fatal over time. So the Singleton question keeps going past the naive answer, into double-checked locking, volatile, and memory barriers. The smart pointer question keeps going into the control block, atomic counts, and cycles. Name what is shared, say what orders the memory, and say who runs the destructor. Say those out loud and build so the race and the leak cannot happen. This round rewards that language.