Before you write a single sorting algorithm, get the boring logistics out of the way: which platforms to use, which Python to submit with, and how to practice so the effort actually compounds instead of evaporating.

What you’ll learn

• Which accounts to create — LeetCode, Codeforces, HackerRank — and what each one is actually good for.
• CPython vs PyPy: which one to submit with on a competitive-programming judge.
• When to practice in-browser here vs setting up Python locally.
• A repeatable, pattern-based, spaced-repetition practice routine.
• A fast-I/O main()main() template you’ll reuse for almost every CP problem.

Create your accounts

Each platform rewards a different kind of practice:

Sign up for all three — you don’t need to be active everywhere, but you’ll run into each one eventually (a recruiter sends a HackerRank test, an interview prep plan lives on LeetCode, a contest happens on Codeforces).

CPython vs PyPy

CPython — the standard interpreter you’re already running in this browser — is what almost every interview platform (LeetCode, HackerRank) gives you, and it’s usually fine because their time limits are set with Python in mind.

Codeforces and some judges also offer PyPy 3, which uses a JIT compiler and can be 10-50x faster on tight numeric loops. If a Codeforces problem’s time limit feels impossibly strict for a correct $O(n)$ solution in Python, resubmit with PyPy before assuming your algorithm is wrong.

Local setup vs practicing here

Every pythonpython code block on this site runs for real in your browser via Pyodide — click Run, edit, re-run. That’s enough for learning concepts, drilling patterns, and testing edge cases quickly.

For serious CP (and to match what a real judge sees) it’s worth installing Python 3.11+ locally too, plus an editor with good autocomplete. Many Codeforces regulars also install a browser extension like Competitive Companion to parse sample tests straight into a local file — nice, but entirely optional to get started.

A repeatable practice routine

The single biggest mistake in early DSA practice is grinding problems randomly. Practicing by pattern — sliding window, two pointers, binary search on answer, and so on — and revisiting old problems on a schedule (spaced repetition) beats raw problem count almost every time.

  graph TD
    A["Pick a pattern
e.g. two pointers"] --> B["Solve 3-5 problems
on that pattern"]
    B --> C{"Solved under time?"}
    C -- Yes --> D["Note the trigger words
add to your cheatsheet"]
    C -- No --> E["Read the editorial,
re-solve from scratch in 2 days"]
    D --> F["Move to the next pattern"]
    E --> F
    F --> G["Weekly: redo 2 old problems
(spaced repetition)"]
    G --> A

The Interview Patterns phase later in this track names all ~15 patterns explicitly, so this workflow has a concrete list to walk through.

A fast-I/O template

A real judge feeds your program input through stdin. This track’s playground can’t attach a real stdin, so the template below simulates it with a string — but the parsing shape (sys.stdin.read().split()sys.stdin.read().split()) is exactly what you’ll paste into a real submission.

import sys
 
def main():
    # On a real judge you'd read everything at once for speed:
    #   data = sys.stdin.read().split()
    # Here we simulate that input so the template still runs in-browser.
    simulated_input = "5\n3 1 4 1 5\n"
    data = simulated_input.split()
 
    it = iter(data)
    n = int(next(it))
    nums = [int(next(it)) for _ in range(n)]
 
    print("n    =", n)
    print("nums =", nums)
    print("sum  =", sum(nums))
 
main()

import sys
 
def main():
    # On a real judge you'd read everything at once for speed:
    #   data = sys.stdin.read().split()
    # Here we simulate that input so the template still runs in-browser.
    simulated_input = "5\n3 1 4 1 5\n"
    data = simulated_input.split()
 
    it = iter(data)
    n = int(next(it))
    nums = [int(next(it)) for _ in range(n)]
 
    print("n    =", n)
    print("nums =", nums)
    print("sum  =", sum(nums))
 
main()

Practice

Drill 1 — parse fast. Turn a raw line of space-separated numbers into a list of ints in one pass, the way you will at the top of almost every CP solution.

Drill 2 — track your patterns. Practicing by pattern means knowing which ones you’ve drilled enough. Complete a check for “have I solved this pattern at least 3 times?“.

Drill 3 — the template in miniature. Fill in the missing piece of the fast-parse-then-reduce shape you’ll use constantly.

Recap

• LeetCode for interview patterns, Codeforces for rated contests and editorials, HackerRank for hiring tests.
• CPython is fine for interviews; on Codeforces, submit PyPy 3 if a correct solution is timing out.
• Practice here for fast iteration; install Python locally too once you’re serious about CP.
• Practice by pattern, not randomly, and revisit old problems on a schedule.
• The fast-I/O main()main() shape above gets a full upgrade — real sys.stdinsys.stdin, buffered output — in Phase 2: Python for DSA & CP.

Next: Big-O and Complexity Deep Dive — the language you’ll use to reason about every solution from here on.