Learn the essential skills for IT freshers, including programming, DSA, SQL, Git, debugging, communication, projects, AI tools, and role-specific skills.

How to Solve Coding Problems When You Don't Know Where to Start

If you know Java, Python, C++, or another programming language but still freeze when you open a coding problem, you're not alone.

I know that feeling. You can understand loops, conditions, arrays, functions, and even some data structures. You can watch someone solve a LeetCode problem and think, "Oh, that makes sense." But then you open another problem by yourself and suddenly your mind goes completely blank.

What do I do first? Which data structure should I use? Is this a two-pointer problem? Do I need a HashMap? Should I sort the array? Should I use recursion?

And after staring at the problem for ten minutes, you end up looking at the solution.

I've experienced this gap while learning programming and practicing DSA myself. I've worked mainly with Java, along with C, C++, Python, JavaScript, and web technologies such as React and Node.js. I've also practiced DSA and solved 125+ LeetCode problems.

One thing I've realized is that knowing programming syntax and knowing how to solve problems are two different skills.

You don't necessarily need to learn 100 more algorithms to fix the problem. You need a process for turning a confusing problem into a series of smaller decisions.

That's what this guide is about.

The goal isn't to immediately know the answer. The goal is to know what to do next.

Why You Know Programming But Still Can't Solve Problems

This is one of the most frustrating stages of learning programming.

You might already know:

• Variables
• Loops
• Conditions
• Arrays
• Strings
• Functions
• Basic object-oriented programming
• Some DSA concepts

Yet a coding problem can still feel impossible.

Why?

Because programming knowledge answers the question:

"How do I write this instruction in code?"

Problem-solving asks a different question:

"What instructions should I write in the first place?"

That's a much harder skill.

For example, you might know exactly how to use a HashMap in Java. But that doesn't automatically tell you when a HashMap is useful.

You might know binary search perfectly. But recognizing that a particular problem can be converted into a binary-search problem is a different skill.

This is why watching tutorials can sometimes feel easier than solving problems independently.

When someone else explains a solution, your brain only needs to understand the path they've already created. When you're solving alone, you have to create the path yourself.

What I Do When I Don't Know Where to Start

When I open a coding problem and don't immediately know what to do, I try not to start coding.

Instead, I follow a sequence:

1. Understand the problem.
2. Identify the input and output.
3. Create a tiny example.
4. Solve that example manually.
5. Write down the brute-force approach.
6. Look at the constraints.
7. Search for patterns.
8. Choose a suitable data structure or algorithm.
9. Write pseudocode.
10. Convert the pseudocode into code.
11. Test edge cases.
12. Analyze time and space complexity.

It sounds simple, but this process changes the experience completely.

Instead of asking:

"How the hell do I solve this?"

You start asking:

"What is the next question I need to answer?"

Step 1: Understand the Problem Before Coding

This is where most beginners make the mistake.

They read the problem once, recognize a few familiar words, and immediately start writing code.

Don't.

Read the problem slowly and translate it into your own words.

Ask:

• What information am I given?
• What exactly do I need to find?
• What should my function return?
• Are there any restrictions?
• Can the input contain duplicates?
• Can the input be empty?
• Does the order matter?

If you cannot explain the problem in simple language, you probably aren't ready to code it.

For example, instead of thinking:

"Find two numbers in an array that add up to the target."

Rewrite it as:

"I have a list of numbers. I need to find two different positions whose values add up to a particular number."

That small change can make the problem easier to reason about.

Step 2: Identify the Input and Output

Before thinking about algorithms, make the input and output obvious.

For example:

Input:
nums = [2, 7, 11, 15]
target = 9

Output:
[0, 1]

Now you know exactly what you're working with.

This might sound too basic, but when you're stuck, removing ambiguity is extremely useful.

Step 3: Create a Small Example

If a problem looks complicated, make it smaller.

Suppose the original input contains 100 numbers.

Forget the 100 numbers.

Create something like:

[2, 7, 5]

Then ask yourself:

"If I had to solve this without a computer, what would I do?"

This question is surprisingly powerful.

Computers execute logic. Before you can write that logic, you need to understand what your own brain would do manually.

Step 4: Solve It Manually

Let's use the classic Two Sum problem.

You have:

nums = [2, 7, 11, 15]
target = 9

You need to find two numbers that add up to 9.

Don't think about HashMaps yet.

Imagine you're solving it on paper.

You look at 2.

What number would you need to reach 9?

9 - 2 = 7

Is 7 somewhere in the array?

Yes.

So you've found the answer.

This is an important lesson: your algorithm often starts as a human thought process before it becomes code.

Step 5: Start With Brute Force

Here's the part I wish more beginners understood.

Your first solution does not need to be optimal.

If you immediately try to find the most efficient solution, you can make a simple problem feel much harder than it actually is.

For Two Sum, the simplest approach is:

1. Pick the first number.
2. Compare it with every number after it.
3. Check whether their sum equals the target.
4. Repeat until you find the answer.

In Java, that could look like:

public int[] twoSum(int[] nums, int target) {
    for (int i = 0; i < nums.length; i++) {
        for (int j = i + 1; j < nums.length; j++) {
            if (nums[i] + nums[j] == target) {
                return new int[]{i, j};
            }
        }
    }

    return new int[]{};
}

This isn't the most efficient solution, but it is a completely valid starting point.

The progression should often be:

Brute force → Understand → Test → Optimize

Don't confuse a brute-force solution with failure. It gives you a working baseline that you can improve.

Step 6: Look at the Constraints

Constraints are not decoration.

They give you clues about what kind of solution might be acceptable.

Imagine a problem says:

1 <= n <= 100

An O(n²) solution might be completely reasonable.

But if it says:

1 <= n <= 100,000

you should start questioning an O(n²) approach.

Why?

Because an algorithm that repeatedly compares every element with many other elements can perform a huge number of operations as the input grows.

You don't need to become a complexity expert overnight. Start by developing the habit of asking:

• How large can the input become?
• How many times am I looping through it?
• Am I repeatedly searching through the same data?
• Can a data structure make that operation faster?

Constraints often tell you whether you can afford a simple approach or need something more efficient.

Step 7: Look for Patterns

Once you understand the brute-force approach, ask:

"Am I doing the same work repeatedly?"

That's where optimization often begins.

In Two Sum, the brute-force approach repeatedly searches for the number we need.

For every number:

needed = target - nums[i]

If we could quickly check whether that value already exists, we could avoid repeatedly scanning the array.

That's where a HashMap can help.

Step 8: Choose the Right Data Structure

Don't choose a data structure because you memorized it.

Choose it because the problem is giving you a clue that makes it useful.

HashMap / HashSet

Start thinking about a HashMap or HashSet when you need to:

• Quickly check whether something exists.
• Count frequencies.
• Associate one value with another.
• Remember information you've already seen.

For Two Sum, we can remember numbers we've already encountered.

Two Pointers

Start considering two pointers when:

• You are working with an array or string.
• The data is sorted or can be sorted.
• You need to move from both ends or maintain two positions.

Sliding Window

Think about sliding window when the problem involves a continuous subarray or substring and you need to maintain a moving range.

Typical clues include words such as:

• Longest substring
• Smallest subarray
• Continuous sequence
• Window of elements

Binary Search

Think about binary search when:

• The data is sorted.
• You need to repeatedly search for something.
• The problem has a monotonic "yes/no" condition.

Don't assume every search problem needs binary search. Look for the clues first.

Stack

Think about a stack when you need a last-in-first-out behavior.

Common clues include:

• Matching parentheses
• Undo-like behavior
• Nested structures
• Processing the most recently added item first

Queue

Think about a queue when elements need to be processed in a first-in-first-out order.

This becomes particularly useful in problems involving level-by-level or sequential processing.

Recursion

Consider recursion when the problem naturally breaks into smaller versions of itself.

Tree traversal is a common example.

Prefix Sum

Think about prefix sums when you need to repeatedly calculate sums over ranges.

Instead of recalculating the same portions repeatedly, you can preprocess information once and reuse it.

Sorting

Sometimes sorting itself is the clue.

Sorting can make relationships between values easier to identify and can enable techniques such as two pointers.

Linked List Patterns

With linked lists, start thinking about patterns such as:

• Fast and slow pointers
• Reversing pointers
• Detecting cycles
• Using a dummy node

You don't need to memorize every pattern immediately.

The important skill is learning to recognize the clues that suggest a pattern.

A Simple Pattern Decision Framework

When you're stuck, ask yourself:

Question	Possible Direction
Is the array or data sorted?	Binary search or two pointers
Do I need to quickly check whether something exists?	HashSet / HashMap
Do I need frequencies or counts?	HashMap / frequency array
Is it about a continuous subarray or substring?	Sliding window / prefix sum
Do I need last-in-first-out behavior?	Stack
Do I need first-in-first-out processing?	Queue
Does the problem repeatedly ask for a range sum?	Prefix sum
Does the problem naturally break into smaller versions?	Recursion / divide and conquer

These are clues, not rules.

A good problem solver doesn't see the word "sorted" and automatically write binary search. They ask whether binary search actually fits the problem.

Step 9: Write Pseudocode

If you understand the approach but coding still feels difficult, stop writing actual code.

Write pseudocode.

For the optimized Two Sum solution, your thinking could become:

create a map

for every number:
    calculate the number needed to reach target

    if needed exists in map:
        return the previous index and current index

    store current number and its index

Notice something important.

There is no Java syntax here.

That's intentional.

First solve the logic. Then worry about syntax.

Step 10: Convert the Pseudocode Into Code

Once the logic is clear, translating it into Java becomes much easier.

import java.util.HashMap;

class Solution {
    public int[] twoSum(int[] nums, int target) {
        HashMap<Integer, Integer> map = new HashMap<>();

        for (int i = 0; i < nums.length; i++) {
            int needed = target - nums[i];

            if (map.containsKey(needed)) {
                return new int[]{map.get(needed), i};
            }

            map.put(nums[i], i);
        }

        return new int[]{};
    }
}

The important line is:

int needed = target - nums[i];

Instead of searching through the entire array for a matching number, we calculate exactly what number we need.

The HashMap lets us quickly check whether we've already seen it.

Step 11: Test Edge Cases

Getting your code to work on the example isn't enough.

Ask what happens in unusual situations.

For example:

• What if the array has only two elements?
• What if there are duplicate values?
• What if the target is negative?
• What if the numbers are negative?
• What if the answer uses the first and last elements?
• What if there is no valid pair?

Testing edge cases isn't something you should do only after becoming an advanced programmer.

It is part of learning how to think like a programmer.

Step 12: Analyze Time and Space Complexity

Finally, ask how efficient your solution is.

For the brute-force Two Sum approach, we potentially compare many pairs.

That gives us approximately:

Time: O(n²)
Space: O(1)

For the HashMap solution, we make one pass through the array while using extra memory:

Time: O(n)
Space: O(n)

Again, don't become obsessed with complexity before understanding the problem.

But make it a habit to analyze your solution after you've written it.

A Complete Example: How to Think Through Two Sum

Let's put everything together.

The Problem

Given an array of integers and a target value, find two numbers whose sum equals the target and return their indices.

nums = [2, 7, 11, 15]
target = 9

1. Understand

We need two different elements whose values add up to 9.

2. Try a Tiny Example

[2, 7]

2 + 7 = 9.

3. Solve Manually

For each number, calculate what number is required to reach the target.

9 - 2 = 7

So we need to know whether 7 exists.

4. Brute Force

Compare every pair.

5. Find the Repeated Work

The brute-force solution repeatedly searches for matching numbers.

6. Optimize

Remember the values we've already seen using a HashMap.

7. Pseudocode

create map

for each number:
    calculate needed value

    if needed is already in map:
        return its index and current index

    store current value and index

8. Code

HashMap<Integer, Integer> map = new HashMap<>();

for (int i = 0; i < nums.length; i++) {
    int needed = target - nums[i];

    if (map.containsKey(needed)) {
        return new int[]{map.get(needed), i};
    }

    map.put(nums[i], i);
}

9. Test

[2, 7, 11, 15], target = 9
→ [0, 1]

10. Complexity

Time: O(n)
Space: O(n)

That's the complete thought process.

Notice that the actual code was almost the final step.

The real solution happened before the code was written.

What to Do When Your Mind Goes Completely Blank

Sometimes none of this happens.

You read the problem.

You read it again.

Nothing.

If you're stuck here, that's normal.

Don't sit there staring at the screen for an hour hoping the algorithm will magically appear.

Use this emergency process:

1. Read the problem again.
2. Rewrite it in your own words.
3. Write down the input and expected output.
4. Create the smallest example you can.
5. Solve that example manually.
6. Write down exactly what you did manually.
7. Look for repeated work.
8. Try the simplest possible algorithm.
9. Check the constraints.
10. Only then think about optimization.

If you're still stuck, ask yourself one more question:

"What information would make this problem easier to solve?"

Maybe you need the data sorted.

Maybe you need to remember what you've already seen.

Maybe you need to maintain a range.

Maybe you need to count frequencies.

Maybe you need to process items in a particular order.

That question often leads you toward the right data structure.

Why Watching DSA Tutorials Isn't Enough

You can watch dozens or even hundreds of DSA tutorials and still struggle with coding problems.

That's because understanding someone else's solution is a different skill from discovering a solution yourself.

I've noticed this distinction while practicing problems myself.

Sometimes you see a solution and think:

"Of course! Why didn't I think of that?"

The problem is that recognizing the logic after someone explains it doesn't guarantee that you'll discover the same logic tomorrow.

That's why active problem solving matters more than passive consumption.

Instead of watching another solution immediately, spend some time trying to build your own approach.

Even if your approach is wrong, you are practicing the exact skill you want to improve.

Mistakes I Would Avoid When Learning DSA

1. Immediately Looking at the Solution

If you look at the answer after 30 seconds, you're mostly practicing recognition rather than problem solving.

2. Memorizing Code

Don't memorize:

for (...) {
    ...
}

Instead understand why the loop exists and what information it is maintaining.

3. Constantly Switching Languages

If your goal is problem solving, don't let syntax become another obstacle.

Since Java is my main programming language for coding practice, using one primary language can make the process more consistent.

You can learn other languages separately. You don't need to solve every DSA problem in five languages.

4. Solving Random Problems Without a Plan

Random practice can expose you to many concepts, but structured practice makes patterns easier to recognize.

For example, you could spend some time focusing on arrays and hashing, then two pointers, then sliding window, and gradually move toward more difficult topics.

5. Only Watching Tutorials

Watching someone solve 20 problems can make you feel productive.

But eventually, you have to close the video and solve one yourself.

6. Avoiding Easy Problems

Easy problems aren't beneath you.

They help build the pattern-recognition skills you need for harder problems.

7. Starting With Hard Problems Too Early

If every problem takes hours, you may spend more time feeling frustrated than learning patterns.

Difficulty should increase gradually.

8. Not Reviewing Failed Problems

A failed problem can be extremely valuable.

After learning the solution, ask:

• Where exactly did I get stuck?
• What clue did I miss?
• Which concept did I not recognize?
• Could I solve it now without looking?

9. Copying Without Rewriting

If you study a solution, close it afterward.

Then try implementing the solution yourself.

If you can't, you haven't fully internalized it yet.

When Should You Look at the Solution?

There is no prize for staring at one problem for six hours.

Looking at solutions is part of learning. The problem is how you use them.

A useful process is:

1. Attempt the problem yourself.
2. Write down what you understand.
3. Try a brute-force approach.
4. Struggle with it for a reasonable amount of time.
5. Take a small hint if available.
6. Try again.
7. Study the full solution if necessary.
8. Close the solution.
9. Implement it yourself.
10. Revisit the problem later.

This is much better than reading the solution immediately and thinking:

"Yeah, I understand."

Understanding a solution and being able to reproduce the reasoning are not the same thing.

How to Improve Your Problem-Solving Skills

If you want to get better at coding, don't measure your progress only by the number of problems solved.

Pay attention to whether your thinking is improving.

For example:

• Can you understand a new problem faster?
• Can you create examples more quickly?
• Can you identify brute-force approaches?
• Can you recognize familiar patterns?
• Can you explain why your solution works?
• Can you identify the time complexity?
• Can you solve a previously failed problem later without help?

Those are meaningful signs of progress.

My own programming journey has reinforced one important lesson: consistency matters more than trying to become brilliant overnight.

If you're also struggling with consistency, you may find this related guide useful:

[Internal Link Opportunity: How to Learn Programming Consistently]

And if procrastination is the bigger problem preventing you from practicing, another useful related article would be:

[Internal Link Opportunity: How to Stop Procrastinating]

How to Practice Coding Problems Consistently

You don't need to solve ten problems every day.

A better approach is to create a routine you can actually maintain.

For example, during a practice session:

1. Choose one problem appropriate for your current level.
2. Spend time understanding it.
3. Attempt it without immediately searching for the answer.
4. Write down your approach.
5. Study a hint or solution if necessary.
6. Implement the solution yourself.
7. Write down the key pattern you learned.
8. Revisit the problem later.

You can even maintain a simple problem-solving notebook.

For every problem, record:

• Problem name
• What confused me
• My first approach
• Why it failed or was inefficient
• The final approach
• The pattern used
• Time complexity
• Space complexity

Over time, this becomes your own personal DSA reference instead of another collection of copied solutions.

🛠️ My Coding & Study Setup: Things That Actually Help

If you're serious about getting better at coding, you don't need a ₹1 lakh setup or a desk full of expensive gadgets.

But having a few useful tools around you can make studying, practicing DSA, and staying consistent a lot easier.

Over time, I've found that the little things matter — a good book to refer back to, a notebook where you can actually write down your failed approaches, and a comfortable setup where you can sit and solve problems without constantly getting distracted.

So I've put together a small collection of things across coding, studying, self-improvement, gadgets, and everyday work that you can browse if you're building your own setup.

👇 If you're currently building or upgrading your coding/study setup, you can check out my collections here:

🛒 EXPLORE MY AMAZON STORE →

📚 What You'll Find There

• 💻 Useful Gadgets — practical tech and accessories for your coding, studying, and work setup.
• 📖 Self-Help Books — books around learning, discipline, productivity, mindset, and personal growth.
• 📝 Study Tools — useful items for taking notes, planning your practice, and staying organized.
• 🎒 College & Work Essentials — practical products that can be useful for students and working professionals.

Why have I put these together?

Because when you're trying to build a consistent habit, you shouldn't have to spend hours searching for every little thing separately.

I've organized the store into different categories so you can quickly browse the things that are actually relevant to you.

For example, if you're a student looking for useful study tools, go there and check the Study Tools collection. If you're interested in books that can help with personal growth, check the Self-Help Books section. If you're setting up a coding or work desk, have a look at the Gadgets collection.

You don't need to buy anything just because it's recommended. My goal is simply to make the searching process easier for you.

Check the product details, compare prices, read reviews, and buy only if something genuinely makes sense for your needs.

👉 See My Coding, Study & Self-Improvement Picks

Affiliate disclosure: Some links in this section may be affiliate links. If you purchase through them, I may earn a small commission at no additional cost to you. This helps support my content and allows me to continue creating useful programming, career, and student-focused content.

My Simple Coding Problem-Solving Framework

If you remember nothing else from this article, remember this:

Understand → Example → Manual Solution → Brute Force → Constraints → Pattern → Data Structure → Pseudocode → Code → Test → Complexity

Here's the shorter version you can keep beside you while practicing:

Before Coding

• What exactly is the problem asking?
• What are the inputs?
• What should I return?
• What are the constraints?
• Can I solve a tiny example manually?

While Solving

• What's the brute-force approach?
• Am I repeating work?
• Can I identify a pattern?
• Can a data structure help?
• Can I simplify the problem?
• What edge cases exist?

After Coding

• Does it work on the example?
• What happens with empty input?
• What happens with one element?
• What happens with duplicates?
• What happens with negative values?
• What is the time complexity?
• What is the space complexity?
• Can I explain why my solution works?

Save this framework. Screenshot it. Use it every time you get stuck.

Frequently Asked Questions

How do I start solving coding problems?

Don't start by writing code. First understand the problem, identify the input and output, create a small example, solve it manually, and then think about a brute-force approach. After that, use the constraints and patterns to improve your solution.

Why do I understand coding but can't solve problems?

Programming syntax and problem solving are different skills. Knowing loops, arrays, and functions tells you how to express a solution in code, but problem solving requires you to determine what the solution should actually be.

How can I get better at solving LeetCode problems?

Practice consistently, start at an appropriate difficulty level, attempt problems before looking at solutions, learn common patterns, and revisit problems you previously failed.

Should beginners start with brute force?

Yes. A brute-force solution gives you a working baseline and helps you understand the problem. Once you understand the simple approach, you can look for repeated work and optimize it.

How long should I struggle with a coding problem before looking at the solution?

There is no universal time limit. The important thing is to make a genuine attempt first. If you have no progress, use a small hint, then try again. If necessary, study the solution and implement it yourself afterward.

Should I memorize DSA patterns?

Memorizing pattern names is less useful than understanding the clues behind them. You should gradually learn when a HashMap, two pointers, sliding window, stack, binary search, or another technique is likely to be useful.

How many coding problems should I solve every day?

Quality matters more than a specific number. Solving one problem deeply, understanding why it works, and reviewing your mistakes can be more valuable than rushing through several problems without understanding them.

What should I do when I completely don't understand a coding problem?

Rewrite the problem in your own words, create the smallest possible example, solve it manually, and write down each step you took. Then turn those steps into pseudocode. If you're still stuck, use a hint before looking at the full solution.

Final Thoughts

If you currently open a coding problem and think, "I have no idea where to start," don't automatically assume you're bad at programming.

You may simply be missing a problem-solving process.

I also had to learn that knowing programming concepts doesn't automatically mean you can combine them under pressure. The more problems you practice, the more you start noticing that the hardest part isn't always writing the code.

It's understanding the problem.

It's creating the right example.

It's figuring out what information matters.

It's recognizing repeated work.

It's choosing the right tool.

And sometimes, it's simply staying with the problem long enough to discover something yourself.

So the next time you open a LeetCode problem and your mind goes blank, don't immediately search for the solution.

Stop.

Rewrite the problem.

Create a tiny example.

Solve it like a human.

Start with brute force.

Check the constraints.

Look for patterns.

Write pseudocode.

Then code.

You don't need to know the answer immediately.

You just need to figure out the next step.

And that's how problem solving gradually becomes a skill instead of something that feels like a guessing game.

About the Author

I'm Sandip Mali, a computer science graduate and IT professional sharing practical experiences and lessons around starting a career in technology.

Through this blog, I write about IT fresher preparation, college placements, first-job experiences, corporate life, career development, relocation, and the practical challenges that come with starting a career.

My aim is to share practical information from a fresher's perspective while being transparent about the fact that technology, job requirements, recruitment processes, and company practices vary.

Note: Technology requirements and recruitment processes vary between companies and roles. Always check the current requirements of the specific job or organization you're targeting.