One thing to remember
A good solution is not only accepted by the judge. You must be able to explain why it works, what it costs, and where it can fail.
Why this matters
In a placement interview, the interviewer is checking your thinking process. They may care more about your reasoning than the final code.
Your repo should show the same skill. Each solved problem needs a short explanation that sounds like you can talk through it on a call.
Use this structure
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Explanation template
Create a small explanation beside each solution, or add it inside your README under that problem. Keep it short. Recruiters will scan it.
Problem: Two Sum
Goal:
Find two indices whose values add up to the target.
Pattern:
Hash map lookup.
Approach:
Scan the array once. For each number x, check if target - x was seen before.
If yes, return both indices. If no, store x with its index.
Why it works:
For every element, the only possible partner is target - x.
The map tells us if that partner appeared earlier.
So the first valid pair found is correct.
Complexity:
Time: O(n), because each element is visited once.
Space: O(n), because the map can store up to n elements.
Edge cases:
- Negative numbers
- Duplicate values
- No valid pair, if the platform allows that casePractise out loud
Before you commit a problem, explain it in 60 to 90 seconds without reading the code. If you get stuck, your explanation file is not clear enough yet.
You can ask ChatGPT or Gemini: “Act as an interviewer. Ask me follow-up questions on this solution.” Check that the AI does not change your algorithm or invent constraints.
Common weak explanation
Do not say only, “I used DP” or “I used BFS.” That names the tool, not the reasoning.
Also avoid fake certainty. If there is an edge case you have not tested, test it before writing that it works.
Speak it simply
Here is a short spoken version for a graph traversal problem. Notice the order: goal, method, safety check, cost.
I need to find whether all rooms can be visited.
I model rooms as nodes and keys as directed edges.
I start from room 0 and run DFS.
Whenever I enter a room, I mark it visited so I do not loop forever.
At the end, if the number of visited rooms equals n, the answer is true.
The time is O(V + E), because I visit rooms and keys once.
The space is O(V), for the visited set and recursion stack.Do this now
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
git add .
git commit -m "Add explanation and edge cases for two sum"