I did LeetCode 2. Yup. That’s the headline. The classic Add Two Numbers.

Submitted my solution thanks to the tremendous help of ChatGPT, but I still feel a bit guilty about it. Afterward, I went down a rabbit hole of trying to convince myself it’s fine not to understand every single detail of every problem on the first pass. Some Reddit comments helped reinforce that idea — learn patterns, don’t memorize solutions.

I agree with that in theory. Which is why I immediately went to watch the NeetCode breakdown on YouTube to actually understand what was going on. I stopped just as the video started playing to write this blabbering. My solution was in Rust, of course, which probably made the whole thing feel more intimidating than it needed to be. But honestly, I don’t think I would’ve fared much better in TypeScript either, so I’m not blaming Rust for this one.

All of this happened in the last two hours.

Earlier in the day, I had been working on something completely different: integrating the HashiCorp Vault Transit Engine for encryption and decryption in an MFA feature I was shipping. The feature was actually complete locally, but we ran into policy configuration issues in dev. That got resolved today, and the frontend team was finally able to integrate it successfully.

Before this, our 2FA system was...let’s just call it creative, in a bad way.

We had two endpoints: /initiate and /validate (Ehn..., tell me about naming conventions 😂☺️). The frontend would call them before allowing users to perform critical actions like withdrawals, transfers etc.

/initiate simply generated a random 6-digit code and stored it in Redis as plain text, keyed by the user’s email. That OTP was then emailed to the user. /validate just compared the input against whatever was in Redis.

If you already think that sounds like an insecure API design, it gets better.

Nothing stopped a malicious user from completely bypassing the whole “2FA flow” and calling the withdrawal endpoint directly. There was no server-side enforcement tying the withdrawal action to a completed 2FA challenge. So effectively, the “2FA” was just client-side theatre. You still needed your PIN and login session, sure — but as far as security layers go, this one was more decorative than functional.

Two years ago, I would’ve been livid that anyone would design it this way. These days, I understand how fast-paced systems can lead to oversights like this. I still don’t see myself making this exact mistake, even when I was a junior, but reality is messy and things slip through.

Since my MFA implementation and some intentional security hardening work across the company, we’ve been closing gaps like this. This particular one is now fixed: every critical action (withdrawals, transfers, etc.) is tied to a scoped MFA session. Meaning an MFA challenge is bound to a specific action and cannot be reused or replayed across different flows.

The frontend and PMs may see it as a “small update,” but any security-conscious backend engineer knows that this is actually a meaningful shift in how trust boundaries are enforced.

On another note, I also had to debug a bug caused by a slightly incorrect use of the dayjs library in a different project.

We had a job that ran roughly like this:

const hasExceededDefaultWindow = dayjs(item.createdAt)
  .isBefore(dayjs().subtract(1, 'day'));

if (hasExceededDefaultWindow) {
  // do something1
} else if (process.env.IS_CHECK_FEATURE_ENABLED === 'true') {
  // carry out check
  // if check is true, do something1 else do nothing
}

The intention was simple:
If item.createdAt is more than 24 hours old, process it immediately. Otherwise, if the feature flag is enabled, run an extra check before deciding what to do.

We had feature-flagged this because even though it had been tested in staging and already deployed, there were still internal reasons to keep the behavior partially disabled in production.

Later, we noticed inconsistent behavior. Some items that were clearly older than 24 hours weren’t being processed. hasExceededDefaultWindow was still evaluating to false, and because the feature flag was also disabled, the fallback logic never ran either. So the job effectively did... nothing.

I’m skipping some surrounding context, but the root cause ended up being subtle behavior around date difference calculations in dayjs.

At one point, the logic was effectively relying on:

dayjs().diff(dayjs(item.createdAt), 'day') > 1

Which actually means:

Only true after more than 1 full day boundary has passed

So in practice:

23 hours → 0
25 hours → 1
48+ hours → 2

Meaning it only becomes true after roughly 48 hours, not 24.

The corrected version is:

const hasExceededDefaultWindow =
  dayjs().diff(dayjs(item.createdAt), 'hour') >= 24;

Or more readable:

const hasExceededDefaultWindow =
  dayjs(item.createdAt).isBefore(dayjs().subtract(1, 'day'));

This didn’t take long to trace — we had Grafana logs showing job execution patterns, so it was fairly quick to isolate. Still, it was one of those “small but annoying” parts of the day.

Now I’ll probably format this properly with ChatGPT, then sleep off while watching NeetCode explain LeetCode 2 again — this time with a little less guilt attached.