No Learning in a Service Company? Where to Find Hard Problems

Your service project has hard problems in it. Nobody assigns them to you. You find them by asking what happens at 10× on the tickets you already have, and when the project truly has nothing, you build the problem yourself, at scale, outside work.

Asmit, one of my learners, put it like this:

With over 3 years of experience, I understand that companies now expect depth in whatever skills you have. Since my company is service-based, it is very difficult to gain that depth.

Asmit is right about both halves. So start by knowing what depth looks like.

How to tell a hard problem from a long one

Check your last five tasks against these four questions:

1. Scale: are the numbers big enough that the obvious approach breaks?
2. Trade-off: were there two reasonable answers, each with a cost?
3. Consequence: would a wrong call cost users, money or a weekend?
4. Ownership: did you decide, or did the spec, the architect or the client?

A task that passes none of them was long, however many days it took. A task that passes three or four is the kind an interviewer will ask you about. If none of your last five pass more than one, your project isn’t teaching you, and it’s on you to change that.

Upgrade the tickets you already have

Most tickets on a service project are small versions of hard problems, and the hard version is one question away. You don’t have to ship the bigger version. Work it out, measure what you can, and write down what you’d do.

“Add a list screen for orders.” Ask what happens at 10 million rows. OFFSET pagination gets slower the deeper the user scrolls, because the database still walks past every skipped row. Read about keyset pagination, check which index the query uses, and run EXPLAIN ANALYZE on page 1 and page 5,000.

“Rename a field in the API response.” Ask which clients break. Find every consumer of that endpoint. Work out how you’d ship the new field next to the old one, how long you’d keep both, and how you’d know when it’s safe to remove the old one.

“Send a confirmation email after the order is placed.” Ask what the customer waits for. If the email goes out inside the request, a slow mail server makes checkout slow. Work out how you’d move it to a queue, and what happens when the send fails.

“The report page is slow.” Ask why before you fix it. Is it a missing index, an N+1, or too much data? Would you add a cache or fix the index? Get the numbers before and after.

You can also dig without any ticket. Find your service’s p95 latency; if nobody on the team knows it, finding out is already a hard problem, because you have to work out where the numbers live and which endpoint is the worst. And read the last few incident reports. Every outage on your project is a hard problem somebody else solved, so check whether you’d have solved it the same way.

What practice outside work does to work

A learner of mine did the first assignment in the program, which benchmarks MongoDB against Postgres at scale, with and without batching. The next day at work they got a connection-timeout bug on large document reads. They spotted the missing batching first, proposed the fix, and their senior agreed.

When your project truly has nothing

Some projects are thin. Maybe you’re on support with no production access, and the client won’t let you touch anything that matters. Then build the problem yourself.

Take one piece of what your project does and rebuild it at scale. Load a million rows into Postgres and make the slowest query fast, or put a load test on one endpoint and find where it falls over. Moving one slow step into a queue and watching what breaks teaches you plenty too.

The 1 Million Row Challenge is the quickest place to start: a slow Postgres query in your browser and five minutes to fix it. Then try The Latency Game to see whether you can tell 50 µs from 5 minutes.

Side projects usually die without someone pushing back on them. That’s what Vyson is for. You build a backend for a million users, every submission comes back with my red pen on it, and you redo it until you can defend every choice.

What waiting costs you

The easy tickets are the work AI is taking first. I wrote about that in Will AI Take My Job? A 2-Minute Test for Developers. The longer you wait for your project to hand you something hard, the higher the interview bar gets, which I covered in Is It Too Late to Switch to a Product Company at 8 Years?

At the end of this week, answer one question: what did you get done learn this week?