Du débutant au développeur Rust : plan de préparation à l'entretien

Rust : un langage qui vous fait penser autrement

Vous avez décidé de conquérir Rust. Parfait. Ce n'est pas simplement un autre langage — c'est un défi. Rust brise les schémas auxquels nous sommes habitués en Python, JavaScript ou même C++. Il vous oblige à réfléchir à la mémoire, à la sécurité et à la concurrence à un nouveau niveau.

Un entretien Rust n'est pas un examen de syntaxe. C'est une vérification de votre façon de penser. Les recruteurs veulent voir que vous comprenez la philosophie du langage : ownership, borrowing, lifetimes. Dans cet article, nous analyserons les sujets et questions réels qui vous seront posés, et montrerons des exemples de code qui vous aideront à réussir l'entretien.

Prêt ? C'est parti.

1. Ownership — le fondement indispensable

Le premier et le plus important bloc. Si vous ne comprenez pas l'ownership, vous ne comprenez pas Rust. Lors de l'entretien, on vous demandera certainement d'expliquer comment fonctionne le transfert d'ownership et d'écrire du code qui le démontre.

Règles clés de l'ownership :

\n
• Chaque valeur en Rust a exactement un propriétaire.
\n
• Lorsque le propriétaire sort de la portée, la valeur est supprimée.
\n
• L'ownership peut être transféré (move) ou temporairement prêté (borrow).
\n

Exemple : que produit ce code ?

fn main() {\n    let s1 = String::from("hello");\n    let s2 = s1;\n    println!("{}", s1); // Erreur !\n}

Bonne réponse : erreur de compilation. s1 a été déplacé vers s2, et s1 n'est plus valide. Le recruteur veut entendre que vous comprenez la sémantique de déplacement et pourquoi Rust est si strict à ce sujet.

2. Borrowing et références

Après l'ownership — le borrowing. Comment prendre une référence sans prendre l'ownership ? Et surtout, comment ne pas enfreindre les règles du compilateur.

Règles du borrowing :

\n
• Il peut y avoir un nombre illimité de références immuables (&T).
\n
• Il ne peut y avoir qu'une seule référence mutable (&mut T).
\n
• On ne peut pas avoir simultanément &T et &mut T sur une même valeur.
\n

Exemple : trouver l'erreur

fn main() {\n    let mut s = String::from("hello");\n    let r1 = &s;\n    let r2 = &mut s;\n    println!("{} {}", r1, r2);\n}

Erreur : nous avons créé une référence immuable r1, puis une référence mutable r2. Le compilateur ne le permettra pas. Explication : c'est une protection contre les courses de données (data races) à la compilation.

3. Lifetimes — le sujet qui fait peur à tout le monde

Les lifetimes ne sont pas de la magie. Ce sont des annotations qui aident le compilateur à comprendre combien de temps les références restent valides. Lors de l'entretien, on vous demandera d'expliquer à quoi elles servent et d'écrire une fonction avec des paramètres de lifetime explicites.

Question typique :

Écrivez une fonction qui retourne la chaîne la plus longue parmi deux. Comment spécifiez-vous les lifetimes ?

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {\n    if x.len() > y.len() { x } else { y }\n}

Ici, 'a est une durée de vie commune qui garantit que la référence retournée sera valide tant que les deux références d'entrée sont valides. Le recruteur appréciera si vous mentionnez l'élision de durée de vie (lifetime elision) — lorsque Rust déduit lui-même les lifetimes pour les cas simples.

4. Enums et Pattern Matching — la force de Rust

Rust n'a pas de null. À la place, il utilise Option<T> et Result<T, E>. Lors de l'entretien, on vous demandera d'écrire une gestion d'erreurs en utilisant match.

Exemple : division sécurisée

fn safe_divide(a: f64, b: f64) -> Option<f64> {\n    if b == 0.0 { None } else { Some(a / b) }\n}\n\nfn main() {\n    match safe_divide(10.0, 0.0) {\n        Some(result) => println!("Résultat : {}", result),\n        None => println!("Impossible de diviser par zéro"),\n    }\n}

Montrez