Remember: Don’t Mention Rust During Interviews

Today I want to write something beyond tech. I want to talk about psychology and humanity in tech, about the unspoken social dynamics that often matter more than our technical skills. There’s an unwritten rule circulating among experienced developers: Don’t mention Rust in a non-Rust team during interviews. At first glance, this seems absurd. Why would discussing a modern, safe systems language be a problem? Yet from my experience, this advice touches on a deeper psychological phenomenon that affects technical interviews across the industry. I’ve paid several lessons learning this the hard way, and each one cost me opportunities I thought I had in the bag.

The Pattern Recognition Game

I’ve sat on both sides of the technical interview table enough times to recognize what happens when someone mentions Rust to a Python or TypeScript team. The interviewer’s posture shifts slightly. There’s a pause. Something changes in the room, and it’s not about the technical merits of the language.

What’s happening is pattern matching. The interviewer isn’t just hearing about a programming language — they’re matching you against a stereotype they’ve encountered before. Cognitive psychologists call this “availability bias,” the tendency to rely on immediate examples that come to mind. And many technical leads have war stories about the engineer who wanted to rewrite perfectly functional services in Rust, often with minimal understanding of the team’s actual constraints, deployment pipelines, or business priorities.

When you mention Rust unprompted, you risk triggering this mental association before you’ve had a chance to demonstrate your actual judgment. You’ve become “that Rust person” in their mind, and now you’re playing defense for the rest of the interview.  The Threat Response in Python/TypeScript Teams

I used to think the fear reaction from dynamically-typed language teams was irrational, but I’ve come to understand it’s actually protective. These teams chose their stack for specific reasons — development velocity, ecosystem maturity, hiring pipeline, or simply organizational momentum. When a candidate brings up Rust without prompting, the interviewer’s mind starts racing through anxiety-inducing scenarios.

“Will this person constantly advocate for unnecessary rewrites?” Technical debt is real, but so is the opportunity cost of chasing the perfect technology stack. I’ve watched teams lose months to rewrites that delivered marginal improvements at best. Teams need builders who can ship features with the tools at hand, not philosophers who debate the ideal tooling.

“Will we be able to have pragmatic technical discussions?” The worst-case scenario for any team is hiring someone who turns every technical decision into an ideological battle. I’ve been in those meetings where choosing a library becomes a two-hour debate about type systems and memory safety. It’s exhausting, and it kills momentum.

“Are they more interested in their resume than our problems?” There’s a legitimate concern that candidates who emphasize trendy technologies are optimizing for their next job rather than excelling at this one. Rust has become a “resume-driven development” red flag, fairly or not. I’ve seen engineers push for Rust adoption not because it solved a real problem, but because they wanted that experience on their LinkedIn.

This isn’t about Rust being bad. I actually think it’s a brilliant language for certain use cases. But technology choices exist within complex organizational contexts, and failing to acknowledge that reveals something worrying about how you approach problems.

Why Go Teams React a Bit Differently

The implicit laughter from Go teams represents a different psychological dynamic entirely. I’ve been in those rooms too, and I recognize the social dance happening beneath the surface.

Go and Rust occupy adjacent niches — both are compiled, performance-oriented languages that compete for similar use cases. Go teams often chose their language deliberately over Rust, typically valuing simplicity, fast compilation, and a gentler learning curve over Rust’s memory safety guarantees. They’ve had this conversation before, probably many times.

When you mention Rust to a Go team, you’re inadvertently suggesting their choice might have been wrong. The laughter is a defense mechanism, a way to dismiss the implied criticism without engaging in a potentially uncomfortable technical debate. It’s the social equivalent of “we’ve heard this song and dance before, and we’re confident in our decision.”

There’s also an element of intellectual status signaling at play. Within certain technical communities, Rust carries connotations of being “more hardcore” or “more technically sophisticated.” The borrow checker is seen as a rite of passage, a proving ground for serious engineers. Go developers — many of whom deliberately chose simplicity — can interpret Rust evangelism as condescension disguised as technical discussion. Like someone showing up to a carpentry workshop and suggesting everyone should really be using hand-forged Japanese chisels.

The Deeper Issue: Demonstrating Judgment vs. Knowledge

I’ve come to realize the real problem isn’t mentioning any specific technology. It’s failing to demonstrate the kind of judgment that separates effective engineers from those who chase technical novelty.

Strong engineers demonstrate contextual thinking. They ask about the team’s current challenges before proposing solutions. They show curiosity about why existing choices were made. They recognize that the “best” technology is the one that solves the actual problem within real-world constraints — budget, timeline, team expertise, operational capabilities, risk tolerance.

When you mention Rust (or any technology stack different from what’s advertised) without first understanding the context, you’re signaling that you might lack this crucial judgment. You’re leading with the solution before understanding the problem. It’s like a doctor prescribing medication before examining the patient.

I learned this the hard way early in my career. I walked into an interview and spent fifteen minutes explaining why the company should adopt reactive programming patterns. The interviewer nodded politely, let me finish, then asked, “But do you understand why we built it the way we did?” I didn’t. I hadn’t asked. I’d failed the real test, which wasn’t about technical knowledge but about professional maturity.

The Paradox of Expertise

Here’s the irony that took me years to appreciate: truly experienced engineers often have strong opinions about technologies, including legitimate criticisms of languages they work with daily. I complain about Python’s performance characteristics and TypeScript’s type gymnastics all the time. But I’ve learned to calibrate my communication based on social context.

Interviews are fundamentally about trust-building, not technical debates. The interviewer needs to believe you’ll be collaborative, pragmatic, and focused on team success. Technical correctness matters less than demonstrating that you’re someone they want to work alongside for the next few years. Someone who makes their job easier, not harder.

This is why the advice “don’t mention Rust” works — not because Rust is problematic, but because it’s become a shibboleth for a particular type of engineer who may prioritize technical purity over practical delivery. Fair or not, you’re being judged on your ability to read the room and contribute positively to team dynamics.

What I Do Instead

The solution isn’t to hide your knowledge or enthusiasm. I still get excited about new technologies and love discussing trade-offs. But I’ve learned to demonstrate strategic thinking about technology choices rather than just technical enthusiasm.

I follow conversational leads now. If the interviewer asks about other languages I’m interested in, that’s my opening. Context matters. Invited opinions land differently than unsolicited ones. When they ask “what technologies are you excited about?” I might mention Rust, but I frame it as a learning journey rather than an implicit criticism of their stack.

I show systems thinking when I do discuss alternatives. Instead of “we should use Rust,” I’ll say something like “I’ve been learning Rust and find its ownership model fascinating for concurrent systems, though I recognize the learning curve and compilation times can be dealbreakers for rapid iteration.” This demonstrates that I understand trade-offs exist and that perfect solutions don’t.

I ask before advocating. “What drove the decision to use Python for this service?” shows respect for existing context and creates space for nuanced discussion. Often I learn something valuable — maybe they tried Go first and ran into specific issues, or they inherited the codebase from an acquisition. That context completely changes the conversation.

I demonstrate polyglot pragmatism. “I believe in using the right tool for the job — I’ve shipped production code in Python, Go, and TypeScript because each had specific advantages for those problems” signals that I’m not married to any particular technology. I’m married to solving problems effectively.

The Meta-Lesson

This phenomenon extends far beyond Rust. I’ve watched it happen with Kubernetes in teams running monolithic deployments, with microservices in teams running monoliths, with functional programming in imperative codebases, with GraphQL in REST API shops.

The pattern is always the same: leading with a solution before understanding the context signals poor judgment, regardless of how technically correct you might be. And interviews are ultimately judgment tests disguised as technical assessments.

The engineers who succeed aren’t necessarily the ones with the deepest technical knowledge or the strongest opinions. I’ve watched brilliant engineers struggle to find jobs because they couldn’t read the room. Meanwhile, I’ve seen decent engineers with good social calibration land roles at top companies. They’re the ones who can build trust, apply their expertise within the messy reality of organizational constraints, and make the people around them better.

So yes, maybe don’t mention Rust in a non-Rust interview — not because Rust is bad (it’s genuinely excellent for certain problems), but because you have more important things to demonstrate first. Like the fact that you understand when to mention Rust, and more importantly, when not to.

That kind of judgment is harder to teach than any programming language, and it’s exactly what interviewers are looking for, even if they don’t always articulate it that way.