Forem: Jota Feldmann

The Legend, the Problem, and "Shock! Shock!"

Jota Feldmann — Sat, 07 Mar 2026 03:18:03 +0000

Who is Donald Knuth?

Donald Knuth is, without exaggeration, one of the most important figures in the history of computer science. He wrote The Art of Computer Programming — a multi-volume series that has sat on the desk of nearly every serious programmer for the past fifty years. He won the Turing Award, which is the Nobel Prize of computing. He invented TeX, the typesetting system that scientists around the world still use to write papers and format equations.

If you're a developer, you've used his work today without knowing it. That sorting algorithm you called in one line of code? The analysis explaining why it's fast or slow? The mathematical notation in the documentation? Knuth is in the foundation of all of it. He's 88 years old, still active, and considered by many to be the greatest living mind in the field.

The Problem — and Why It Matters

Imagine a three-dimensional grid of dots — think of it like a Rubik's cube, but instead of colored stickers, every dot is connected to exactly three neighbors by wires. Now the question: can you trace three separate routes through this grid so that each route visits every single dot exactly once and returns to where it started — and the three routes never share the same wire?

This kind of path — one that visits every point in a network exactly once — is called a Hamiltonian cycle. It shows up everywhere in practical problems: optimizing delivery routes, designing efficient circuits, scheduling tasks with complex dependencies, planning network infrastructure. The challenge isn't just solving it for one specific grid. It's finding a general recipe that works for any size.

Knuth solved it by hand for a small 3×3×3 grid. A collaborator used a computer to find solutions for grids up to size 16. But a universal construction — a formula that provably works for every odd size forever — had never been found. The number of possibilities grows so explosively that brute-force search is simply not an option, even on the fastest computers alive.

"Shock! Shock!"

Those are the first two words of a paper Knuth published this week.
Let that sink in. A man who has spent decades at the absolute frontier of mathematical thinking, who has seen computing go from punch cards to neural networks, who has written the books that define the field — chose to open a scientific paper with those words.

Why? Because Claude, Anthropic's AI model, found the general construction that no one else had.

It didn't happen in a flash of machine brilliance. It happened over 31 iterations that looked remarkably like real research: early attempts with simple formulas failed; brute-force search proved unworkable; a promising approach inspired by Gray codes (a technique for navigating ordered sequences) got partway there but stalled; decompositions by "slices" of the grid were tried; randomized simulations with controlled backtracking were explored.
On the 31st attempt, something clicked. Claude found a small set of simple directional rules — based on each dot's position in the grid — that generate all three complete cycles. It tested the construction for multiple grid sizes. It worked every time.
Then came the human part.

Claude found the recipe. Knuth wrote the proof — the rigorous mathematical argument for why the recipe works, why it will always work, with no exceptions. Without that step, it's a well-supported hypothesis. With it, it's mathematics.

This kind of problem — finding paths that visit every point in a network — is considered fundamentally hard in computer science. No general shortcut is known to exist.

What changed here isn't that AI "solved everything." It's that it managed to see a hidden structure inside an enormous space of possibilities, and delivered a construction with real mathematical logic — not just a lucky numerical result.

The division of labor that emerged naturally — AI explores, human proves — may be a powerful model for mathematical research going forward.

Knuth published the paper this week, you can read it at https://www-cs-faculty.stanford.edu/~knuth/papers/claude-cycles.pdf

AI Fair usage: Written with Claude, revised with Grammarly. Thinking is still mine.

Adapting Technical Interviews to Counter AI-Assisted Cheating

Jota Feldmann — Sat, 31 May 2025 03:05:29 +0000

I've been hiring developers for over 10 years—initially as a senior engineer, and for the last two years, as a dedicated technical recruiter. During that time, I’ve reviewed dozens of take-home projects, attended numerous whiteboard sessions, and observed the evolution of interview trends.

But lately, something’s changed.

Candidates are using AI tools like ChatGPT and GitHub Copilot to pass technical interviews, often in ways that bypass actual engineering judgment. I’m not against AI—it's a powerful tool when used responsibly. But when it's used to mask a candidate’s true skill level, it undermines the purpose of technical hiring.

This article outlines some practical strategies and observations I’ve developed to help design interviews that are fairer, more insightful, and harder to game with AI.

Personalize the Problem

Generic problems are the easiest to solve with AI. So I’ve started giving contextual, personalized exercises that reflect challenges from our actual codebase or systems.

For example:

“Here’s a simplified version of our logging system. We recently had issues with performance under load. What would you change, and why?”

This forces the candidate to think beyond “just code” and engage with the problem like an engineer, not a copy-paste operator.

Use Live, Interactive Interviews

Cheating is harder when someone’s watching. I run most coding interviews live, using platforms like CoderPad or VSCode Live Share. Cameras on, code shared, and I ask candidates to think out loud as they work.

This reveals so much more than a finished solution. I’m not just hiring for correct syntax—I’m looking for how they reason, debug, and adjust when they hit a wall.

Focus on Thought Process Over Output

I’ve learned to push beyond the “Did it run?” mindset. Instead, I ask:

Why did you choose that approach?
What’s the trade-off of doing it this way?
What would break if the data doubled?

AI can give you an answer. It can’t (yet) explain why that answer matters in context.

Break Challenges into Timed Parts

Rather than one long take-home, I now use multi-part, timed challenges during live sessions. For example:

Part 1: Quick algorithm
Part 2: Real-world refactor
Part 3: Code review or optimization

I tell them upfront: “You probably won’t finish it all.” That’s the point. I’m looking at how they prioritize, communicate, and think under fair pressure, not just what they ship.

Add a Bit of Ambiguity

Real-world specs are rarely perfect, so I sometimes leave edge cases open-ended. I want to see:

Do they ask clarifying questions?
Do they make smart assumptions?
Do they catch corner cases without prompting?

This is where junior devs and senior engineers start to show their differences.

Ask Open-Ended, Non-Code Questions

I’ve also added open-ended discussions into my process. Things like:

“How would you design a feature to reduce backend load?”
“How would you onboard a junior into a legacy system?”
“How do you approach technical debt?”

These are the kinds of questions you can’t just Google or AI your way through—they demand real experience and opinions.

Set Boundaries on AI Use

For take-home assignments, I now include a clear statement:

“This test must be completed without the assistance of AI tools such as ChatGPT, Copilot, or similar.”

Is it foolproof? No. But it sets the tone—and the ethical candidates take it seriously.

I’m not trying to “catch” candidates using AI. I’m trying to design a process where genuine skill and thought shine through, regardless of whether a candidate has ChatGPT open in another tab. AI is changing the game, and as interviewers, we need to adapt—not by being punitive, but by being thoughtful.

AI is here to stay, I believe it is a human extension (Iron Man), not to replace developers (Androids). However, you need to be the best you can be with the tool; not to mention that people trust individuals to handle ethics.

If you're a fellow tech hirer seeing similar patterns, I hope these ideas help you refine your process.

Let’s keep interviews human—and fair.

AI usage:

Chat-GPT for the cover image
Grammarly for final redaction

How a Math Breakthrough Can Help Us Build Better Software: A COMMON Developer's Guide to Williams' Time-Space Insight

Jota Feldmann — Sat, 24 May 2025 18:38:31 +0000

As a common software developer with experience in common commercial software (what I call "real world software"), especially in startup settings, I constantly fight resource constraints: memory, compute, and cost.

Recently, I stumbled on something from the academic world that might actually matter to us, common craftsmanship developers in the trenches: a breakthrough by MIT's Ryan Williams. No, it's not some abstract math proof for theorists only. It's a real insight with potential real-world impact on how we write memory-efficient code.

What caught my eye was: "One computer scientist’s 'stunning' proof is the first progress in 50 years on one of the most famous questions in computer science."

WOW.

The core idea is:

You don’t always need linear space to finish a task efficiently.

It took me some time to understand the context of linear space here (thanks Chat-GPT), but essentially, it's this: the memory you need to use to be faster is equal to the input.

If you have 1 million records, you’re expected to use 1 million “slots” in memory to process them efficiently. That’s linear space — one-to-one. More data? More memory. No questions asked.

It’s like trying to be the fastest at checking every name on a list, so you write all of them on sticky notes and plaster them on your walls. Sure, you can find anyone instantly, but now your house is full of notes and you can’t find your cat.

Williams comes along and says:

“Hey… what if we just remembered the important parts, and recomputed the rest when we need it? You’d use fewer sticky notes — and your cat would thank you.”

Before, computer scientists used to believe that:

To run an algorithm efficiently, you needed memory roughly proportional to the size of the input — linear space.

In essence, it sounds obvious: more data means you need more memory to handle it well. Like saying, “If I want to cook for 100 people, I need 100 plates.”

But now, thanks to Ryan Williams, we have proof that this isn’t always true.

Turns out, with the right approach, you can sometimes cook for 100 people using just 10 plates — you just wash and reuse them fast enough that no one notices.

In algorithm terms: you simulate the same result, using way less memory, maybe with a bit more time or clever recomputation. It's not magic. It's just a smarter use of resources — and now it's mathematically backed.

A Kind of Real World Simple Example: Finding the Maximum Value in a List

Let’s say you’re finding the maximum number in a list. Most developers know two ways to do this.

Before (How We Typically Think)

# Load everything in memory
nums = [int(line) for line in open("data.txt")]
max_val = max(nums)

Time: O(n)
Space: O(n)

You load all the numbers into memory, then call max(). Fast and simple, but memory-heavy.

Williams-Inspired Interpretation

Instead of storing everything, why not just keep track of the max as you go?

max_val = float('-inf')
for line in open("data.txt"):
    num = int(line)
    if num > max_val:
        max_val = num

Time: O(n)
Space: O(1)

This simulates the same behavior with way less memory, and its not that slow how we used to think before.

MORE Real World Example: Building a Search Engine

Let’s say you’re building a support dashboard or knowledge base search tool. Normally, you’d build an inverted index like Elasticsearch or Lucene:

Before: Traditional Inverted Index

inverted_index = {}
for doc_id, content in enumerate(docs):
    for word in content.split():
        inverted_index.setdefault(word, set()).add(doc_id)

Time: Fast lookups
Space: O(n) to store the index

This is memory-heavy. If you have millions of documents, the index might not fit on smaller machines or edge devices.

After: Williams-Inspired Interpretation

What if we simulate the index instead of storing it entirely? We could use space-efficient structures like Bloom Filters or sketches:

class BloomFilter:
    def __init__(self, size=10000):
        self.size = size
        self.bits = [0] * size

    def add(self, word):
        for h in self._hashes(word):
            self.bits[h] = 1

    def contains(self, word):
        return all(self.bits[h] for h in self._hashes(word))

Each document gets a small filter. At search time, instead of querying a big inverted index, you check which filters "probably" contain your words. You trade exactness for space, but still get fast, usable search.

My two cents: personal insight while digging into this

What really clicked for me while exploring this idea wasn’t just the resource savings — though that’s cool. It was how this way of thinking led me to design software differently.

Instead of just asking “How do I load everything and go fast?”, I started thinking in units of work — batches, chunks, steps. Suddenly, I was building systems that naturally scale better, are easier to retry, and recover more gracefully from failures.

You’re not just writing smarter algorithms — you’re architecting smarter systems and NOW YOU CAN JUSTIFY THAT IS NOT THAT SLOW HOW WE USED TO BELIEVE!

Memory limits become design constraints that actually make your software more resilient.

It’s weird: a theory paper ended up helping me in the system design.

Final Thoughts: Why You Should Care

If you're building for constrained environments or just want more efficient systems, Ryan Williams' result gives you permission to rethink the memory/time trade-offs in your architecture. It’s not just theory — it’s a mindset shift.

And mindset shifts can lead to big wins in the world of startups and real-world software.

Update: I removed a Fibonnaci example that is not the best explanation in this case.

AI Usage:

To understand the "linear space" concept
The cover image
Grammarly for text correction

A brief history of tech interviews

Jota Feldmann — Wed, 05 Feb 2025 18:28:02 +0000

Since I've been doing tech interviews for 10+ years and professionally for 2, I decided to look for previous work in that area.

It's a common topic for tech professionals, but finding material is difficult.

This post intends to start a series about this topic.

Let's start with a small recap AFAIK:

Early Days (1950s-1970s) The Birth of Computing & Hiring Engineers

Companies like IBM, Bell Labs, and Xerox PARC were pioneers in hiring computer scientists.

Interviews were academic in nature, focusing on logic, mathematics, and electrical engineering principles.

Hiring was often referral-based, with informal questioning rather than structured interviews.

Many interviewers were scientists and engineers rather than dedicated HR professionals.

1980s-1990s: The Rise of Silicon Valley & Algorithmic Interviews

The rise of companies like Microsoft, Apple, and Sun Microsystems brought more structured hiring processes.

Microsoft famously introduced puzzle-based interviews, testing problem-solving skills.

Whiteboard coding and algorithm-heavy interviews became the standard, with books like Programming Pearls influencing interview techniques.

Dedicated technical recruiters and specialist interviewers emerged, distinct from hiring managers.

2000s: Google’s Influence & Standardization of Coding Interviews

Google revolutionized hiring by implementing data-driven hiring and rigorous coding interviews.

LeetCode-style algorithmic questions and system design interviews became industry norms.

Behavioral interviews like "Googleyness" checks were introduced to assess cultural fit.

Many companies adopted bar-raiser programs (inspired by Amazon), where trained interviewers had veto power over hiring decisions.

2010s: Remote Interviews, AI Assessments, & Diversity Efforts

The rise of remote interviews with tools like CoderPad, CodeSignal, and online assessments.

AI-powered resume screening and technical assessments became common.

Companies focused on reducing bias in interviews, incorporating structured rubrics and blind hiring practices.

Pair programming interviews and take-home projects grew in popularity.

2020s-Present: AI and Vibe Coding

AI-assisted interviews (e.g., AI grading coding challenges) and machine learning to predict candidate success.

Shift away from pure algorithmic interviews toward real-world problem-solving and system design.

Live coding interviews and asynchronous video interviews continue to evolve.

Sources

Converting a Node project to Deno

Jota Feldmann — Wed, 13 May 2020 06:15:23 +0000

I was intrigued to test Ryan Dhal's Deno and nothing better than some personal project to make it right.

Some important stuff before:

Remove all NPM files and node_modules

You don't need anything more than Deno, but some tasks will be converted to some Deno "out of the box" command (e.g. deno test), and for others, I'll use a Makefile for convenience.

Remove package.json, package-lock.json, and all related stuff. Check this file for all NPM possibilities: https://github.com/github/gitignore/blob/master/Node.gitignore
Remove node_modules

Add file extensions to imports

Add .ts to all import statements.

One easy way using VS Code "search and replace":

Enable regex
For Search field use from (.+?)(?=.ts')
For Replace field use from $1.ts

Fix parser warnings and adapt the logic

Deno uses strict guidelines using the TypeScript and style guide. It includes some logical/code adaptations.

Optional: convert tests and test task

Short version: https://github.com/denoland/deno/blob/master/docs/testing.md
Follow the "out of the box" test suite https://deno.land/std/testing
Convert from npm test to something like:

# Optional Makefile for convenience
test:
    deno test

Convert install task and add the first dependency

Forget npm install. You can use dep.ts, but it's not required. I'm using a Makefile to keep track of all dependencies:

# Optional Makefile for convenience
install:
    deno install --unstable --allow-read --allow-run -f https://deno.land/x/denon/denon.ts;

Convert run and dev tasks (with Denon)

Here I'm using Denon module, the Nodemon for Deno, to watch and reload file changes.

# Optional Makefile for convenience
dev:
    denon $(ENTRY_POINT)
run:
    deno run $(ENTRY_POINT)

Set entry point

Change the entry point file name from index.ts to mod.ts Deno/Rust standard.

Use my project as a template

All these steps are documented on my project: https://github.com/jotafeldmann/elevators/pull/1

Enjoy and, please, send me feedback to improve.

Uncached Go tests: avoid flaky tests

Jota Feldmann — Thu, 27 Feb 2020 21:25:42 +0000

So, crazy about your integration tests with Go?

I was totally crazy testing my endpoints, and, for hours, I didn't know why some tests were flaky in my CI environment.

But since Go 1.10 tests are cached.

To avoid cache, you can use:

go test -count=1

Thanks @marciorodrigues and that issue.

A tricky Python default argument

Jota Feldmann — Sat, 15 Feb 2020 22:34:55 +0000

Check the following code:

def append(l=[]):
  l.append(1)
  return l

In my opinion, we have a problematic mutator function, but for the purpose of this article, just focus on the default argument/parameter. What's wrong?

def append(l=[]):
  l.append(1)
  return l

print(append())
# [1]
print(append())
# [1,1]

Here's the tricky default parameter: any object (list, map, etc) will be instantiate and will live in the memory for the rest of the function's life!

IMHO it's problematic behavior, different from any other language, like Java or JavaScript. Ok, it's cool when you can work with dependency injection because once set, it will never be instantiated again. But in common use, you can forget that default parameter and have practical side-effects. Example: in unitary tests (my reason to write that article).

To avoid that stuff, you can check and instantiate every time, at the beginning of the function:

def immutableAppend(l=None):
  l = [] if l is None else l
  l.append(1)
  return l

print(immutableAppend())
# [1]
print(immutableAppend())
# [1]

This gotcha leads me to the great Python Guide, which first gotcha is exactly this behavior. And one more reason to read all Python doc, again 😞 (search for "Important warning: The default value is evaluated only once").

You can test it on https://repl.it/@jotafeldmann/trickyDefaultArgument

You become responsible, forever, for what you have published on NPM

Jota Feldmann — Thu, 30 Jan 2020 04:54:06 +0000

You become responsible, forever, for what you have tamed.
― Antoine de Saint-Exupéry, The Little Prince

I was checking for my old small codes, looking for some good projects to apply tests and improve my skills.

Suddenly I remembered that some of them were published on NPM, just for fun, to my own use. And then, in that small right area, which I've used so many times before to analyze packages, my eyes became bright: most of my packages have about 6 to 24 downloads/week!

I was shocked! Somebody, out there, in the ocean of the open-source, is really using my humble chunks of code...

After minutes of self-admiration, one thing became clear: I was responsible, somehow, for the code of the others. Never, in my 20 years of coding, this kind of responsibility crashed over me.

One thing is to code to the production environment of software you're paid to execute; another is ship some silly code and somebody, not your fellas or company, start to use your package. Weekly.

So, I've decided to improve all of them. Version, tests, good documentation, better code. Even knowing my published codes was simple, the need for some baseline overwhelm my shoulders and became a duty.

And now, 20 years after my first code, I can feel what open source can be. It's not just "contributing back" but become responsible for the others, raising the bar, as I think those same guys do in the all-stared repositories.

...

So, for you out there, using my code: thanks a lot. And one lesson learned: open source out your ideas, maybe somebody can find it useful.

Tricky async declarations

Jota Feldmann — Thu, 16 Jan 2020 22:39:23 +0000

Imagine the following code, using Express and Sequelize:

app.get('/', async (_, res) => {
  const result = await sequelizeModel.getStuff()[0]
  return res.status(200).send(result)
}

In simple words: given an endpoint, it will execute a query on the database and return the result.

But there's a small gotcha: that code works but doesn't return the results, because at the time of the promise creation, the [0] is not available/ready.

Only after the promise/async is fulfilled, the Sequelize object exists.

Working code:

app.get('/', async (_, res) => {
  const result = await sequelizeModel.getStuff()
  return res.status(200).send(result[0])
}