less programmer-competency-matrix

Programmer Competency Matrix

A rough guide to where a programmer stands on 44 skills, from 2ⁿ (level 0) to log(n) (level 3). Knowledge at each level is cumulative: being at level n implies you know everything from the levels below it.

Updated in 2026. The progression held up; the specifics didn't. VSS is gone, git won, and whole areas like security, cloud, observability and AI agents were missing. The 2008 original is still around.

computer science

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
data structures
2ⁿDoesn’t know the difference between an array and a linked list
n²Able to explain and use arrays, linked lists, dictionaries etc. in practical programming tasks
nKnows space and time tradeoffs of the basic data structures, arrays vs linked lists, able to explain how hash tables can be implemented and can handle collisions, priority queues and ways to implement them etc.
log(n)Knowledge of advanced data structures like B-trees, LSM trees, binomial and Fibonacci heaps, AVL/red-black trees, splay trees, skip lists, tries, Bloom filters, HyperLogLog etc.
algorithms
2ⁿUnable to find the average of numbers in an array (it’s hard to believe but I’ve interviewed such candidates)
n²Basic sorting, searching and data structure traversal and retrieval algorithms
nTree, graph, simple greedy and divide and conquer algorithms, is able to understand the relevance of the levels of this matrix.
log(n)Able to recognize and code dynamic programming solutions, good knowledge of graph algorithms, good knowledge of numerical computation algorithms, able to identify NP-hard problems etc.
systems programming
2ⁿDoesn’t know what a compiler, linker or interpreter is
n²Basic understanding of compilers, linkers and interpreters. Understands what assembly code is and how things work at the hardware level. Some knowledge of virtual memory and paging.
nUnderstands kernel mode vs. user mode, multi-threading, async I/O and event loops, synchronization primitives and how they’re implemented, able to read assembly code. Understands how networks work, network protocols and socket level programming.
log(n)Understands the entire programming stack, hardware (CPU + memory + cache + interrupts + microcode), binary code, assembly, static and dynamic linking, compilation, interpretation, JIT compilation, garbage collection, heap, stack, memory addressing…
distributed systems

The fallacies of distributed computing are still the best one-page summary of this row.

2ⁿAssumes the network is reliable and remote calls are instant
n²Knows that remote calls fail and time out; adds timeouts and retries
nDesigns idempotent operations, understands at-least-once vs exactly-once delivery, queues, caching and cache invalidation, CAP and eventual consistency
log(n)Understands consistency models, consensus (Raft/Paxos), clocks and ordering, partitioning and replication. Designs for partial failure and can reason about what happens when any one part is slow or gone.

software engineering

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
source code version control

E.g. git: bisect, reflog, interactive rebase.

2ⁿFolder backups by date
n²Clones, commits, pushes and pulls, mostly on one branch
nComfortable with branches, rebasing, resolving merge conflicts and pull requests. Writes small commits with useful messages.
log(n)Uses history search, recovery and interactive rewriting without fear, understands how the version control system stores history, and can design the branching, review and release workflow for a team
build and CI/CD
2ⁿOnly knows how to build from the IDE
n²Can build the system and run the tests from the command line
nHas set up a CI pipeline that builds, lints and tests every pull request
log(n)Makes builds reproducible and cached; has the pipeline produce versioned artifacts and release notes, and deploy with feature flags, staged rollouts and one-step rollbacks
automated testing
2ⁿThinks that all testing is the job of the tester
n²Writes unit tests for the code they change and comes up with good test cases
nWrites tests first when it helps (TDD), uses fakes and mocks sensibly, writes integration tests against real dependencies
log(n)Uses property-based, contract, snapshot and fuzz testing where they fit; able to set up load/performance and end-to-end tests
test strategy
2ⁿTests whatever is easy to test
n²Knows the test pyramid and why most tests should be small and fast
nKeeps the suite fast and trustworthy: fixes or quarantines flaky tests, measures coverage without worshipping it
log(n)Decides what not to test, balances pre-merge tests against canaries, monitoring and testing in production, and can explain the cost of each layer

programming

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
problem decomposition
2ⁿOnly straight line code with copy paste for reuse
n²Able to break up a problem into multiple functions
nAble to come up with reusable functions/objects that solve the overall problem
log(n)Uses appropriate data structures and algorithms and writes generic, composable code that encapsulates the aspects of the problem that are subject to change.
systems decomposition
2ⁿNot able to think above the level of a single file/class
n²Able to break up the problem space and design a solution as long as it is within the same platform/technology
nAble to design systems that span multiple technologies/platforms.
log(n)Able to visualize and design complex systems with multiple product lines and integrations with external systems, including where the boundaries between teams should fall
communication

This is an often underrated but very critical criterion for judging a programmer. With teams spread across time zones, more and more of it is written: pull requests, design docs, chat threads, and now prompts to AI agents. I know of several projects that failed because the programmers could not understand what the intent of the communication was.

2ⁿCannot express thoughts/ideas to peers. Poor spelling and grammar.
n²Peers can understand what is being said. Good spelling and grammar.
nIs able to effectively communicate with peers, in person and in writing
log(n)Able to understand and communicate thoughts/design/ideas/specs in an unambiguous manner and adjusts communication as per the context
code organization within a file
2ⁿNo evidence of organization within a file
n²Methods are grouped logically or by accessibility
nCode is grouped by purpose, formatted by a formatter rather than by hand, and commented where the why isn’t obvious
log(n)The file reads top to bottom: what it’s for, the public surface first, details after. The file should look beautiful.
code organization across files
2ⁿNo thought given to organizing code across files
n²Related files are grouped into a folder
nEach physical file has a unique purpose, e.g. one class definition, one feature implementation etc.
log(n)Code organization at a physical level closely matches design and looking at file names and folder distribution provides insights into design
source tree organization

The difference between this and the previous item is in the scale of organization, source tree organization relates to the entire set of artifacts that define the system.

2ⁿEverything in one folder
n²Basic separation of code into logical folders.
nNo circular dependencies; source, generated code, docs, build config and third-party code are all organized into appropriate folders
log(n)Physical layout of source tree matches logical hierarchy and organization. The directory names and organization provide insights into the design of the system.
code readability
2ⁿMono-syllable names
n²Good names for files, variables, classes, methods etc.
nNo long functions, comments explaining unusual code, bug fixes, code assumptions. Lint-clean.
log(n)Code reads like the problem it solves: names, flow and structure make the intent obvious, so comments are left for the why – no deep nesting of conditionals or methods
defensive coding
2ⁿDoesn’t understand the concept
n²Checks all arguments and asserts critical assumptions in code
nFails fast at boundaries, validates external input at the edge, and checks every return value and error path
log(n)Uses the type system to make invalid states unrepresentable, has their own library to help with defensive coding, writes tests that simulate faults
error handling
2ⁿOnly codes the happy case
n²Basic error handling around code that can throw exceptions/generate errors
nEnsures that errors/exceptions leave the program in a good state; resources, connections and memory are all cleaned up properly
log(n)Codes to detect possible exceptions beforehand, maintains a consistent error handling strategy in all layers of code, comes up with guidelines on error handling for the entire system.
editor and tooling
2ⁿMostly uses the editor for text editing
n²Knows their way around the interface, able to use search, the menus and the debugger
nKnows keyboard shortcuts for most used operations, uses the language server for navigation and refactoring, debugs with breakpoints rather than print statements
log(n)Has shaped their environment to how they work – config, extensions, dotfiles under version control – and has written plugins or tools for it
API

E.g. the Java standard library, .NET, the browser DOM, a cloud provider’s SDK or the custom API for the application

2ⁿNeeds to look up the documentation frequently
n²Has the most frequently used APIs in memory
nVast and in-depth knowledge of the API
log(n)Has written libraries that sit on top of the API to simplify frequently used tasks and to fill in gaps in the API
frameworks
2ⁿHas not used any framework outside of the core platform
n²Has used one of the popular frameworks for the platform
nHas used more than one framework in a professional capacity and is well-versed with the idioms of the frameworks.
log(n)Has written a framework that other people use
front-end development

In 2008 I said this matrix was biased against web developers. This row is a start on fixing that.

2ⁿThinks the front end is just HTML and CSS that someone else does
n²Builds working pages and components with a framework; knows the box model, the DOM and the basics of HTTP
nBuilds accessible, responsive UIs, keeps state in one place, handles loading, error and empty states, and measures load and rendering performance
log(n)Understands how the browser parses, lays out, paints and schedules work; designs for accessibility, performance budgets and slow networks from the start, and can debug jank or layout problems from a profile
requirements
2ⁿTakes the given requirements and codes to spec
n²Comes up with questions regarding missed cases in the spec
nUnderstands the complete picture and comes up with entire areas that need to be specced
log(n)Able to suggest better alternatives and flows to given requirements based on experience
scripting

E.g. Python, Ruby, Node, PowerShell.

2ⁿNo knowledge of scripting tools
n²Shell scripts and one-liners
nA general-purpose scripting language for automation, glue code and data munging
log(n)Has written and published reusable scripts or CLI tools
database
2ⁿThinks that Excel is a database
n²Knows basic database concepts, normalization, ACID, transactions and can write simple selects
nAble to design good and normalized database schemas keeping in mind the queries that’ll have to be run, proficient in use of views, stored procedures and constraints. Knows difference between clustered and non-clustered indexes. Proficient with ORMs and knows when to drop down to SQL. Writes safe schema migrations.
log(n)Can do basic database administration, reads query plans, does performance and index optimization, writes advanced queries, able to replace cursor usage with relational SQL, understands how data and indexes are stored internally, understands replication and sharding and the tradeoffs between relational, document, key-value and columnar stores. Understands how two-phase commit works.

security

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
secure coding
2ⁿTrusts all input; secrets live in the source code
n²Knows the OWASP Top 10 – injection, XSS, CSRF – uses parameterized queries and output encoding, keeps secrets out of the repo
nDesigns authentication and authorization properly, uses a secrets manager, keeps dependencies patched and watches the supply chain (lockfiles, signing, provenance)
log(n)Can find and exploit vulnerabilities in their own and others’ code: fuzzes, reverse engineers binaries, plays CTFs, has reported or fixed real CVEs
threat modeling
2ⁿThinks security is someone else’s job
n²Asks “what could go wrong?” about the feature they’re building
nThreat-models new designs: trust boundaries, attacker goals, least privilege, blast radius
log(n)Sets security architecture and practice for a system or team, and gets real value out of pen tests and bug bounties

infrastructure and operations

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
cloud and infrastructure
2ⁿThe app runs on “the server”
n²Can deploy to a cloud provider through the console; understands VMs, storage and managed databases
nUses containers and an orchestrator or serverless platform, understands networking, DNS, load balancers and IAM, keeps an eye on cost
log(n)Designs multi-region, highly available systems, knows how each part fails, and can explain the bill
infrastructure as code

E.g. Terraform, Pulumi, CloudFormation, Dockerfiles.

2ⁿConfigures servers by hand and nobody remembers how
n²Uses scripts or container definitions to set up environments
nKeeps all infrastructure declared in code, reviewed and applied through CI
log(n)Builds reusable modules and platforms that other teams use to provision their own environments safely
observability
2ⁿDebugs production with print statements and ssh
n²Writes structured logs and basic metrics
nUses distributed tracing and dashboards, alerts on symptoms rather than causes, defines SLOs
log(n)Designs systems to be debuggable in production: can answer a new question about how the system behaves without shipping new code
incident response
2ⁿHas never been on call
n²Has been on call and can follow a runbook
nLeads incident response, writes runbooks and blameless postmortems
log(n)Designs for operability – graceful degradation, load shedding, chaos testing – and changes how the team works based on incident trends

data and ml

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
data engineering
2ⁿData lives in spreadsheets emailed around
n²Can write SQL against a warehouse and build a simple report or notebook
nBuilds reliable batch and streaming pipelines; understands schemas, data quality checks and idempotent reprocessing
log(n)Designs the data platform: lineage, governance, privacy, and the tradeoffs between warehouse, lake and streaming architectures
machine learning
2ⁿThinks ML is magic
n²Can train and use an off-the-shelf model; understands train/test splits and overfitting
nPicks features, models and evaluation metrics to suit the problem, and knows when a heuristic beats a model
log(n)Ships and runs models in production – drift monitoring, retraining, evaluation pipelines – and understands the math well enough to debug them

ai-assisted development

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
working with AI coding agents

The bar for reviewing code didn’t drop because a machine wrote it. If anything it went up.

More in the AI Agent Competency Matrix.

2ⁿPastes generated code without reading it, or refuses to try the tools
n²Uses AI completion and chat for boilerplate and explanations; reviews and tests what comes back
nGives agents the context, tests and constraints they need, breaks work into reviewable chunks, knows which tasks they’re good and bad at
log(n)Matches how much they hand an agent to the task and the risk, knows when not to use one, and builds the instructions, evals and guardrails that make more work safe to delegate

experience

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
languages with professional experience
2ⁿImperative or object-oriented
n²Imperative, object-oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and type inference
nFunctional, added bonus if they understand lazy evaluation, currying, continuations and algebraic data types
log(n)Concurrent (Erlang/Elixir, Go) and systems languages with manual or ownership-based memory management (C, Rust)
years of professional experience
2ⁿ1
n²2-5
n6-9
log(n)10+
domain knowledge
2ⁿNo knowledge of the domain
n²Has worked on at least one product in the domain.
nHas worked on multiple products in the same domain.
log(n)Domain expert. Has designed and implemented several products/solutions in the domain. Well versed with standard terms, protocols used in the domain.

knowledge

skill
2ⁿ level 0
n² level 1
n level 2
log(n) level 3
tool knowledge

E.g. grep, jq, curl, perf, strace, Wireshark.

2ⁿLimited to their primary IDE
n²Knows about some alternatives to popular and standard tools.
nGood knowledge of editors, debuggers, profilers, the command line, containers and open source alternatives
log(n)Picks the right tool for an unfamiliar problem – a profiler, a tracer, a packet capture – and can get useful answers out of it quickly
languages exposed to
2ⁿOnly the language they work in
n²Has read code in a few languages from different families
nHas written small programs in a functional, a systems and a dynamic language, and can compare their type systems and memory models
log(n)Has explored the edges – Lisp, Haskell, Prolog, Forth, APL, an assembly language – and brings ideas from them back into everyday code
codebase knowledge
2ⁿHas never looked at the codebase
n²Basic knowledge of the code layout and how to build the system
nGood working knowledge of code base, has implemented several bug fixes and maybe some small features.
log(n)Has implemented multiple big features in the codebase and can easily visualize the changes required for most features or bug fixes.
knowledge of upcoming technologies
2ⁿHas not heard of the upcoming technologies
n²Has heard of upcoming technologies in the field
nHas tried the betas and previews and read the docs and release notes
log(n)Has built something real with them and, as a bonus, shared what they learned
platform internals
2ⁿZero knowledge of platform internals
n²Has basic knowledge of how the platform works internally
nDeep knowledge of platform internals and can visualize how the platform takes the program and converts it into executable code.
log(n)Has written tools to enhance or provide information on platform internals, e.g. disassemblers, decompilers, debuggers, profilers, tracers etc.
books
2ⁿUnleashed series, 21 days series, 24 hour series, dummies series…
n²Code Complete, Don’t Make Me Think, Mastering Regular Expressions, The Pragmatic Programmer
nDesign Patterns, Peopleware, Programming Pearls, The Algorithm Design Manual, The Mythical Man-Month, A Philosophy of Software Design, Accelerate
log(n)Structure and Interpretation of Computer Programs; Concepts, Techniques, and Models of Computer Programming; The Art of Computer Programming; Designing Data-Intensive Applications; An Introduction to Database Systems by C. J. Date; Thinking Forth; The Little Schemer
blogs and writing
2ⁿHas heard of blogs and podcasts but never got the time.
n²Reads tech blogs and newsletters and listens to podcasts or talks regularly.
nKeeps and shares a collection of useful articles, notes and tools
log(n)Writes or speaks publicly about their own insights and thoughts on programming