Coding Fundamentals

String vs &str vs Cow

use std::borrow::Cow;

// Returns borrowed if no replacement needed, owned if replacement happened.
fn redact_email(s: &str) -> Cow<'_, str> {
    if !s.contains('@') {
        Cow::Borrowed(s)
    } else {
        Cow::Owned(s.replace(|c: char| c.is_alphanumeric(), "*"))
    }
}

Interview test: someone hands you fn parse(s: String) as an API. Senior answer: "Take &str unless you're storing it." Strings should usually be borrowed at API boundaries.

Box, Rc, Arc

Default in service code: Arc<T> for shared state across tasks. Box<T> for trait objects and recursive types. Rc<T> is rare in service code (single-threaded scenarios only).

Async cancellation

Three things to know cold:

1. Cancellation = drop. When you drop a future, its in-flight work stops at the next .await point. Resources owned by the future are released by destructors.
2. Cancellation is cooperative. If a task is CPU-spinning without awaits, you can't cancel it. The fix is yielding, or moving the work to spawn_blocking.
3. Cancel-safety is a property of a future: can it be cancelled mid-execution without leaving state corrupted? tokio::select! docs flag which futures are cancel-safe; mpsc::Receiver::recv is, but broadcast::Receiver::recv is not (you may lose a message).

use tokio::select;
use tokio_util::sync::CancellationToken;

async fn work(token: CancellationToken) {
    let mut interval = tokio::time::interval(std::time::Duration::from_secs(1));
    loop {
        select! {
            _ = token.cancelled() => { break; }   // cooperative cancel
            _ = interval.tick()   => { do_step().await; }
        }
    }
    cleanup().await; // runs after cancel
}

Channel patterns interviewers love

Request-reply with oneshot

use tokio::sync::{mpsc, oneshot};

enum Req { Compute { input: u64, reply: oneshot::Sender<u64> } }

let (tx, mut rx) = mpsc::channel::<Req>(64);

tokio::spawn(async move {
    while let Some(Req::Compute { input, reply }) = rx.recv().await {
        let _ = reply.send(input * 2);
    }
});

let (rtx, rrx) = oneshot::channel();
tx.send(Req::Compute { input: 21, reply: rtx }).await.ok();
let answer = rrx.await.unwrap(); // 42

Fan-out with broadcast

Many tasks subscribe; each gets a copy of every message. Late subscribers miss prior messages.

Worker pool with bounded mpsc

One channel feeds N worker tasks. The bounded capacity provides backpressure.

let (tx, rx) = tokio::sync::mpsc::channel::<Job>(1024);
let rx = std::sync::Arc::new(tokio::sync::Mutex::new(rx));

for _ in 0..16 {
    let rx = rx.clone();
    tokio::spawn(async move {
        loop {
            let job = { rx.lock().await.recv().await };
            match job {
                Some(j) => process(j).await,
                None    => break, // channel closed
            }
        }
    });
}

Note: a single shared Mutex<Receiver> is the simple form. For higher throughput, give each worker its own receiver via cloning, or use a work-stealing crate.

Error type design

For library or service code (where callers branch on errors), define an enum with thiserror:

• One variant per failure mode the caller might handle differently.
• Include #[from] for source errors that should propagate transparently via ?.
• Add retryable: bool on transient variants. Or use a method fn is_retryable(&self) -> bool.
• Don't expose internal panics — convert them at the boundary.

#[derive(thiserror::Error, Debug)]
pub enum ToolError {
    #[error("tool not found: {0}")]
    NotFound(String),
    #[error("schema validation failed: {0}")]
    InvalidArgs(String),
    #[error("unauthorized: user {user} cannot call {tool}")]
    Unauthorized { user: String, tool: String },
    #[error("upstream error: {0}")]
    Upstream(#[source] BackendError),
    #[error("timeout after {0:?}")]
    Timeout(std::time::Duration),
}

impl ToolError {
    pub fn is_retryable(&self) -> bool {
        matches!(self, ToolError::Upstream(_) | ToolError::Timeout(_))
    }
}

Trait objects vs generics

When you need polymorphism:

For a tool registry (heterogeneous, runtime-known set), Box<dyn Tool> is right. For a generic worker that processes one type at a time, generics are right.

DSA — the suite you must know cold

Live coding rounds for Rust infra roles are typically not LeetCode-heavy, but you should be fluent in:

For an AI-infra interview specifically, expect at least one of: rate limiting, LRU cache, retry-with-backoff, request coalescing. Those are in 11.

Concurrency primitives

Beyond channels and mutexes, know:

• Semaphore — bound concurrent operations. tokio::sync::Semaphore.
• Notify — single-producer, single-consumer "something happened" signal.
• Barrier — wait until N tasks reach a point.
• JoinSet — spawn N tasks, await any/all.
• Atomics — AtomicU64, AtomicBool, etc. Use Ordering::Relaxed for counters, Acquire/Release for cross-thread synchronization.
• arc-swap — atomic Arc swap. Great for "config you can hot-reload."
• dashmap — sharded concurrent hashmap.
• parking_lot — faster, smaller Mutex/RwLock for sync contexts.

Big-O cheat sheet for Rust collections

Defaults: HashMap for general key-value (uses SipHash; switch to ahash/fxhash in perf-sensitive code). BTreeMap when you need sorted iteration or range queries. Vec for everything sequenced.