Software engineering · Level 1 of 5
Junior Software Engineer job description
This is what Software engineering teams expect from a Junior Software Engineer. 40 skills, each with the mastery level set for this rung. It is the same framework Competrace ships to new customers, so you can read it here and import it as-is.
Delivers well-scoped tasks with review and regular guidance.
Junior Software Engineer only.
Software engineering — Junior Delivers well-scoped tasks with review and regular guidance. REQUIRED SKILLS Software Development - Programming and Build — You can design, write, test and document a small program or script from a written specification, working under direction. Your changes pass review with minor comments, and you follow the build and packaging steps without needing them explained again. - Modern Development Standards — You can explain the main principles behind the team development standards and apply them to your own work once someone points you at the right practice for the situation. - Code Review — You can review routine changes in your team codebase, spot missing tests and error handling, and separate a blocking objection from a preference. You take review on your own work without defensiveness. - Debugging and Diagnosis — You can diagnose defects in code you work on regularly, form a hypothesis before changing anything, and confirm a fix by reproducing the original failure and watching it stop. - Refactoring — You can rename, extract a function and delete dead code safely when a reviewer or a test suite confirms the behaviour is unchanged. - Version Control — You can keep a tidy local history, write commit messages that explain why, resolve routine conflicts yourself, and recover from a mistake with revert or reflog rather than starting the work again. - API Design — You can add an endpoint or method that follows the patterns already in the codebase, and you can read an API specification and say what a given call will return. Testing and Quality - Test Design — You can select suitable test types for routine work with some support, and design cases covering the happy path, the boundaries and the obvious error paths. You set up a test environment when shown how. - Test Automation — You can use the team frameworks and tooling to write reliable automated tests, and wire them into continuous integration so they run on every change. You fix the flaky tests you introduce. - Defect Management — You can triage defects against an agreed process, judge severity and priority with support, and assess the dependencies and risk a defect carries. You help build a workaround while a fix is written. - Test Strategy — You can explain why a test approach or plan exists and how a delivery method changes it, and you can follow an existing plan with support. - Performance Testing — You can run an existing load or benchmark script and read its report, and you can explain the difference between latency and throughput. - Accessibility Testing — You can explain that users have different access needs, and you can fix an accessibility defect that someone else has flagged, under direction. Systems and Design - Systems Design — You can read an existing design document and explain what the components are for and where they hand off to each other. You can draw the current shape of a system you work in without leaving out the parts you find confusing. - Systems Integration — You can trace a call from one system into another and say what data crosses the boundary. You can run an existing integration test and read what it reports while someone works alongside you. - Architectural Decisions — You can read a recorded technical decision and explain what was chosen, what was rejected and why. You can find the record of a past decision when you need to know why the code looks the way it does. - Schema and Query Design — You can read a schema and explain what each table holds and how the tables relate. You can write a simple query and, with help, tell whether the result answers the question that was actually asked. - Prototyping and Spikes — You can build a small throwaway example to answer a question someone else has framed, and report what you found. You leave the code as an experiment rather than trying to turn it into production work. Operations and SRE - Continuous Delivery — You can push a change through the existing pipeline, read a failed stage and say which step broke. You ask first before doing anything by hand that the pipeline is meant to do. - Observability and Monitoring — You can find the logs and dashboards for a service and use them to answer a simple question about what it is doing. You can add a log line where a reviewer suggests one. - Production Incident Response — You can follow the incident process, keep a record of what you tried and hand over cleanly at the end of your shift. You escalate early rather than working alone on something you cannot yet judge. - Availability and Capacity — You can explain what an availability target means for a service and where its current numbers are reported. You can see that a resource is near a limit once someone has shown you where to look. - Infrastructure as Code — You can read the infrastructure definitions for a service and say what they create. You can make a small parameter change and get it reviewed and applied with support. Security and Data - Application Security — You can name the common classes of vulnerability that affect the code you write and fix one that a reviewer or a scanner has flagged. You ask for help before writing credential or authentication handling yourself. - Secure Data Handling — You can tell personal data apart from other data in a system you work on, and you follow the rules on what may be copied, logged or displayed. You ask before moving data out of an environment. - Dependency Management — You can add a library the team already uses, explain what a lock file is for and find which version a project depends on. You ask before introducing something new. Delivery - Project Management — You can follow a plan someone else wrote, keep your own tasks up to date, and flag a task you own as soon as you know it will slip. - Planning & Estimation — You can estimate a task you have been given once the approach is clear, and you say promptly when the estimate turns out to be wrong. - Ownership & Accountability — You can own a piece of work after release: you watch how it behaves, fix what you broke, and are never chased for a status update. - Quality Focus — You can choose checks that suit the work in front of you, catch your own mistakes before review, and confirm the result behaves once it is live. Craft - Problem Solving — You can diagnose problems in work you did not build, and you fix the underlying cause instead of routing around the symptom. - Domain Expertise — You can apply the basics of your field to the work you are given, and you know who to consult at the edge of what you know. - Continuous Learning — You can pick up an unfamiliar area fast enough to be useful in it, and you turn what you learned into something others can reuse. Communication - Communication — You can explain your work to your team so they can act on it, and you take vague requirements and ask the questions that sharpen them. - Collaboration — You can work well with people in other roles, share context and credit, and take criticism of your work without defending territory. - Technical Writing — You can document your own work well enough for a colleague to follow it unaided, and you keep that document current as the work changes. - Stakeholder Management — You can keep your manager and immediate team informed of your progress, and you raise an issue before someone else discovers it. Leadership - Leadership — You can act on direction well, seek feedback on how you work, and be transparent about what you need help with. - Mentoring — You can share what you have just learned with your peers and help a newer colleague find their way around. - Strategic Thinking — You can explain why the work you were given matters and who it is for.
Import this exact framework into your own org
Create a free account and Software engineering lands in your org as a department: all 40 skills, with the mastery expected at each of your 5 career levels — already filled in. Rename or delete anything you don't want.