yoklainterview sim
ProgressHistory

Backend Rs Traits Generics Dispatch Interview Questions

75 verified Backend Rs Traits Generics Dispatch interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Rs Traits Generics DispatchDifficulty 2
use std::fmt::Display;

fn label(flag: bool) -> impl Display {
    if flag { 1 } else { "one" }
}

fn main() {
    println!("{}", label(true));
}

What happens when this is compiled?
  • aIt compiles and prints 1; each branch is checked against Display on its own.
  • bE0308: the if and else branches have incompatible types for the hidden type.✓
  • cE0277: &str does not implement Display, so only the 1 branch is valid.
  • dIt compiles and prints one; the last expression fixes the concrete type.
Explanation:impl Trait in return position is an opaque alias for a single concrete type chosen by the function body. Here one branch yields i32 and the other &str, so the compiler reports E0308 (if and else have incompatible types). Both types implement Display, so E0277 is not the issue. To return different types behind the same interface you need Box<dyn Display> and box each branch.
Rs Traits Generics DispatchDifficulty 1
use std::fmt::Display;

fn show<T: Display>(t: T) -> String {
    format!("<{}>", t)
}

fn main() {
    println!("{}", show(vec![1, 2]));
}

What is the result?
  • aIt prints <[1, 2]> using Vec's Debug output.
  • bE0308: Vec<i32> is not the T the function expects.
  • cE0282: T cannot be inferred from a vec! literal.
  • dE0277: Vec<{integer}> doesn't implement Display.✓
Explanation:Generic bounds are checked at the call site. Vec<T> implements Debug but deliberately not Display (there is no canonical human-readable form), so show(vec![1, 2]) violates T: Display and rustc reports E0277. T itself is inferred fine (no E0282), and there is no type mismatch (no E0308) — the bound is what fails.
Rs Traits Generics DispatchDifficulty 2
trait Task {
    fn run(&self);
}

fn execute(t: dyn Task) {
    t.run();
}

Why does this not compile?
  • aE0277: dyn Task has no compile-time size, so it must sit behind & or Box.✓
  • bIt compiles; t.run() goes through the vtable like any trait-object call.
  • cE0038: Task is not dyn compatible because run takes &self rather than self.
  • dE0308: a trait cannot be a parameter type, only a bound such as T: Task.
Explanation:A trait object dyn Task is unsized: different implementors have different sizes, so a by-value parameter has no fixed stack size. Function parameters must be Sized, hence E0277. Trait objects are always used behind a pointer (&dyn Task, Box<dyn Task>, Rc<dyn Task>). Task itself is perfectly dyn compatible — the &self receiver is exactly what trait objects need.
Rs Traits Generics DispatchDifficulty 1
trait Greet {
    fn name(&self) -> String;
    fn hello(&self) -> String {
        format!("Hello, {}!", self.name())
    }
}
struct A;
impl Greet for A {
    fn name(&self) -> String { "A".into() }
}
struct B;
impl Greet for B {
    fn name(&self) -> String { "B".into() }
    fn hello(&self) -> String { "Hi B".into() }
}

fn main() {
    println!("{} | {}", A.hello(), B.hello());
}

What is printed?
  • aHello, A! | Hello, B!
  • bE0407: B cannot override hello.
  • cHello, A! | Hi B✓
  • dE0046: A is missing hello.
Explanation:A trait method with a body is a default method: implementors may omit it (as A does) or override it (as B does). The default hello calls the required name through self, so A.hello() yields Hello, A!, while B's override returns Hi B. Nothing forces A to implement hello, and nothing forbids B from replacing it.
Rs Traits Generics DispatchDifficulty 1
struct Point { x: i32, y: i32 }

fn main() {
    let p = Point { x: 1, y: 2 };
    println!("{:?}", p);
}

What does the compiler say?
  • aE0277: Point doesn't implement Debug; #[derive(Debug)] fixes it.✓
  • bIt prints Point { x: 1, y: 2 }; {:?} works on any struct.
  • cE0599: no method fmt for Point; call p.fmt() explicitly.
  • dE0308: {:?} expects a String, so p.to_string() is required first.
Explanation:{:?} requires the Debug trait, and user-defined types get no formatting traits automatically. rustc reports E0277 (Point doesn't implement Debug) and suggests #[derive(Debug)], which generates an impl printing Point { x: 1, y: 2 }. Field visibility plays no role, and to_string() would need Display, a different trait.
Rs Traits Generics DispatchDifficulty 2
mod shapes {
    pub trait Area { fn area(&self) -> f64; }
    pub struct Sq(pub f64);
    impl Area for Sq {
        fn area(&self) -> f64 { self.0 * self.0 }
    }
}

fn main() {
    let s = shapes::Sq(2.0);
    println!("{}", s.area());
}

What happens?
  • aIt prints 4; the impl lives next to Sq, so the method is always visible on the type.
  • bE0603: Area is private to shapes and needs pub use before it can be called.
  • cE0277: Sq does not implement Area outside the shapes module.
  • dE0599: no method area found for Sq; the trait must be brought into scope with use.✓
Explanation:Trait methods are only callable when the trait is in scope. The impl exists and Area is pub, but main has not imported it, so method resolution cannot see area and rustc reports E0599, adding the hint that items from traits can only be used if the trait is in scope. A single use shapes::Area; makes it print 4. This is also why use std::io::Write; is needed before calling write_all on a file.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450Rust 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3750-question Backend bank.

Start interview