I'm working on moving beyond the LeetCode interview for software developers.

Most software engineering interviews are a “signal crisis”. They measure recall, not real-world engineering.

I'm working on moving the evaluation from “writing code under pressure” to technical judgment via structured code review.

https://entrevue.app

I hope you succeed, just to rid the industry of this abomination that is leetcode.

I want to learn how to be bored again.

I also want to learn how to ask better questions.

I didn't realize it was important to be bored until I read/watched this: https://hbr.org/2025/08/you-need-to-be-bored-heres-why. There are some pointers in there that you might find helpful.

One thing that's helped me is solo hikes which I've done many times before. I still do them for workouts and use them as an opportunity to get bored.

These are great. I recently started taking phone holidays, usually on weekends, where for a whole day I don't allow myself to use my phone except to communicate with people.* Sometimes I just wind up bored, sometimes I wind up spending my time better. I've been gradually increasing how frequently I do this.

How would you go about learning to ask better questions?

*Thinking how strange this sentence would sound 20 years ago.

I wonder how teens who already use social media will be affected compared with kids who won’t have accounts until age 16.

If you know your team's velocity, this methodology has worked well for me in the past:

- ask enough questions about the scope of work to do a prototype

- build a prototype to identify constraints / complexity

- ask followup questions

- break the body of work down into a list of tickets (spike/discovery tickets included)

- use the PERT formula to estimate the total number of story points for the body of work

- take the total estimated points and divide by your team velocity for a duration of time (e.g. 100 total points / 40 points per 2 weeks = 2.5 weeks)

In my opinion, pair programming and system design discussions are important in the interview process. Those sessions enable hiring teams to assess how the candidate leverages AI tools to build features, debugs, and thinks about solving system-level problems.

However, I'm convinced the future of technical screening for software developers is to do so with code reviews rather than evaluating solely on code production.

The ability to review code is crucial in our industry. You'll be reviewing code often regardless of who (or what) generated it.

I had no idea, I'll change the name. Thank you for letting me know.

There is something unique about working on a solo project that you usually don't find in traditional software organizations: you can work on something lower priority just because you feel like it.

The sweet spot is when those tasks are complex and it really takes some motivation to get started/keep going.

I'd recommend fostering your curiosity as a mechanism for building momentum and getting stuff done, even if it's not a top priority task.

Do you mind giving some insight into what you like/dislike about the RSS reader you’re using?

This came up at work the other day re: client-side code readability.

In one camp, folks were in favor of component extraction/isolation with self-documenting tests wherever possible.

In the other camp, folks argued that drilling into a multi-file component tree makes the system harder to understand. They favor "locality of behavior".

Our consensus - there needs to be a balance.

Those were exactly my thoughts while reading this article: if your codebase (over)uses inheritance, interfaces, traits, facades, dependency injection etc. etc. to thinly spread any given functionality over several files, no amount of formatting or nice naming is going to save you...