It feels like the whole junior hiring playbook is broken. Standard take-home assignments don't work anymore because candidates can just generate an entire app in minutes and companies reacting by raising the bar to ridiculous mid level expectations are shutting out great talent.

We shifted our focus away from raw code generation during interviews and started looking closely at code review and debugging skills instead.

How has your team changed its hiring process to actually spot good potential in junior devs when AI can fake the basics?

This is the toughest part of building engineering teams right now. When I started, you learned by grinding through hundreds of basic CRUD endpoints and simple UI bug fixes.

Now, an LLM handles all of that in a few seconds, which has completely wiped out the traditional stepping stones for fresh grads. Companies expecting mid-level skills for entry-level pay are missing the point entirely.

If you're hiring or mentoring juniors today, what kind of actual entry-level tasks are you giving them to help them grow without burning them out?

It's so tempting to keep adding tabs and buttons just in case someone needs them someday. Most of the time unused features just add visual clutter and make the rest of the product harder to navigate.

We recently pulled the plug on a tool that nobody used for six months and nobody even noticed or complained. Have you ever removed a quiet feature just to clean up your dashboard?

We used to celebrate hitting high weekly signup numbers, but looking at month-two retention always brought us right back down to earth. A huge chunk of those users were bouncing immediately because our messaging attracted people who wanted a completely different tool.

We were wasting time building features based on feedback from the wrong crowd. Once we explicitly rewrote our landing page to say what the product doesn't do our signups dropped by half, but retention doubled.

Have you ever deliberately slowed down your top of funnel growth to filter out bad-fit users?

I can safely say that the video is one of the most important things on launch day.

Sometimes even more important than your images.

There is a super fine line between a helpful reminder and mental noise. Early on we configured notifications for every tiny event inside the dashboard assuming it built a daily usage habit. Turns out people just turned off app permissions or deleted their accounts to clean up their phones and inboxes.

Now we're trying to figure out smart defaults like only pinging users when an action is strictly required from them.

What rules do you follow to make sure your alerts bring value instead of fatigue?

I sent the same page three requests this morning with no cookies attached, the way a monitor or a link checker would. Three responses, three different session ids, three different CSRF tokens, each one set to live for a day. The same response also says it must not be stored by any cache.

The pages either side of it, same site, same server, same deploy, hand out nothing at all and are served with five minutes of freshness and a day of stale while revalidate. The difference is not the page and not the traffic. It is which middleware group the route was declared in, which in my source is a word at the end of one line.

Then I went looking for what reads those two cookies on that page. Nothing does. The page carries no form and never prints the token into the markup, so neither cookie has a consumer until the visitor goes somewhere else. I watched the session store locally while sending five of those requests and it did not gain a single file. The id is minted, sent, and never asked for again.

Here is the check, and it is about two minutes. Take the pages you point ads or links at. Request each one without cookies. Look at exactly two response headers: whether anything is being set, and what the caching header says. If the first is present, that page is out of every shared cache in front of you no matter what the second one claims, and the clients collecting those identities are your uptime monitor, your link checker, every social preview fetcher and every crawler, none of which will ever send one back.

I m a solo founder building Ember (Next.js + Supabase) with AI coding tools. Last week I did a security pass on my database. Here s what I found:

1. Row-level security checks which rows, not which columns.
My users table let a logged-in user update their own row. That sounds fine, until you notice their own row includes the column that stores their plan. Fix: revoke table-wide UPDATE and grant it only on the columns the app really needs (streaks, achievements).

2. Policies combine with OR.
An old open policy beats a new strict one. Audit all policies per table and drop the permissive ones.

3. Public pages need a narrow door.
Shared roast links must be readable by logged-out visitors, but the table is owner-only. Solution: a SECURITY DEFINER function that looks up by a random share code and returns only public fields, with a fixed search_path and EXECUTE granted to anon and authenticated.

4. Test as the real roles.
I run tests inside a single DO block that sets role anon or authenticated, checks results, and then raises an exception so everything rolls back. No test data left behind.

Biggest lesson: it works in the app proves nothing about what a logged-in user can do through the API.

Curious how others test their RLS policies. What s your setup?

Our most requested feature from feedback forms took us three weeks to build and ship. We launched it with an announcement email and in app banner but less than 5% of active users have touched it since.

It was a good reminder that what users say they want in a survey often differs from what actually fits into their daily habits.

How do you validate feature requests before committing engineering time to build them?

We ve been debating between offering a 14 day free trial or a permanently free tier restricted features. Freemium seems great for virality, but managing storage and server costs for inactive free users gets expensive fast. On the flip side, time-boxed trials create urgency but turn away casual explorers.

For early-stage SaaS, which model helped you convert high-intent users faster without burning resources?