Denis Defreyne

Weeknotes 2025 W38: Deep dive option

September 15​–​21, 2025

Quick bits:

  • I went through my writing on this web site and fixed a lot of duplicate words all over the the place. They are remarkably easy to miss.

  • Card payments in Germany still aren’t the default. If you don’t say mit Karte, bitte, you could very well end up with a cashier staring at you for an uncomfortably long period of time. And once you do say mit Karte, bitte, then the cashier might start looking around in confusion, desperately trying to remember where the heck they placed the electronic payment terminal.

    Germany in 2025, people.

  • Speaking of money in Germany in 2025: I found a store that accepts cash donations in both EUR and DM currencies. The Deutsche Mark, for the record, has been out of circulation for decades.

  • As I was about to cross a pedestrian intersection (green light for pedestrians), a Porsche accelerated through, racing between the people that had started to cross. When I say traffic in Berlin is deadly, this is what I mean.

  • I ordered specialty coffee online, and it came pre-ground. Pre-ground! Why is there specialty coffee that is being sold pre-ground?!

  • I am not upgrading to macOS Tahoe. Too much Liquid Ass.

  • Aftkr upgradijg to thk latkst vkrsioj of After upgrading to the latest version of macOS Sequoia, my keyboard layout automatically and consistently reverts from Tarmak to QWERTY every time I log in or unlock my macBook. It is infuriating. I’ve got no clue why this started happening.

  • I imported my music library into Doppler. When Time Machine started backing up, it didn’t deduplicate the music in my new music library. Time Machine tried to free up space and deleted all backups except the one from this morning.

    Ahh, Time Machine, how my mistrust in you is validated.

Here is a neat pattern in Zig: errdefer in tests.

An errdefer is executed when there is an error. Assertion failures are errors, and this opens up the possibility of printing extra details that are helpful for debugging a test, but only if and when that test fails.

Here is an example — spot the errdefer disassemble(bytecode):

test "Evaluate simple" {
    const src = "let x = 5;";

    const bytecode = try compile(src);
    errdefer disassemble(bytecode);

    const result = try eval_bytecode(bytecode);
    // ... assert correctness of result ...
}

This test will be intentionally quiet on success, but on error, it will print the disassembled bytecode. Immediately useful!

Ugh — the fucking take-home coding challenges, man… they keep on haunting me.

Every single one of them is a gamble. The evaluation criteria on the interviewers’ side is never clear, and sometimes a total mystery. Going forward, I will ask the interviewers precise questions to learn as much as possible about the evaluation criteria beforehand. A few ideas:

  • How complete does this solution need to be? Interviewer, are you OK with me leaving in TODOs for items that I could not get to within the allocated time, or do you genuinely need the solution to be fully done?

  • How production-ready does this solution need to be? Will you be looking for testing, observability (metrics, logging), documentation, authentication/authorization, rate limiting, style checks, linters?

  • How extensible/flexible do you want my solution to be? In other words: are you looking for a solution that a tight fit for the problem, or a generic solution for a potentially much larger problem?

I know these questions (which will need rephrasing) won’t be enough, but it’s a start. Too often have I made assumptions1 that backfire. Double-checking is always useful.

Some lessons I learnt:

  • Err on the side of over-engineering. A coding challenge is a place to show off your skills rather than build a realistic solution. I suspect that many candidates simply a considerable amount of time showing off in their coding challenge solutions.

    This one is hard for me, because I loathe spending more time than I need to on pointless work that will be thrown away anyway.

  • When providing sample code, make it the intent of the sample code clear. It is a realistic sample, or a sample that intentionally shows the error path?2

After failing my most recent coding challenge, I emailed the recruiter with feedback about my experience with this coding challenge. Was this an entitled thing to do? Maybe. But I hope it reaches people who want to improve the recruitment process, and I hope it makes a difference.

In theatre, auditioning is considered a distinct skill — you can be a great actor and still fail auditions because you don’t have the skill to audition properly.3 Perhaps take-home coding challenges are not too dissimilar, and genuinely need to be treated as a distinct thing in order to succeed.

The often-used argument for coding challenges is fairness: to guarantee fairness, everyone needs to do the coding challenge. But what does this “fairness” give you as an interviewer, exactly?

I believe the “fairness” argument does not hold up,4 and I want to illustrate this by pushing the argumentation to the limit. Imagine that you are interviewing a Rails core team member who wanted to join your company. Would you still give them the coding challenge to write a simple backend service in Rails? If so, what on Earth would you expect to learn from their solution? If they pass the challenge — well, obviously they’d pass the challenge.

And if they fail the challenge… surely that says more about you as an interviewer than about the candidate?

So why give them the challenge in the first place?

My public profile is not nearly as grand as the Rails core team members’. But I have written hundreds of thousands of lines of code across countless repositories, many of them public, some of them rather popular and successful. I’ve put in tens of thousands of hours. Asking me to write some code will yield nothing useful that you can’t glean from my open-source work.5

I know I am coming across as grumpy and perhaps entitled, but I have been doing this sort of work for close to two decades. Being told that you seem to lack real-world experience, or even that you are actually a junior developer, is, frankly, insulting.

I recommend companies provide three options to candidates:

  • A take-home coding challenge — Keeping this as an option makes sense, as some people prefer it.

  • A real-time coding challenge — This would be sitting with an interviewer and doing a coding challenge in person or on a video call. I don’t mind these, actually. These are often quicker, and the interviewer’s decision criteria are much more visible.

  • A technical open-source product deep dive — This would have the candidate elaborate on the thought process and technical design that went into their open-source work. As an interviewer, you get to assess a candidate’s communication skills, which is highly valuable. In addition, as an interviewer you get to spend precious, precious time with a prolific open-source maintainer talking about their work — what is not to love about that?

It’s probably no surprise by this point that I’d go for the technical deep dive option every single time.

Entertainment:

  • I really wanted to like Neyyah,6 but it’s a struggle. The story is hard to follow, but puzzles are sometimes arbitrary.

    I also get lost quickly. Portals are one of the main methods of transportation in the world of Neyyah, but this makes orientation much harder.

    This game also has an overwhelming amount of jargon. I still don’t fully understand what half of the terms mean. Jalood, Banoxi, Holtish, Payeeta, Pinorvia, Pelska, Pelorian, Taleeta, Trondi, Lodvik, Niyelda, Niyashka, etc. I’m lost.

Links:

Tech links:

  1. The most recent coding challenge that I failed was because even though a “proof of concept” was requested, it was deemed to be not production-ready. Of course it isn’t — the request was explicitly for a proof of concept! ↩︎

  2. I failed a recent coding challenge in part because of an unrealistic example. The example was intentionally unrealistic to show a failure case, but the interviewers interpreted it as me lacking real-world experience. Oops. ↩︎

  3. I’ve never auditioned myself, but this is what I’ve heard. Case in point: there are dedicated classes for auditioning. ↩︎

  4. There is something insidious about labelling a process as “fair,” because it allows one to write off any pushback as “making it less fair” — regardless of whether fairness is involved at all. ↩︎

  5. I am saying this, too, because I have been on the other side of the table, interviewing people. Making a candidate with an established body of work go through coding challenge is a waste of time for both parties. ↩︎

  6. Neyyah (Defy Reality Entertainment Pty Ltd, 2025), published by MicroProse Software Pty Ltd. ↩︎

You can reply to this weeknotes entry by email. I’d love to hear your thoughts!
If you like what I write, stick your email address below and subscribe. I send out my weeknotes every Sunday morning. Alternatively, subscribe to the web feed.
Incoming links: