fs_software

I've been building a platform for code review-based interviews.

Was going to post "Show HN" but the guidelines say blog posts / sign up pages should be a regular post. Since I'm running a pilot (just trying to learn and iterate) the platform is invite only. So I guess this is both a blog post and a sign up page for folks interested in trying it out.

Just me working on this on nights and weekends for now. Open to feedback!

> Any misfortune ‘that lies outside the sphere of choice’ should be considered an opportunity to strengthen our resolve, not an excuse to weaken it.

This is an interesting perspective that I've practiced but haven't explicitly considered before.

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 want to learn how to be bored again.

I also want to learn how to ask better questions.

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.

I've been building a simple RSS feed reader just for the purpose of taking back control of my attention. It allows me to subscribe to my favorite youtube channels, reddit threads, HN, etc. The best part is I can mute feeds and catch up later without the pressure of consumption. I've used it daily for years and don't anticipate going back to social media any time soon.

https://feedme.digital

I wonder the rate of which like-minded senior leadership is growing in our industry.

If this mindset spreads enough we will probably see many major software issues playing out in our day-to-day lives.

Some observations:

- This might lead to the job security / market pendulum swing in favor of software developers that we seem to have lost recently. Companies might start paying a premium for those of us who can debug LLM code and get businesses back on track.

- There may unfortunately be a disaster resulting in the loss of life that leads to the introduction of strict regulations on our industry (sure hope not).

Curious what others think.

> We need more builders, not fewer. Because building fosters understanding. And as more people start making personal software, the bar for what counts as “great software” will inevitably rise.

Love this take. After over a decade of software development I've gained much more appreciation for well-built/useful products.

It seems like the more deployment friction there is for your project, the more the scale tips toward buy vs build here.

As a solo dev, something lightweight and cost-effective like this is attractive. Deployment is a CLI command or PR merge away.

Would I recommend it for the 200 person engineering org that deploys at most once a week? Probably not.

Maybe this exists and I haven’t found it yet but a lightweight logging/alerting solution would be nice. That way, I don’t have to invest in Datadog with all the extra bells and whistles targeted for enterprise customers.

I don't practice TDD often but I've found that TDD can be particularly useful in rare cases when there is a long feedback loop for manually testing the logic I'm working on. In these situations, TDD is perfect for quickly validating a code change.

> Amy Edmondson of Harvard, the leading researcher in psychological safety, defines it as the belief that you won't be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. It encourages intelligent risk-taking by reducing interpersonal anxiety.

I've found that many tech workplaces seem to favor _always_ being complimentary over "psychological safety" per the definition above.

For example, there have been too many situations to count where folks don't feel safe enough to speak up if another coworker produces sub-par work.

Toxic positivity seems to destroy psychological safety.

This general method has worked well for me, too.

Keep things as simple as possible for as long as possible, identify abstractions later rather than sooner, build the system knowing it will change and optimize for as little friction as possible when that change inevitably happens.

> Whatever the explanation, the continuing rollback of remote work options at larger employers creates a rare opportunity for startups and smaller employers to recruit employees who have sought-after skills.

We could be looking at a shift in talent from larger organizations joining smaller projects.

Wondering what the pros/cons are if this happens. I could see this putting more strain on entry-level folks getting a foot in the door of remote companies. But I could also see this being a net positive outcome for innovation.