Language Shapes Thought: Why Coding Assessments Undervalue Polyglot Programmers

“Language shapes the way we think, and determines what we can think about.” — Benjamin Lee Whorf

That quote refers to natural languages, but I think it applies just as much to programming.

If your programming language was designed for systems-level work—like C—you probably think in terms of memory and registers. If you use R, statistical thinking feels natural. If you’ve written a lot of Prolog, your mind starts wrapping itself around logic, rules, and deduction. And if you swim in the world of functional programming—SML, F#, OCaml, Clojure—you start thinking in transformations, purity, and recursion.

In other words, programming languages shape the way we think. And when you explore many of them, your mind stretches in powerful, flexible ways.

My Journey Through Languages

I’ve been programming for years—not just because it’s useful, but because I genuinely love it. And when you love something, you explore it deeply and widely.

I started with Pascal, C, and BASIC, then went into dBase III, Clipper, and other xBase dialects. I built GUIs with VB, Visual FoxPro, and Delphi. From there, I moved on to C++, dabbled in Java, had a blast with Python, and jumped headfirst into the web world with JavaScript, PHP, and Ruby.

Then I found Scheme and Clojure, and the world of Lisp blew my mind. That led me into ML, F#, and OCaml — and suddenly, functional programming made everything click in a different way.

I even toyed with Lua, Tcl, Raku, and others along the way. And of course, I learned SQL—a declarative language that reshaped how I think about data, queries, and relationships.

This wide exposure didn’t just teach me syntax. It rewired my thinking. It gave me tools to approach problems from different paradigms. It helped me see trade-offs clearly. It taught me not just how to solve a problem—but to ask, what’s the best way to think about this kind of problem?

But the Hiring Process Doesn’t Reward This Kind of Thinking

Here’s the problem: when it’s time to apply for a job, all of that experience and breadth can feel like a liability.

Why?

Because most coding assessments reward fluency over adaptability. You’re given a timed challenge. No docs. No search. No autocomplete. No room to pause and ask, “Wait, was this the language with implicit returns? Or was that the other one?”

If you’ve specialized in one stack, you fly through. Your muscle memory kicks in. You know every built-in by heart.

But if, like me, you’ve used dozens of languages over time, you hesitate—not because you don’t understand the problem, but because the surface details vary from language to language:

• Was this one eager or lazy?
• Did this support multiple assignment?
• Was the pattern matching syntax this way, or that way?

You find yourself defaulting to a basic “Algol-style” programming model—avoiding idioms, avoiding built-ins—just to be safe. You lose time. You lose the expressive power that normally comes from years of experience. You start second-guessing things you’d normally just look up.

And in a timed test, time is everything.

Fluency vs Adaptability

In tech, fluency often gets mistaken for competence.

If someone can write code fast, rattle off method names from memory, and navigate a familiar stack effortlessly, we assume they’re good. And often, they are—in that narrow domain.

But in reality, the problems we face as engineers rarely stay within the neat boundaries of one framework, language, or library. Technologies evolve. Paradigms shift. Teams change stacks. One day you’re writing REST APIs, the next you’re debugging GraphQL. One quarter you’re in Python, the next it’s TypeScript and React.

So what actually matters in the long run?

It’s not how fast you can type a solution in a language you’ve used for five years. It’s how quickly you can learn, adapt, and apply foundational thinking in unfamiliar territory.

I’ve worked in enough languages to know that the core skills—reasoning about complexity, modeling data, managing state, decomposing problems—transcend syntax. They’re the real transferable skills. And the more paradigms you’ve worked in, the more you can spot patterns others might miss.

The hiring process often ignores this in favor of speed, fluency, and precision under artificial constraints.

But in real engineering, adaptability beats fluency every time—especially in an industry where the only constant is change.

High-Level Thinking vs Low-Level Trivia

Just like programming languages, some environments make you more productive because they let you operate at a higher level of abstraction. You don’t need to deal with manual memory management, imperative loops, resource cleanup, or pointer arithmetic. You describe what you want—the runtime handles the rest.

Languages like Python, Ruby, or Clojure let you think in terms of the problem domain, not the machine. You use map, filter, list comprehensions, or pattern matching to express ideas, not manage mechanics.

That’s how developers should work too.

A good developer doesn’t need to memorize every obscure method or syntax rule. They need to understand the problem deeply, structure a solution well, and know where to find the rest.

That’s why we have documentation. That’s why we have search. That’s why modern tooling exists. Great developers work close to the intent—not buried in trivia.

Memorizing syntax doesn't make someone better. Being able to think clearly and operate at the right conceptual level does.

What Are We Really Valuing?

Maybe this is what frustrates me most.

We say we want engineers who are adaptable, curious, and creative—people who can handle ambiguity, shift paradigms, and think at a high level. But when it comes time to hire, we often filter them out early.

Not because they’re lacking.

But because we’re measuring the wrong things.

We reward speed over depth. Recall over reasoning. Specialization over synthesis.

And the people who’ve spent time learning, exploring, building, and thinking differently—the ones who see problems from surprising angles—are often the ones who struggle to pass a test that reduces software engineering to a timed typing contest.

I don’t think that’s the kind of developer we should be filtering out.

My Strength Is My Weakness — But Only in a Broken System

I’ve come to accept that my curiosity—the same curiosity that drove me to learn so many languages, paradigms, and ways of thinking—might make me slower at syntax recall.

But it also makes me better at:

• Designing systems
• Thinking through edge cases
• Helping others debug across paradigms
• Seeing problems from unexpected angles

Maybe that’s not what coding tests measure.

But perhaps the tests are wrong.

Let’s Rethink What We’re Looking For

We keep saying we want creative engineers.

Let’s build a hiring process that actually finds them.

Let’s look for problem-solvers, not syntax flashcards. Let’s look for adaptability, not just fluency. Let’s look for depth, not just speed.

I might not ace your quiz in 30 minutes.

But give me access to docs and a real-world problem?

I’ll ship.

Because here’s the thing:

Language shapes how we think.

And the more languages you know — natural, declarative, functional, object-oriented — the wider your mental models, the better your tools for thought, and the more flexible your problem-solving becomes.

That’s the kind of thinking companies say they want.

But if your hiring process filters that out…

You’ll never know how good I could have been — because you never gave me the chance.