Notifications
Last 30 Days
No notifications
Last 30 Days
No notifications
Moving from tutorials to real problem-solving requires mastering patterns and building projects. This module covers the most common coding interview patterns in Python and gives you a roadmap for practical projects.
| Pattern | When to Use | Python Tool |
| Two Pointers | Sorted arrays, palindromes | left, right = 0, len(a)-1 |
| Sliding Window | Subarrays/substrings of size k | collections.deque |
| Hash Map | Frequency, lookup, duplicates | dict, Counter, defaultdict |
| Stack | Matching brackets, monotonic | list as stack (append/pop) |
| BFS / DFS | Graphs, trees, connected components | deque for BFS, recursion for DFS |
| Binary Search | Sorted data, search space reduction | bisect module |
| Greedy | Optimal local choices | Sort + iterate |
| Dynamic Programming | Overlapping subproblems | @lru_cache or table |
1. UNDERSTAND ā Restate the problem, identify inputs/outputs
2. EXAMPLES ā Work through 2-3 examples by hand
3. APPROACH ā Pick a pattern, analyze time/space complexity
4. CODE ā Write clean, modular Python
5. TEST ā Verify with edge cases (empty input, single element, large N)| Project | Skills Used |
| Web Scraper | requests, BeautifulSoup, file I/O |
| CLI Task Manager | argparse, JSON, file I/O, OOP |
| Data Analyzer | pandas, matplotlib, CSV processing |
| REST API Client | requests, error handling, json |
| Markdown-to-HTML Converter | Regex, file I/O, string manipulation |
sys.stdin for fast input in competitive programmingsorted() uses Timsort (O(n log n)) ā very efficient@lru_cache turns recursion into memoized DP with one decoratorKnowing the syntax doesn't mean you can *solve problems*. The gap between "I learned Python" and "I can build / interview with Python" is closed only by deliberate practice ā LeetCode, HackerRank, real projects, code reviews. This page is your roadmap.
Reading code teaches you syntax. Solving problems teaches you judgement: choosing the right data structure, recognising patterns, debugging under pressure. The skill compounds ā the 200th problem feels easier than the first 20 combined.
Goal: solve problems *consistently*, not heroically. 1 problem a day for a year beats 20 in a weekend then nothing.
1. Read twice. Identify inputs, outputs, constraints, and at least one example by hand. 2. Restate the problem in your own words. 3. Brute force first. Even an O(nĀ³) solution is something. Don't let perfect block any. 4. Optimise. Where's the wasted work? Repeated computation ā cache. Repeated lookups ā hash map. Sorted scan possible ā sort. 5. Code carefully. One small, named helper at a time. 6. Test on edge cases. Empty input, one element, duplicates, negatives, max size. 7. Reflect. After solving, write 2 lines: pattern, mistake, what to remember.
Look at the input size to pick a target:
| n | Target | Common patterns |
| ā¤ 10 | brute force | recursion, permutations |
| ā¤ 20 | O(2āæ) | bitmask DP, backtracking |
| ā¤ 1,000 | O(nĀ²) | nested loops, DP grid |
| ā¤ 10āµ | O(n log n) | sorting, binary search, divide & conquer |
| ā¤ 10ā¶ | O(n) | hash map, two pointers, sliding window, prefix sums |
| ā¤ 10ā¹ | O(log n) / O(ān) | math, binary search on answer |
1. Watching solutions before trying. You learn by struggling for 20ā30 minutes first; *then* peek. 2. Skipping easy problems. "Easy" tags exist to drill fundamentals. Get fast there before chasing hards. 3. No edge-case checklist. Empty, single, duplicates, sorted reverse, max size ā always. 4. Not measuring. Time yourself. Can you re-solve a problem you saw last week in 15 minutes? 5. Cargo-culting cool tricks. A clean O(nĀ²) you understand beats an O(n) you can't explain in an interview. 6. Only LeetCode, no projects. Real projects teach what interviews can't ā messy data, vague specs, deployment.
from collections import Counter, defaultdict, deque
import heapq, bisect, math, itertools, functoolsCounter("abracadabra").most_common(2)
bisect.insort(sorted_list, x) # binary insert
heapq.nsmallest(3, nums) # top-3 smallest
functools.lru_cache(maxsize=None) # memoise
defaultdict(list) # group-by
deque(maxlen=k) # fixed-size sliding window
itertools.pairwise([1,2,3,4]) # (1,2),(2,3),(3,4)
for i, x in enumerate(arr): ...
for a, b in zip(arr, arr[1:]): ...
int("abc123".isdigit()), s.count("a"), sorted(s)
These 10 lines cover an embarrassing fraction of LeetCode mediums.
When your code fails:
1. Run the failing example by hand, line-by-line, with a notebook. 2. Print intermediate state, not just the final return. 3. Reduce to the smallest failing input. 4. Fix the root cause, not the symptom.
If you've stared for 15 minutes with no progress, take 5 minutes off the screen. New ideas surface in the silence.
Keep a personal log: problem name, pattern, mistake, link. Re-solve flagged problems after 1 day, 1 week, 1 month. This *compounding review* is what separates people who "have done" 500 problems from people who can solve them under pressure.
Tools: a spreadsheet, an Anki deck, or a simple markdown file.
Interviews aren't the only judge. Build:
argparse / typer) that does something useful.requests, pandas, streamlit).1. Solve Two Sum from scratch in O(n) using a dict; explain to yourself why a brute O(nĀ²) version fails on n = 10āµ. 2. Solve a sliding window problem (e.g., longest substring without repeating chars); practice growing/shrinking the window. 3. Re-solve a problem you struggled with 3 days ago; aim for under 15 minutes. 4. Pick a 1-week mini-project (CLI, scraper, or small API) and ship it to GitHub with a README.