DEV Community: Skilled Coder

Tech Interviews Are Broken -And So Is Real-World Engineering

Skilled Coder — Sun, 30 Mar 2025 05:25:02 +0000

Our Interview System is Fundamentally Broken

After nearly a decade in big tech companies and interviewing at many more, I’ve come to realize something pretty obvious: tech interviews are fundamentally flawed.

Here’s the truth: interviews today don't test how good you are at building software. Instead, they test how well you've prepared to play the "interview game."

You know the drill. You spend days (or even months!) solving LeetCode problems, cramming solutions for puzzles that interviewers casually label as "easy." Of course, it’s easy—after they've glanced at the solution minutes before your interview. But in reality, coming up with those solutions on the spot demands serious DSA intuition, deep pattern recognition, and a fair bit of luck. Expecting candidates to crack these problems in under 15 minutes? That's just unrealistic.

Then comes the infamous system design round. You're asked to design Twitter, Instagram, or a billion-user-scale system in just 40 minutes. Let’s be honest—almost everyone memorizes a basic blueprint because, guess what? In the real world, nobody designs Instagram from scratch using MySQL and Redis on a whiteboard. Real-world system design is messy, iterative, and deeply tied to ever-changing business goals—something these interviews completely ignore.

Our interview process filters out talented engineers who might not be great at memorizing "perfect" solutions but excel at solving real-world problems. The current system rewards polished communication and confident jargon-dropping more than actual engineering skills.

Real-world Engineering Looks Completely Different

Step away from the interviews, and you quickly realize that day-to-day engineering is nothing like these high-pressure puzzle-solving sessions.

You're not reinventing databases or crafting groundbreaking algorithms from scratch. Instead, your daily tasks often look like:

Converting one API format into another just because another team needs it differently.
Tweaking protobuf schemas while ensuring nothing breaks for existing users.
Refactoring code—not because it's broken, but because someone decided to standardize naming conventions.
Writing migration scripts for feature flags that everyone forgot existed.
Convincing infrastructure teams to adjust rate limits, even if the request later turns out unnecessary.
Crafting impressive-sounding documentation to justify simple tasks because promotions depend on narrative more than actual complexity.
Adjusting unit tests to hit arbitrary coverage metrics, knowing full well these tests aren't catching real-world issues.

And the kicker? Most of the code you write today won't even matter in a couple of years. It’s just tech debt piling up, waiting to be rewritten. Deadlines loom, priorities shift, and "clean" code becomes a luxury nobody has time for.

When crunch time hits, your messy PR will get approved instantly because, at the end of the day, shipping matters more than beautiful code.

The Real Skill: Adaptability
The best engineers aren't the ones arguing about the "right way" to do things—they're the ones who understand the reality of building software at scale. They're adaptable. They ship fast when needed and optimize carefully when time permits.

Good engineers adapt; great engineers deliver.

Accepting the imperfect reality of tech interviews and software engineering can help you navigate the industry more effectively. Because ultimately, it’s not just about coding skill—it’s about understanding and playing the game well.

Java Memory Leaks: What Causes Them and How to Avoid Them

Skilled Coder — Mon, 24 Mar 2025 15:45:00 +0000

Memory leaks in Java aren’t always loud or obvious. Sometimes, they creep in quietly - through static fields, forgotten listeners, or subtle misuse of common classes. These leaks don’t crash your app right away, but they slowly degrade performance, increase memory usage, and lead to unexpected OOM errors in long-running systems.

In this post, we’ll look at some lesser-known but real-world Java memory leak patterns with clean fixes you can apply right away.

1. Using ThreadLocal without removing

In thread pools (e.g., servlet containers), threads live long. If we don't remove the value, it stays in memory forever, even if it's not used again

Fix:

.remove() clears the reference tied to the thread, allowing GC to collect the HeavyObject instance after it's used - avoiding memory bloat in long-lived threads.

2. Static Collections Holding Data

Static map never dies = entries stick around forever = slow memory leak as data piles up.

Solution: Using a proper caching library (like Caffeine) introduces eviction + TTL, meaning old or unused entries are automatically removed, keeping memory usage in check.

3. Anonymous Inner Classes Holding Outer Class References

Inner classes implicitly hold a reference to the outer class. If the task lives long, it prevents the outer class from being GC'ed - even if the user navigated away.

Non-static inner classes hold an implicit reference to their outer class. If they outlive the outer class, they can cause a memory leak.

Fix: Use static inner classes or separate classes. A static inner class does not hold an implicit reference to an instance of the outer class. This decoupling ensures that the lifecycle of the inner class is not tied to the outer class, preventing potential memory leaks.

when the outer object is unused, it’s freed correctly by the GC.

4. Listeners Not Removed

You added a listener but never removed it. So even if the object that registered it is no longer needed, it stays alive because the button holds it.

Fix: Explicitly removing the listener breaks the reference chain, allowing both the listener and possibly its enclosing object to be garbage collected.

5. Holding Strong References to ClassLoaders

private static final List<ClassLoader> loaders = new ArrayList<>();

In plugin/reloadable apps, classloaders should be GC'ed after unload. But strong references keep them in memory, causing class metadata and heap leaks.

Fix:

Weak references don’t prevent GC, so once a classloader is unused, it’s eligible for cleanup. You avoid both heap and Metaspace bloat.

List<WeakReference<ClassLoader>> loaders = new ArrayList<>();

6. Unbounded Executor Queues

The default LinkedBlockingQueue used by Executors.newFixedThreadPool() is unbounded. Submitting millions of tasks causes the queue to grow indefinitely, consuming heap.

Fix: Use a custom ThreadPoolExecutor with a bounded queue:

The queue has a size cap, preventing runaway heap usage. CallerRunsPolicy throttles the caller instead of leaking memory.

7. JDBC Connections Not Closed Properly

If the connection isn’t closed, it stays alive, leading to connection leaks and memory/resource exhaustion.

Connection conn = dataSource.getConnection();
// do stuff

Fix:

try (Connection conn = dataSource.getConnection()) {
    // use it
}

The try-with-resources block ensures the connection is always closed, even if an exception occurs - preventing resource + memory leaks.

8. Keeping Long References in Logging Context (like MDC)

MDC uses ThreadLocal internally. If you don’t clear the context, that data lives on in the thread - leaking memory across requests in thread pools.

Fix:

.clear() removes all MDC values tied to the thread, letting memory get released cleanly after request completion.

Most memory leaks in Java happen not because of complex code, but because of overlooked patterns in everyday usage.

Catch these early, and your app stays healthy. Miss them, and they quietly eat your memory.

If you found these helpful, drop a follow or share — and let me know if you’ve seen any sneaky leaks in the wild.

For more coding related content subscribe to my newsletter and twitter

The Leetcode Trap: Why Solving 1000 Problems Won’t Make You a Real Problem Solver

Skilled Coder — Thu, 20 Mar 2025 08:03:13 +0000

You’ve been lied to.

Everyone says, "Grind 200-500 Leetcode problems before your interview."
Everyone follows this mindless formula - because it works, right?

Wrong.

Because if you need to solve 500+ problems just to feel "ready," let’s be brutally honest: you’re not a real problem solver.

You're a pattern matcher.

And the moment an interviewer throws an unseen and unique problem at you, you freeze. Your brain panics. You have no clue what to do - because you never actually learned problem-solving. You just memorized patterns and prayed they’d show up again.

This is why so many smart engineers bomb interviews.

It’s not that they aren’t good at coding.
It’s that they’ve been training the wrong way.

This post will show you how to train like a real problem solver.
Not a Leetcode bot.
Not a brute-force grinder.
But an engineer who can think through any problem - even if they’ve never seen it before.

Let’s break it down.

Why People Grind 500+ Questions

Why do people grind hundreds of Leetcode problems?

Simple. They’re addicted to easy progress.

Every time you solve a new problem, you get a dopamine hit.
You feel like you’re improving.
You mark another problem as "solved" in your spreadsheet.
Your confidence grows - but only in familiar territory.

The second you see something slightly different (or same thing after long long time)?
Your mind short-circuits.

This happens because you never actually built problem-solving skills.
You just memorized enough patterns to brute-force your way through an interview.

And that works - until it doesn’t.

The Harsh Truth: You’re Giving Up Too Soon

Here’s the real reason most engineers never develop true problem-solving skills:

They check solutions too soon.

Most people:

Try for 10-15 minutes.
Get stuck.
Open the solution.
Feel like they "understand" it.
Move to the next problem.
Rinse and repeat. And they learn nothing.

Real problem solvers don’t look up solutions.

They sit with the frustration.
They obsess over the problem.
They refuse to give up.

Because true breakthroughs happen in that struggle.

Think about it - when was the last time you truly struggled with a problem for 3 days straight?
Not an hour. Not a few minutes. Days.

Most people never do this - so they never get better.

And then they wonder why they can’t solve unseen concept in an interview.

The Right Way to Train: Become a Natural Problem Solver

If you want to actually develop problem-solving skills, stop grinding.
Start training your brain the right way.

1️⃣ Pick Fewer, Harder Problems

Instead of solving 500 problems mindlessly, do this:

✅ Go to Codeforces or CodeChef.
✅ Pick 5-10 medium-hard problems from old contests.
✅ Solve them without looking at the solution.

If it takes 3 days to crack a single problem, so be it.
If you struggle, that’s the point.

Struggling forces you to think deeper.
Thinking deeper forces you to truly understand.

This is how real engineers train.

2️⃣ Never Look at the Solution (Until You Break)

This is where 99% of people fail.

The moment they get stuck, they peek at the answer.
And that destroys the learning process.

New Rule: No solutions. Ever.

Sit with the problem.
Break it apart.
Think about what you’re missing.
If you’re stuck, walk away and come back later.
Let your brain keep working on it in the background.
The more you struggle, the deeper your learning.

Eventually, you’ll crack the problem on your own - and that will stick with you forever.

3️⃣ Simulate Real Pressure

Most people fail interviews because they aren’t used to thinking under pressure.

Leetcode grinding won’t fix this. Contests will.

✅ Compete in Codeforces Div 2 or CodeChef Starters.
✅ Join short contests where you only have 1-2 hours to think.
✅ Learn to solve problems fast, under real stress.

When an interviewer throws a hard question at you, you’ll be calm, collected, and sharp.
Because you’ve trained for it.

My Story: How I Learned This the Hard Way

Back in college, I fell for the grind mindset.

I thought solving 200-300 problems would make me a master.
It didn’t.

But then, I started competing in CodeChef Long Contests - 10 days, 10 problems.

The first 4-5 problems? Easy.
But the next 3-4?

They broke me.
I spent days stuck.
I couldn’t Google the answer. (Back then there were no AI to help)
I had to break the problem down myself.

It was frustrating.
It was painful.
But when I finally solved them? I had leveled up, and the feeling was amazing.

This is why, even after 9 years in the industry, I never have to grind 100+ problems before an interview.

I just review 15-20 solid questions, and I’m ready.
Because my brain knows how to think.

The Future: Master This, and You’ll Never "Prepare" Again

If you train like this, you will never need to grind again.

You will walk into any interview fully confident.
Not because you solved 500+ questions.
But because you know how to solve any problem, even if you’ve never touched something like it before.

That’s real problem-solving.

And that’s what top engineers do.

The 4-Step Framework to Build Real Problem-Solving Skills

If you want to become a true problem solver, follow this:

Pick one hard problem per week. Deep-dive into all possible solutions.
Struggle with problems for days before looking at a solution.
Compete in short contests to simulate real pressure.
Develop meta-skills: breaking problems down, finding patterns, optimizing solutions.

💡 Do this for 3-6 months, and you will see the difference.

You’ll no longer be a Leetcode grinder.
You’ll be a natural problem solver.

And that’s the skill that gets you hired. 🚀

Final Thought (Read This Twice)

If you can train your mind to never give up, you’ll never need to grind again.

Now go.
Pick a problem.
And struggle until you win.

That’s how you get better. 💪