DEV Community: Ameer Abdullah

PyCodeIt: A Free Platform to Master Python Tracing and SQL for Technical Interviews with Game feature implemented.

Ameer Abdullah — Sat, 26 Sep 2026 18:21:19 +0000

PyCodeIt: A Free Platform to Master Python Tracing and SQL for Technical Interviews

If you've ever frozen in an interview when asked "what does this code print?", you already know why dry-run tracing matters. It's the skill of mentally executing code line by line — tracking variables, scope, and state — without ever hitting run. It's also exactly what interviewers test, and it's rarely taught well.

I built PyCodeIt to fix that. It's 100% free, runs entirely in the browser, and covers both Python tracing and SQL querying.

Core Features

Python Code Tracer
A frame-by-frame simulator that walks through code execution step by step — variable scope, mutable defaults, closures, decorators, and loops — so you learn why the output is what it is, not just what it is.

SQL Playground (WASM SQLite)
Write real SQL queries against live in-browser databases (HR, e-commerce, and competition schemas) using a WebAssembly SQLite engine. No backend calls, instant results.

AI Tutor
A chat-based tutor available per lesson with trace, hint, and correct commands — context-aware help exactly where you're stuck.

Daily Challenges & Game Mode
Build streaks, earn XP, and climb the leaderboard with daily trace puzzles.

Structured Learning Paths

Python: 100+ topics from variables and loops through decorators, closures, and OOP
SQL: 200+ queries from basic SELECT through window functions (ROW_NUMBER, RANK, LAG, LEAD) and recursive CTEs

Vision Lab
A newer addition covering digital image processing fundamentals — intensity transforms, histogram equalization, contrast enhancement, and color-space conversions.

Interview Mode & Blog
Scenario-based practice modeled after FAANG-style data engineering rounds, plus in-depth written guides on tracing, joins, and window functions.

Embeddable Profile Widget
Copy an iframe from your dashboard to show your live XP, streak, and accuracy on any portfolio or GitHub README.

Why It's Different

Most coding platforms let you run code and check the output. PyCodeIt forces you to predict the output first — which is the actual skill interviewers are grading. No installs, no signup required to start practicing; an account just unlocks XP tracking and streaks.

Tech stack: Next.js 15, React 19, Supabase.

Try it free: pycodeit.com

Feedback, bug reports, and feature requests are always welcome in the comments 👇

Level Up Your Python & SQL Interview Skills for Free with PyCodeIt

Ameer Abdullah — Tue, 22 Sep 2026 00:52:52 +0000

Technical interview prep often hits the same wall: high-priced subscription tiers, paywalled problem explanations, and heavy local setup requirements. PyCodeIt provides an accessible alternative by offering 100% free, interactive interview training directly in your browser.Why Check Out PyCodeIt?No Setup or Installs Required: Everything executes client-side and server-side seamlessly. The interactive SQL sandbox runs on in-browser WebAssembly (WASM SQLite), eliminating database configuration friction.Deep Python Execution Focus: Rather than just solving generic algorithmic puzzles, the platform emphasizes dry-run code tracing, mutable defaults, scoping, closures, decorators, and internal execution logic.1,400+ Curated Challenges: Practice across fill-in-the-blank problems, dry-run tracing drills, and SQL scenarios tailored for data roles and software engineering technical screens.Gamified Daily Practice: Build consistent coding habits with daily games (like Code Snake), streak tracking, XP milestones, and community leaderboards.If you are preparing for coding screens, data analyst assessments, or simply want to sharpen your mental model of Python internals without paying for premium platforms, explore PyCodeIt's Practice Hub.

Also don't forget to see 2 newly added features.Here

New Game Feature on PyCodeIt

Ameer Abdullah — Fri, 18 Sep 2026 18:16:31 +0000

Hello everyone,
A new feature updated for PyCodeIt
And that is game feature. Now you can play concepts related games also.
Explore and provide feedback.

Attention Needed and Feedback Needed.

Ameer Abdullah — Mon, 14 Sep 2026 17:30:01 +0000

Hi Everyone,

PyCodeIt is refactored further.
Kindly visit it and use it and provide your valuable suggestions and feedback for long term health of this website.

I need Feedback and Few Suggestions on PYCODEIT

Ameer Abdullah — Thu, 20 Aug 2026 10:13:24 +0000

To all developers, students, professors, instructors, professional individuals in IT field or specialist or freshersin AI domain or open to anyone...

I need your genuine feedback on PYCODEIT. Just visit it and explore it. Comment down your valuable feedback/suggestions in improving this website. It could be any feature that you think might really help in for individuals preparing for interviews or overall practice or in learning purposes. I want to make this website scalable. Right now, we are stick to python and SQL and I need to refactor it more efficiently and effectively, then we will move towards more languages including AI/ML domain.

You can suggest new topics, articles to write on, visual explanation or anything else in python and SQL or new features to make it more user friendly.

NULLs: The Behavior Most Candidates Get Wrong

Ameer Abdullah — Wed, 19 Aug 2026 19:43:11 +0000

NULL in SQL represents the absence of a value, not zero or an empty string. It propagates through arithmetic and comparisons in ways that surprise developers coming from Python or JavaScript. Any arithmetic involving NULL produces NULL. Any comparison using = or != against NULL returns UNKNOWN, not TRUE or FALSE.

Use IS NULL and IS NOT NULL to test for missing values, never = NULL.

COUNT(*) counts all rows including NULLs; COUNT(column) skips NULLs in that column.

COALESCE returns the first non-NULL value in its argument list and is the standard way to substitute a default.

NULL values sort last in ascending order in PostgreSQL; behavior varies by database engine.

Two rows with NULL in the join column will not match each other, which removes them from INNER JOINs.

Visit PyCodeIt

New Update for the PYCODEIT

Ameer Abdullah — Sun, 16 Aug 2026 19:24:55 +0000

Hey Everyone,

For the past few days, I was extremely busy in work overall.

So, website has been refactored and there is no need to have access to API which might be a security concern over the users.

I request everyone to visit pycodeit once, explore and use it. It would be so kind of your's precious time and generous feedback in keep improving it.

Regards,

Five Python Patterns Every Developer Should Be Able to Trace on Sight

Ameer Abdullah — Thu, 30 Jul 2026 19:00:00 +0000

After analyzing hundreds of Python interview questions and production bug reports, five patterns account for the majority of prediction errors and bugs that experienced developers encounter.

If you can trace each of these on sight, without hesitation, you are prepared for virtually any Python dry-run question.

Pattern 1: The Shared Mutable Default

def build_list(item, container=[]):
    container.append(item)
    return container

r1 = build_list("a")
r2 = build_list("b")
r3 = build_list("c", [])
print(r1)
print(r2)
print(r3)

Output:

['a', 'b']
['a', 'b']
['c']

r1 and r2 share the default list because it is created once at function definition time. r3 receives a new empty list explicitly so it is independent.

Trace rule: any call that does not pass the second argument shares the single default object.

Pattern 2: The Generator That Forgets

def make_gen(n):
    for i in range(n):
        yield i * 2

g = make_gen(4)
first_half = list(g)[:2]
second_half = list(g)
print(first_half)
print(second_half)

Output:

[0, 2]
[]

list(g) exhausts the generator. The first list(g) produces [0, 2, 4, 6] and then takes the first two elements. The generator is now exhausted. The second list(g) finds no remaining values.

Trace rule: calling list() on a generator always consumes it entirely.

Pattern 3: The Class Variable Mutation

class Registry:
    items = []

    @classmethod
    def register(cls, item):
        cls.items.append(item)

Registry.register("first")
r = Registry()
r.register("second")
Registry.register("third")
print(Registry.items)
print(r.items)

Output:

['first', 'second', 'third']
['first', 'second', 'third']

All three registrations go to the same class-level list. The instance r has no instance attribute items so it reads the class attribute. Both Registry.items and r.items reference the same list.

Trace rule: class variables are shared unless overridden by instance assignment.

Pattern 4: The Late Binding in a Loop

multipliers = {}
for i in range(1, 4):
    multipliers[i] = lambda x: x * i
print(multipliers[1](10))
print(multipliers[2](10))
print(multipliers[3](10))

Output:

30
30
30

All three lambdas close over the same variable i. By the time they are called, the loop has finished and i is 3. Every lambda returns x * 3 regardless of which key you use.

Fix:

multipliers[i] = lambda x, i=i: x * i

The default parameter captures the current value of i at lambda creation time.

Pattern 5: The Chained Comparison With Side Effects

def check(n):
    print(f"checking {n}")
    return n

result = 1 < check(2) < 3
print(result)

Output:

checking 2
True

Python evaluates check(2) once and reuses the result in both comparisons. It does not call check twice. The expression becomes 1 < 2 and 2 < 3 which is True and True which is True.

This matters in production code when the middle expression has side effects: it runs exactly once.

The Unified Mental Model

All five patterns follow from the same underlying principle: Python names are references to objects, and the behavior you observe depends on whether operations create new objects or modify existing ones.

Default arguments, class variables, and closure variables are all cases where a single object is referenced from multiple places. Late binding is a case where the reference is resolved at call time, not at definition time. Chained comparison is a case where Python optimizes to avoid redundant evaluation.

Once you internalize references versus objects as your mental model, each pattern becomes predictable rather than surprising.

For daily practice on all five patterns and hundreds of variations, visit pycodeit.com. Free, no account needed to start.

Solving the Division Problem in SQL and Relational Algebra Using Python Reasoning

Ameer Abdullah — Mon, 27 Jul 2026 19:00:00 +0000

The division operation in relational algebra is considered the hardest concept in undergraduate database courses. Most students memorize the formula without understanding it.

Here is the insight that makes it immediately clear: it is the same problem as the "participated in all competitions" query, and you can reason about it using the same logic you use to trace Python code.

The Problem in Plain English

Given two tables: the first contains (participant, competition) pairs recording who competed where. The second contains all competitions. Find all participants who competed in every single competition.

This is called the division problem. In relational algebra, the answer is:

Result = Participant_Competition ÷ Competition

In SQL, there is no division operator. You must simulate it.

The Python Reasoning

Imagine you are writing Python to solve this.

You have a dictionary mapping each participant to the set of competitions they entered. You want to find participants whose set of competitions is a superset of all competitions.

from collections import defaultdict

entries = [("Alice", "C01"), ("Alice", "C02"), ("Alice", "C03"),
           ("Bob", "C01"), ("Bob", "C03"),
           ("Carol", "C01"), ("Carol", "C02"), ("Carol", "C03")]

all_competitions = {"C01", "C02", "C03"}

participant_comps = defaultdict(set)
for person, comp in entries:
    participant_comps[person].add(comp)

result = [p for p, comps in participant_comps.items()
          if comps >= all_competitions]

print(result)  # ['Alice', 'Carol']

comps >= all_competitions checks whether comps is a superset of all_competitions. Alice and Carol entered all three. Bob only entered two.

Translating This to SQL

The SQL version uses a different formulation: find participants for whom there is no competition they did NOT enter.

SELECT p.name
FROM Participant p
WHERE NOT EXISTS (
    SELECT c.CID
    FROM Competition c
    WHERE NOT EXISTS (
        SELECT 1
        FROM CompetitionTeam ct
        JOIN TeamMember tm ON ct.TeamID = tm.TeamID
        WHERE tm.PID = p.PID
        AND ct.CID = c.CID
    )
);

Reading the logic: "Find participants p such that there is no competition c for which p has no entry."

Double negation. The outer NOT EXISTS means "there does not exist a competition that..." and the inner NOT EXISTS means "p did not compete in."

The Count-Based Alternative

A cleaner version for most interview settings:

SELECT p.PID, p.Name
FROM Participant p
JOIN TeamMember tm ON p.PID = tm.PID
JOIN CompetitionTeam ct ON tm.TeamID = ct.TeamID
JOIN Competition c ON ct.CID = c.CID
WHERE YEAR(c.Date) = 2025
GROUP BY p.PID, p.Name
HAVING COUNT(DISTINCT ct.CID) = (
    SELECT COUNT(*) FROM Competition WHERE YEAR(Date) = 2025
);

This groups each participant's distinct competition entries and compares the count to the total number of competitions. If they match, the participant entered all of them.

The count approach is easier to write and explain. The NOT EXISTS approach is more semantically accurate to the division operation.

Why Python Developers Find This Easier

Python thinking about sets and membership naturally maps to the SQL division problem. The >= superset check in Python is exactly the same logic as "no competition they did not enter" in SQL. The double negation in SQL is the relational way to express the Python not in pattern.

If you think of SQL queries through the lens of "what Python code would produce this result," complex queries become much easier to reason about.

Practice SQL and Python problems side by side at pycodeit.com. The hard interview prep mode includes division-style problems in both Python and SQL formats.

How to Write Python Code That Is Both Correct and Readable Under Interview Pressure

Ameer Abdullah — Sat, 25 Jul 2026 19:00:00 +0000

Most interview preparation focuses entirely on correctness: write code that produces the right output. Far less attention goes to the habits that make code readable and communicable under pressure.

This matters because interviewers are not just checking whether your code works. They are evaluating whether they would want to review your pull requests.

The Naming Discipline

Under pressure, developers often revert to single-letter variable names that save a few keystrokes but obscure intent.

# Under pressure version
def f(l):
    r = []
    for i in l:
        if i % 2 == 0:
            r.append(i * 2)
    return r

# Readable version
def double_even_numbers(numbers):
    result = []
    for number in numbers:
        if number % 2 == 0:
            result.append(number * 2)
    return result

The second version takes about 10 seconds longer to type. The interviewer who reads it understands immediately what each line does. The interviewer reading the first version has to build their own mental model.

Practice using descriptive names even in practice sessions so that it becomes the default under pressure.

Communicating Before You Type

The most common mistake in coding interviews is starting to type before you understand the problem. This produces half-started solutions, backtracking, and visible confusion.

A better sequence:

Step 1: Repeat the problem back in your own words. "So I need to find all participants who competed in every 2025 competition, not just some of them."

Step 2: State your approach before typing. "I'll count distinct competitions per participant and compare to the total."

Step 3: Write the code, narrating as you go. "This JOIN connects participants to their teams, this one connects teams to competitions."

Step 4: Trace through a simple example after writing. Do not just say "I think this works." Show that it works by running through the logic manually.

This sequence takes about 60 to 90 extra seconds and consistently produces better impressions than jumping straight to code.

The Early Return Pattern

# Deeply nested version
def validate_user(user):
    if user:
        if user.get("age"):
            if user["age"] >= 18:
                if user.get("email"):
                    return True
    return False

# Early return version
def validate_user(user):
    if not user:
        return False
    if not user.get("age"):
        return False
    if user["age"] < 18:
        return False
    if not user.get("email"):
        return False
    return True

The second version is easier to trace because each condition is independent. You can verify each guard clause separately without tracking multiple levels of nesting.

Interviewers notice this pattern because it signals that you think about code structure, not just functionality.

Handling Edge Cases Out Loud

When you encounter an edge case during an interview, state it rather than silently handling it.

"I'm going to add a check for an empty list here because if the input is empty, this would return an IndexError."

"I'm assuming the numbers are all positive integers based on the examples. If they could be negative, this comparison would need to change."

Naming edge cases demonstrates that you think defensively and that you consider the space of possible inputs rather than just the examples given.

The Self-Review Before Submitting

Develop the habit of reading your code backwards after writing it. Start at the last line and work upward.

This does not catch logical errors but it reliably catches: undefined variable names, mismatched brackets, off-by-one errors in range(), incorrect return placement, and missing edge case handling.

It takes about 20 seconds and consistently catches the category of mistakes that feel embarrassing after the interview.

Practice under timed conditions at pycodeit.com. Setting the interview simulation mode timer to 30 seconds trains exactly the pressure-handling habits this article describes.

The Complete Guide to Python's for Loop Internals

Ameer Abdullah — Thu, 23 Jul 2026 23:27:00 +0000

Every Python for loop you have ever written relies on a two-step protocol that most developers never see because Python hides it behind clean syntax.

Understanding the protocol turns for loops from black boxes into predictable, traceable mechanisms.

What Python Does With Every For Loop

for item in collection:
    process(item)

Python expands this to:

iterator = iter(collection)
while True:
    try:
        item = next(iterator)
        process(item)
    except StopIteration:
        break

iter() calls collection.__iter__() and returns an iterator object.
next() calls iterator.__next__() and returns the next value.
When the iterator is exhausted, __next__ raises StopIteration and the loop ends.

This is the iteration protocol. Any object that implements __iter__ and __next__ can be iterated.

Why This Matters for Tracing

a = [1, 2, 3]
it = iter(a)

print(next(it))  # 1
print(next(it))  # 2

for item in it:
    print(item)

Output:

1
2
3

The iterator is stateful. After calling next(it) twice manually, the iterator has consumed the first two values. The for loop continues from where the iterator left off and only sees 3.

This is why a generator, once partially consumed, resumes from its current position when you iterate it again.

enumerate: What It Actually Does

colors = ["red", "green", "blue"]
for i, color in enumerate(colors, start=1):
    print(i, color)

Output:

1 red
2 green
3 blue

enumerate(colors, start=1) creates an enumerate object that wraps the original iterator. Each call to next() on the enumerate object calls next() on the inner iterator and returns a tuple of (current_count, value).

The tuple (i, color) in the for loop uses tuple unpacking to assign both values simultaneously.

zip: Combining Two Iterators

names = ["Alice", "Bob", "Carol"]
scores = [85, 92, 78, 95]

for name, score in zip(names, scores):
    print(f"{name}: {score}")

Output:

Alice: 85
Bob: 92
Carol: 78

zip stops when the shortest iterator is exhausted. Carol's 78 is included but the fourth score 95 is dropped because there is no fourth name.

zip_longest from itertools fills with a default value instead of stopping.

The Interview Problem: Custom Iterator

class CountDown:
    def __init__(self, start):
        self.current = start

    def __iter__(self):
        return self

    def __next__(self):
        if self.current <= 0:
            raise StopIteration
        self.current -= 1
        return self.current + 1

for n in CountDown(3):
    print(n)

Trace the execution:

iter(CountDown(3)) returns the object itself because __iter__ returns self.
First next(): current is 3, returns 3, current becomes 2.
Second next(): current is 2, returns 2, current becomes 1.
Third next(): current is 1, returns 1, current becomes 0.
Fourth next(): current is 0, raises StopIteration.

Output:

3
2
1

The Exhaustion Problem

numbers = [1, 2, 3, 4, 5]
evens = filter(lambda x: x % 2 == 0, numbers)

print(list(evens))   # [2, 4]
print(list(evens))   # []

filter() returns a lazy iterator, not a list. After the first list(evens) call consumes all its values, the iterator is exhausted. The second call finds nothing remaining.

This surprises developers who treat filter, map, and zip objects as reusable sequences. They are single-pass iterators.

Practice iteration protocol tracing at pycodeit.com.

Python's Object Model in Depth: Why Two Lines That Look the Same Behave Differently

Ameer Abdullah — Thu, 23 Jul 2026 00:25:00 +0000

Two lines of code. Same variable. Same operator. Completely different behavior.

a = [1, 2, 3]
b = a
b += [4]   # line A
print(a)   # [1, 2, 3, 4]

x = 1
y = x
y += 1     # line B
print(x)   # 1

Line A changes a. Line B does not change x. The only difference is whether the variable holds a mutable or immutable object.

To understand why this happens, you need to understand how Python actually represents variables internally.

Variables Are Not Boxes

The box metaphor is how most introductory programming courses explain variables: a variable is a box that holds a value. You put 5 into the box called x. Later you can replace it with 10.

In Python this metaphor is accurate for immutable types and dangerously misleading for mutable types.

The more accurate model: a Python variable is a name that is bound to an object. The object exists independently of the name. Multiple names can be bound to the same object. Binding a name to a new object does not affect the old object or other names that reference it.

You can inspect this directly:

a = [1, 2, 3]
b = a
print(id(a) == id(b))  # True -- same object, two names

x = 5
y = x
print(id(x) == id(y))  # True -- both point to integer object 5

Both cases start the same: two names pointing to the same object. What happens next depends on whether you mutate the object or rebind the name.

Two Fundamental Operations

Every operation on a Python object falls into one of two categories.

Mutation: the object at a given memory address is modified. All names pointing to that address see the change.

Rebinding: a name is pointed at a different memory address. Other names pointing to the original address are unaffected.

List methods like .append(), .extend(), .sort(), and item assignment lst[i] = x are mutations.

Assignment with = is rebinding.

The += operator is either mutation or rebinding depending on whether __iadd__ is implemented and the object is mutable.

Tracing Through the Object Graph

a = [[1, 2], [3, 4]]
b = a.copy()     # shallow copy
b[0].append(99)
print(a)
print(b)

Output:

[[1, 2, 99], [3, 4]]
[[1, 2, 99], [3, 4]]

a.copy() creates a new outer list. So a and b are different list objects. But the elements inside them are the same inner list objects. b[0] and a[0] both point to the same [1, 2] list.

Calling .append(99) on b[0] mutates that shared inner list. Both a[0] and b[0] reflect the change because they reference the same object.

Draw this as a diagram:

a ---------> [ref_to_inner_1, ref_to_inner_2]
b ---------> [ref_to_inner_1, ref_to_inner_2]
              |
              v
              inner_1: [1, 2]  <-- both a[0] and b[0] point here

Appending 99 to inner_1 changes it to [1, 2, 99]. Both a[0] and b[0] see [1, 2, 99] because both still point to the same object.

How Function Arguments Fit This Model

def process(data):
    data = data + [99]   # rebinding -- creates new list
    return data

def process_mutating(data):
    data += [99]         # mutation -- extends existing list
    return data

original = [1, 2, 3]

result1 = process(original)
print(original)           # [1, 2, 3]

result2 = process_mutating(original)
print(original)           # [1, 2, 3, 99]

When process is called, data is bound to the same object as original. data = data + [99] creates a new list and rebinds the local name data. The original object is untouched.

When process_mutating is called, data += [99] calls list.__iadd__([99]) which extends the existing object. The original object is mutated.

The Practical Debugging Rule

When you see unexpected mutation, ask: is there another name pointing to the same object?

When you see a change not being reflected somewhere, ask: was this a rebinding operation that only affected one name?

These two questions diagnose the vast majority of Python mutation bugs faster than any debugger.

Practice tracing mutation problems at pycodeit.com.