Rust Developer interview questions

Passing the String by value transfers ownership to the parameter, so the old binding becomes unusable and only the final initialized owner can normally drop the value.

• The move transfers the String's stack representation without cloning its heap buffer, and Rust invalidates the source binding at compile time.
• If the callee returns the String, ownership moves back and the caller may use the returned binding without a new heap allocation.
• If the final initialized owner reaches a normal drop point, Drop runs there once; mem::forget, leaks, and process abort mean Rust does not guarantee that destruction runs.
• A type that implements Drop cannot also implement Copy, because implicit duplication would make single destruction impossible to guarantee.

Each call can receive a shorter reborrow of r, so the original mutable reference becomes usable again after that child borrow ends.

• At a parameter expecting &mut i32, the compiler can treat the argument as &mut *r rather than permanently moving r into the first call.
• While the reborrow is active, access through r is suspended because the shorter child borrow temporarily holds the usable exclusive access.
• The second call starts a new non-overlapping reborrow after the first function call has returned.
• An explicit assignment that moves r into another binding can consume the original reference, so this behavior is contextual rather than Copy semantics.

The push is accepted only when the shared borrow's last use occurs before the mutation, not merely when its enclosing block ends.

• Non-lexical lifetimes derive the active region from actual uses, so printing the reference before push can end the borrow early.
• Using that reference after push keeps the borrow live and rejects the mutation because Vec growth could reallocate and invalidate it.
• Calling drop on a Copy reference does not create special lifetime semantics, so a smaller scope or a true last use is the clearer way to end access.
• NLL shortens borrows when the data flow permits it but never allows a reference to survive a potentially invalidating mutation.

Elision assigns input lifetimes first and can infer an output only from one input lifetime or from a receiver lifetime.

• Rule one gives every elided input reference its own lifetime parameter, so x and y in first receive distinct inferred lifetimes.
• Rule two assigns the sole input lifetime to all elided output references when there is exactly one input lifetime.
• Rule three assigns the lifetime of &self or &mut self to all elided outputs when there are several input lifetimes and one is the receiver.
• Therefore trim ties its output to s by rule two, first needs an explicit relationship, and view ties its output to self by rule three.

I would use fn choose<'a>(x: &'a str, y: &'a str, pick_x: bool) -> &'a str, which limits the result to a lifetime valid for both inputs.

• At a call site, the inferred 'a is no longer than the shorter usable input lifetime because either branch may be returned.
• The annotation relates existing borrows and does not extend either allocation or force both original values to live equally long.
• If the function always returns x, y should have an independent or elided lifetime so the signature does not impose a false relationship.
• Returning an owned String is the right alternative when the result must outlive both borrowed inputs.

The 'static bound means the spawned future must contain no borrow shorter than the process, so it should usually own the String or an Arc to it.

• An owned String satisfies T: 'static because it contains no borrowed reference, even though that String can still be dropped when the task completes or is cancelled.
• A value of type &'static str is different because that particular reference is valid for the entire program.
• Box::leak can manufacture a 'static reference by intentionally never freeing the allocation, which turns ordinary task ownership into permanent retention.
• Moving the String into an async move block or cloning an Arc gives the task explicit finite ownership without a leak.

Shared references are covariant, function arguments are contravariant, and mutable references are invariant in their referent type because they permit writes.

• &'a T is covariant in 'a and in T, so a longer valid borrow can be shortened where a shorter one is accepted.
• A function pointer is contravariant in its argument and covariant in its return, since a function accepting more possible inputs can replace one accepting fewer.
• &mut T is covariant over its own borrow lifetime but invariant in T, because code holding it may replace the contained T.
• If &mut &'long str could become &mut &'short str, the shorter reference could be written into a slot later read as 'long, creating a dangling reference.

I would store byte ranges into the String unless a specialized self-referential abstraction is essential, because pinning the outer struct alone does not freeze the String buffer.

• A straightforward safe struct cannot tie an internal &str lifetime to its own String while still allowing operations that move, replace, drop, or reallocate that owner.
• Offsets or Range<usize> survive moves and let a method create a fresh slice after validating UTF-8 boundaries.
• A pinned self-referential design must initialize references after pinning, opt out of Unpin when address stability matters, and hide every operation that could invalidate the referent.
• Pin prevents safe movement of a non-Unpin pointee but does not make fields immutable or stop an inner String from reallocating through an exposed mutable API.

Option::take replaces the field with None before returning the old value, so the borrowed object remains fully initialized.

• Moving a non-Copy field directly through &mut self would leave a hole that the caller could later observe or Drop could traverse.
• take performs the same ownership pattern as mem::replace with a valid replacement value.
• The transferred Vec keeps its existing allocation and is dropped by the worker's eventual owner unless ownership moves again.
• For a plain Vec field, mem::take leaves Vec::default(), while replace is preferable when a preallocated replacement should remain.

Rust first calls the bundle's Drop::drop and then drops its fields in declaration order, while independent local variables are dropped in reverse declaration order.

• Drop::drop can still access all fields because automatic field destruction starts only after that method returns.
• A moved-out local is no longer dropped at its old binding, so only its final owner performs destruction.
• During panic unwinding, initialized values are dropped along the unwound stack, but panic = abort performs no unwinding cleanup.
• Code should encode required shutdown dependencies explicitly rather than rely on a surprising declaration order.

The implementation must prove that every valid use of the wrapper remains sound under the exact cross-thread access promised by Send or Sync.

• Send permits ownership to move between threads, while Sync means &Wrapper can be shared because &Wrapper is Send.
• Auto traits are derived from fields, so Rc prevents Send and Sync, and raw-pointer-like fields force the wrapper author to establish the external contract explicitly.
• An unsafe impl Send may be sound for a thread-transferable handle even when Sync is not, if concurrent calls through shared references are forbidden.
• The proof must cover aliasing, C library thread guarantees, callback threads, destruction, and any thread affinity rather than merely wrapping calls in a mutex.

I would choose from critical-section cost and update semantics, using an RwLock only after read concurrency proves useful and an actor when updates form a sequential protocol.

• Arc<Mutex<_>> is the simplest choice when accesses are short and contention is low, and Arc only shares ownership rather than making the table internally safe.
• Arc<RwLock<_>> can allow concurrent readers, but writer fairness, read duration, and implementation behavior must be measured under the actual 95/5 workload.
• An actor owns the table in one task and receives commands, which removes shared locking but adds queueing, message design, and one-owner throughput limits.
• Copy-on-write publication through ArcSwap is another fit when updates are rare and readers need lock-free snapshots, at the cost of rebuilding and retaining table versions.

I would bound the channel for a measured burst window and define what producers do once sustained input exceeds consumer capacity.

• A capacity of 10,000 absorbs roughly one second of the stated 10,000-event-per-second deficit, but no finite queue fixes sustained overload.
• send().await propagates backpressure by suspending producers, while try_send can implement explicit shedding or coalescing when waiting is unacceptable.
• reserve().await can secure capacity before performing expensive message construction and prevents wasted work during saturation.
• Queue depth, send wait time, rejected events, and consumer throughput must be observed together so memory growth is not the overload signal.

I would use watch for the latest configuration, broadcast only for best-effort audit fan-out, and oneshot for the single startup reply.

• watch retains one current value and notifies receivers of changes, so a slow receiver may skip intermediate configurations and read the newest state.
• broadcast retains a bounded sequence for every receiver, and a receiver that falls behind gets a Lagged error, so compliance-grade audit records need a durable log before fan-out.
• oneshot carries one value from one sender to one receiver without a stream or reusable subscription.
• None of these replaces mpsc when many producers should distribute each work item to one consumer.

The producer should publish the pointer with Release and the consumer should load it with Acquire before dereferencing the initialized object.

• Release prevents prior initialization writes from moving after publication, and a matching Acquire that observes the value makes those writes visible to the consumer.
• Relaxed is enough for an independent statistics counter because it guarantees atomicity but no ordering of surrounding data.
• SeqCst adds one global order among sequentially consistent operations, but it does not repair an invalid ownership or reclamation scheme.
• The design still needs a proof that only valid pointers are published and that no reader accesses the allocation after it is freed.

I would use the weakest orderings that preserve the state machine's synchronization proof, often AcqRel on success and Acquire or Relaxed on failure.

• A successful AcqRel operation can acquire data published by the previous state and release writes associated with the new state.
• A failed comparison performs only a load, so its ordering cannot be Release or AcqRel and should reflect whether the observed value carries data that must be acquired.
• The returned Err(actual) must drive the retry because another thread may have changed the state since the expected value was read.
• Correct orderings do not solve ABA or safe memory reclamation, which require a separate versioning, epoch, or ownership design.

Idle workers can steal runnable tasks from busy workers, but they cannot preempt a task that blocks or spends too long inside one poll.

• Per-worker queues favor locality, while externally spawned or overflow work can enter shared scheduling paths that other workers access.
• A spawned Send task may resume on a different worker after an await, so thread-local assumptions cannot cross suspension.
• Tokio scheduling is cooperative, which requires futures to return Pending or otherwise yield within bounded work.
• Work stealing balances runnable tasks but cannot create CPU capacity or rescue all workers blocked in synchronous calls.

I would move the blocking call to spawn_blocking and bound admission to that work so executor workers and the blocking queue cannot saturate unchecked.

• spawn_blocking uses Tokio's blocking pool, whose large default upper limit is not a substitute for a Semaphore sized to CPU and latency budgets.
• Once a blocking closure starts, aborting its JoinHandle does not stop the closure, so deadlines need cooperative cancellation or discard of late results.
• Sustained CPU-parallel compression may fit a dedicated Rayon pool better, with a bounded bridge from async request handling.
• block_in_place is limited to a multi-thread runtime and runs blocking code on the current worker after Tokio hands off other tasks, so it still needs careful capacity control.

poll must arrange for the current task's Waker to be notified after progress becomes possible and must never block the executor thread.

• The future checks readiness, registers or updates the current waker with the source, and rechecks state when registration can race with an event.
• That recheck closes the lost-wakeup window in which readiness changes between the first check and waker registration.
• Returning Pending without a future wake can leave the task asleep forever, while waking on every poll creates a busy loop.
• poll receives Pin<&mut Self> because the future state may rely on stable addresses, and Ready returns the final output.

I would keep partial protocol state outside the cancellable branch and select only over operations whose dropped futures do not lose committed progress.

• select! drops losing branch futures, so recreating a non-cancellation-safe read on each loop can discard bytes already consumed into that future's private state.
• The parser can own a persistent buffer, use a cancellation-safe read primitive to append bytes, and decode complete frames separately.
• A long-lived future that must retain internal progress should be created and pinned outside the loop rather than rebuilt after every timeout.
• Cancellation safety means dropping at any await preserves invariants and documented restart behavior, not that the operation completes cleanup asynchronously.