Python Developer Skill Matrix

Uses type hints, dataclasses, exceptions, and standard patterns without overengineering.

Does not swallow errors, wraps them with context, and doesn't catch Exception without reason.

Designs dependencies through abstractions, separates domain, transport, and infrastructure layers.

Improves code structure while preserving behavior and backward compatibility.

Prefers the standard library before external dependencies where reasonable; evaluates packages by activity.

Defines package structure conventions, exception strategy, code review practices, and shared utilities.

Creates reusable components that reduce cognitive load without introducing unnecessary coupling.

Identifies architectural risks, security issues, and compatibility violations in PRs.

Sets repository structure so the team moves consistently without ad-hoc decisions.

Settles team disagreements on technical approaches through principles rather than preference.

Creates an environment where reviews add value: teach rather than nitpick, reduce risk rather than slow delivery.

Tracks debt accumulation and includes paydown in the roadmap alongside new features.

Builds an engineering handbook with justified decisions that work across different contexts.

Evaluates dependencies on stability, support, security, and lock-in risk.

Plans the evolution of standards accounting for team growth, system scale, and business direction.

Drives correct decisions without formal authority, through argument and trust.

Speaks at conferences, writes articles, contributes to open-source — builds external authority.

Adds asyncio only where justified, understands the event loop and the difference from thread-based approaches.

Passes context through the async chain correctly and responds to CancelledError.

Designs pools with bounded concurrency using asyncio.Semaphore or ThreadPoolExecutor.

Handles transient failures without overwhelming downstream services.

Identifies and eliminates unfinished tasks and open connections during review and profiling.

Chooses synchronization patterns based on throughput, latency, and production failure modes.

Uses profiling, event loop monitoring, and tracing to find concurrency issues.

Defines which pattern (gather, TaskGroup, queue, semaphore) to use in each context.

Chooses base worker, queue, and cancellation patterns so the team doesn't create unstable solutions.

Identifies risks in critical paths: deadlocks, starvation, thundering herd.

Ensures CI covers critical async scenarios and that task leaks are detected.

Makes informed decisions considering GIL, CPU vs I/O bound load, and deployment context.

Chooses load-limiting models across multiple services and teams.

Defines how to scale parallel processing without degrading adjacent systems.

Sets principles for graceful degradation and circuit breaking at domain level.

Conducts architectural analysis for hidden race conditions and deadlock risks in integrations.

Uses JOINs, WHERE clauses, indexes, and parameterized queries; avoids SQL injection.

Creates Alembic migrations, understands application order and schema change reversibility.

Reads EXPLAIN, adds indexes, eliminates N+1, rewrites subqueries as JOINs where needed.

Normalizes data sensibly, considers nullable, constraints, and deletion scenarios.

Chooses the right isolation level, avoids deadlocks and long-running transactions.

Defines naming conventions, required indexes, nullable rules, and migration workflow.

Applies zero-downtime patterns: expand-contract, column backfill over multiple deploys, lock-free alter.

Decides when to use read replicas, caching, or event sourcing instead of classical CRUD.

Configures SQLAlchemy/asyncpg pool settings, controls max connections and health checks.

Ensures migrations are tested, reversible, and won't cause production degradation.

Coordinates database changes across multiple services and teams.

Defines who adds indexes, how schema review works, and who owns performance regression.

Restricts or approves DROP, NOT NULL without default, full-table lock changes during peak hours.

Chooses between SQL, NoSQL, and mixed storage based on load, structure, and SLOs.

Plans partitioning, sharding, and geo-distribution at platform level.

Defines RPO/RTO, tests recovery, and builds runbooks for data incidents.

Forecasts volume growth, storage costs, and initiates architectural changes in time.

Ensures GDPR, retention policy, and audit trail compliance across multiple systems.

Understands at-least-once semantics, doesn't lose or duplicate messages without reason.

Publishes events with the required structure and handles send errors.

Handles duplicates via a deduplication key or idempotent database operations.

Configures DLQ, lag alerts, and a reprocess procedure for broken messages.

Sets up consumer lag monitoring, identifies and eliminates accumulation causes.

Chooses outbox, saga, or choreography based on consistency requirements.

Establishes event schemas, versioning strategy, and backward/forward compatibility.

Justifies the choice understanding tradeoffs: latency, coupling, failure isolation, observability.

Defines which broker and pattern to use in each scenario and documents decisions.

Ensures lag, DLQ growth, and partition skew alerts; sets up on-call runbooks.

Coordinates event schema changes between producer and consumer teams.

Maintains an event registry, aligns on breaking changes, and organizes contract testing.

Chooses brokers, delivery patterns, and retention policy for the entire domain.

Defines where to store the event log, how to build projections, and how to ensure replay.

Defines exactly-once or idempotency levels for critical business operations.

Analyzes cascade failure, ordering issues, and distributed transaction risks.

Separates build and runtime stages, avoids copying unnecessary artifacts into the final image.

Runs dependencies (DB, queues, services) locally, understands volumes and network namespaces.

Orders instructions correctly for layer caching, uses .dockerignore.

Implements a /healthz endpoint, handles SIGTERM, and waits for active requests to complete.

Reads logs, checks resources, inspects the filesystem, and uses exec in prod-like environments.

Defines base images, linting rules, and a review checklist for container artifacts.

Ensures local Compose and the production environment differ as little as possible.

Runs trivy/grype, tracks CVEs in base images, enforces non-root user.

Selects and maintains golden images, manages their updates and team notifications.

Defines runtime policy: non-root, read-only filesystem, resource limits, seccomp.

Ensures regular updates of base images and pip/uv dependencies with vulnerability checks.

Adds automated image scanning to the pipeline, configures severity thresholds and notifications.

Chooses runtime (Docker, containerd), orchestration, and image registry strategy.

Standardizes approved base images, enforcement mechanisms, and update processes.

Standardizes log format, metrics exposition, and tracing injection at platform level.

Produces RFCs and ADRs for platform decisions, obtains buy-in from team tech leads.

Understands CI steps — lint, test, build, deploy — and knows what each does and where to find failure causes.

Finds the root cause of unstable tests: race conditions, ordering dependencies, or external services.

Sets up lint, test, build, and deploy steps with the right environment variables and secrets.

Parallelizes steps, caches pip/uv packages and dependencies, reduces cold start time.

Rolls out changes gradually and can roll back without downtime.

Chooses rolling, canary, or blue/green based on SLO, traffic volume, and criticality.

Defines mandatory steps: lint, security scan, test coverage, smoke test after deploy.

Documents and tests the rollback procedure, ensures the team can roll back under pressure.

Blocks deploys on coverage regression, CVEs above threshold, or failing smoke tests.

Defines what production-ready means: checklist, approvals, observability requirements.

Balances delivery speed with risk control: who approves, when it's automatic.

Ensures every service has a healthcheck, metrics, alerts, runbook, and documentation before deploy.

Coordinates release windows, feature flags, and dependencies in joint deliveries.

Chooses the deployment model and CI/CD tooling at multi-team level.

Sets principles for feature flags, traffic splitting, and automated rollback at platform level.

Defines acceptable build time, flaky test ratio, and MTTR for CI infrastructure.

Defines rules for hot fixes, emergency deploys, and change freezes balancing speed and safety.

Measures DORA metrics, finds constraints, and initiates improvements at platform level.

Covers happy path and main error branches without testing implementation details.

Structures test cases via @pytest.mark.parametrize, avoids duplication, keeps tests readable.

Uses Testcontainers or in-memory DB — tests real behavior, not just mocks.

Chooses between unittest.mock and HTTP stubs (respx, httpretty) depending on the test level.

Measures function performance via pytest-benchmark and tracks regressions.

Sets the balance between unit, integration, and e2e tests accounting for speed and confidence.

Uses Pact or schema-based approach to verify compatibility between services.

Distinguishes useful coverage from meaningless, focuses on critical scenarios.

Embeds dependency injection and clear boundaries in design so testing doesn't require heroics.

Defines what a PR must have: minimum coverage, required scenarios, performance tests.

Ensures every incident results in a test that prevents recurrence.

Reviews and deletes tests that only slow CI without improving confidence.

Tracks known coverage gaps and includes remediation in the roadmap.

Defines how the combined test suite across levels ensures delivery confidence.

Defines load testing, chaos engineering, and failure injection requirements for critical systems.

Implements systematic failure experiments to find weaknesses before production incidents.

Sets technical launch conditions for services with high SLOs: tests, load, DR.

Logs enough to understand runtime behavior, without sensitive data or noise.

Reads existing Grafana dashboards and understands basic RED metrics for their service.

Reads distributed traces, correlates logs, and isolates bottlenecks or regressions.

Creates alerts on error rate, p95 latency, and saturation with correct thresholds and runbooks.

Distinguishes p50 from p99, understands tail latency and the effect of GIL and GC on graphs.

Chooses meaningful quality indicators, aligns targets with product, and sets error budgets.

Defines naming standards, labeling, and cardinality limits for Prometheus.

Instruments services with correct span context, baggage, and sampling strategy.

Writes blameless postmortems, identifies systemic causes, and defines action items.

Defines the mandatory minimum: what to log, which metrics to instrument, how to trace.

Regularly reviews alerts: removes noise, improves thresholds, adds runbooks.

Ensures every service has a runbook, alerts with descriptions, and an escalation path.

Normalizes blameless review, tracks action item completion, and shares learnings with the team.

Builds a unified approach to SLOs, error budgets, and incident management for the entire domain.

Establishes dependency SLAs between teams, links budgets to delivery priorities.

Defines platform tools for collecting, storing, and visualizing observability data.

Creates a system where production signals regularly influence team priorities.

Defines severity levels, escalation matrix, communication protocol, and learning system for incidents.

Splits a task into clear steps and clarifies ambiguities before starting work.

Doesn't stay stuck silently for more than a day — signals the blocker and proposes options.

Defines the approach, aligns on it, and brings it to production without losing intermediate steps.

Proposes a concrete option with tradeoffs rather than asking an open-ended 'how do I do this'.

Keeps tasks up to date and prioritizes within the sprint goal independently.

Notices system problems and proposes solutions without waiting for someone to file a ticket.

Runs multiple tasks simultaneously without losing context or creating a team bottleneck.

Moves forward with incomplete information, records assumptions, and is ready to revise.

Manages the technical backlog, sets direction, and maintains pace without daily management.

Balances new features, tech debt, and reliability work in a business context.

Independently assesses and mitigates technical risks; escalates only significant ones.

Helps the team move forward without taking over others' work entirely.

Identifies what problems matter and initiates work without external prompting.

Identifies systemic problems and organizes multiple teams to solve them.

Keeps long-term risks in focus: vendor lock-in, architectural debt, skill gaps.

Drives decisions through argument, trust, and engaging key stakeholders.

Sees and manages technical strategy 12–24 months ahead.

Describes what changed, why, and how to verify — reviewers shouldn't reconstruct context.

Follows the agreed format, describes the essence of the change rather than the work process.

Explains why this solution was chosen and what alternatives were considered.

Adds a comment about 'why', not 'what' — where the logic isn't self-evident.

Updates status, adds discussion outcomes, doesn't leave tasks in an undefined state.

Describes the problem, proposal, alternatives, and risks to get quality feedback.

Documents significant architectural decisions with context so future engineers understand 'why'.

Chooses the right format: RFC, design doc, spike summary — based on complexity and audience.

Creates templates and checklists and explains the value of good artifacts to the team.

Returns context-free PRs and tickets for rework; sets expectations by example.

Translates technical decisions into business language: risks, timelines, impact.

Promotes async-first, decision documentation, and process transparency in the team.

Defines when an RFC is needed, how it is reviewed, and how decisions are recorded and accessible.

Adapts a technical document for engineers, management, and external partners.

Creates a system where important decisions are accessible, understandable, and justified for the whole organization.

Writes principles, manifesto, and best practices that become a reference point for teams.

Updates run instructions, env variables, and dependency information with every change.

Describes the purpose of env variables, valid values, and default behavior.

Describes how to start, stop, roll back, and diagnose a service in production.

Keeps the OpenAPI spec in sync with the code on every contract change.

Describes routine operations: migrations, planned restarts, secret rotation.

Syncs diagrams and descriptions with the actual system state, prevents staleness.

Creates a document that lets a new engineer quickly get context and become productive.

Organizes documentation so what's needed is easy to find and stays current.

Defines structure, required sections, and update process for different document types.

Ensures every production service has a runbook, alert descriptions, and escalation path.

Chooses tools and processes for accumulating and sharing knowledge within the team.

Ensures documentation meets external requirements: security reviews, vendor audits.

Sets how knowledge is accumulated, structured, and transferred between teams.

Ensures cross-team architectural decisions are recorded and accessible.

Establishes runbook, postmortem, and incident report standards across multiple teams.

Shares team experience through blogs, conferences, and open-source — builds external technical authority.

Communicates what's done, what's left, and whether there are blockers — without needing prompts.

Clarifies requirements before starting work rather than reworking after finishing.

Adapts the level of detail to the audience without diving into implementation details when results matter.

Gives specific, actionable feedback — identifies the problem and suggests a path to resolution.

Raises issues directly and without aggression; accepts criticism without defensiveness.

Structures discussions, keeps focus, and helps the group reach a concrete conclusion.

Syncs regularly, keeps partners informed, and avoids surprises.

Finds compromise or persuades with arguments without involving management unnecessarily.

Speaks for the team at cross-team meetings, communicates priorities and constraints.

Regularly translates technical priorities and risks into language non-technical managers understand.

Signals risks, schedule changes, and technical decision impacts in advance.

Helps team members resolve disagreements and creates a safe space for discussion.

Creates an environment where people aren't afraid to share ideas, admit mistakes, or ask questions.

Represents technical positions at director, partner, and external audience level.

Creates forums for knowledge sharing and solving common problems between teams.

Convinces key stakeholders of the need for change and builds a coalition of support.

Provides clear direction to the team and partners while strategy is still forming.

Speaks at conferences, runs a technical blog — builds the company's reputation in the engineering community.