Junior Engineer

Is responsible for and maintains their computer and local development environment, e.g.

• Keeps their local tools up to date
• Follows instructions to get software projects running locally

Uses version control to manage routine development workflow, and can work with support on uncommon workflows, e.g.

• Git example: is able to clone a repo, check out a branch, add, commit, push
• Git example: asks for help with more complex tasks like rebase and resolving conflicts

Uses code to make something reasonably straightforward, mostly independently, e.g.

• Works on a feature or improves an existing one
• Adds a use case to an existing automation script

Implements automated unit or end to end tests with help from a more senior engineer

Fixes or updates tests when implementing changes to a preexisting feature

Checks whether code from well-known sources can be reused before writing new code, and generally identifies that kind of reuse when there is the opportunity, e.g.

• Checks to use a Clojure/ClojureScript/etc library in project
• Checks for the chance to integrate with proprietary software packages

Works to timeboxes when debugging, e.g.

• Ensures they have a timebox when debugging
• Communicates their progress through a timebox
• Seeks help from other engineers before time runs out
• Does not overshoot a timebox without flagging it

Shadows during live incidents or joins debugging mob sessions

Is able to explain why using CI/CD pipelines for automation is beneficial, and uses them for basic functions, e.g.

• Restarts a broken build
• Is able to interpret CI output and articulate what is failing
• Can fix simple problems or asks for help

Occasionally uses monitoring tools to explain technical behaviour, e.g.

• Occasionally uses CloudWatch to explain unusual behaviour
• Occasionally uses CloudWatch to understand the consequences of a change

Writes pull requests that are helpful both to the reviewer and those debugging the the code later, e.g.

• Writes PR descriptions that explain why the PR is needed
• Links to relevant Jira tickets in PRs
• Adds screenshots to show changes if applicable
• Provides context that they learned when researching a PR

Regularly reads peers' PRs and asks questions in order to learn

Remembers to write more straightforward tickets and bug reports to track the work expected of them, perhaps with prompting and guidance, e.g.

• Checks there is a corresponding ticket or bug report before starting any work, and flags it if not
• Writes reasonable "steps to reproduce" in a reasonably straightforward bug report when prompted
• Adds relevant links and screenshots to pages affected by a bug when prompted

Receives feedback and acts upon it, e.g.

• Implements requested changes on a pull request
• Responds to comments on a Google document
• If they receive feedback from the team that sometimes they don't seem well-prepared for morning stand-ups, takes 5 minutes before stand-ups to gather thoughts about what the status of their work is

Is able to recognise when they are having difficulties, and provides information so that other people can help, e.g.

• Raises a concern to their line manager if they feel they are falling behind
• Asks a mentor for help if they feel overwhelmed or not feeling confident
• Asks a tech lead for help if they are struggling with a piece of work

Presents their own work clearly to a product owner or tech lead, e.g.

• Talks about their progress in standup without going into deep technical detail
• Explains their approach to a technical problem to their tech lead
• Gives a live demo of a feature that they worked on to their team

Effectively communicates when they are unable to attend expected events, e.g.

• Informs meeting organisers of meetings they cannot attend
• Puts out-of-office messages on emails when going on holiday
• Puts appropriate emoji on Slack when sick or on holiday
• If they've got a meeting clash they explain to the organiser of the meeting they have to miss
• When they're in a meeting that's overrunning into another they communicate with both meetings' organisers to set expectations
• If they have a meeting that reguarly overruns into another they ask for help from their line manager

Recognises and communicates conflicting priorities and delivery expectations, e.g.

• Recognises when meetings clash with other responsibilities, and communicates to affected parties with the aim of resolving the conflict
• Communicates the difficulties they encounter with delivering a ticket rather than struggling on their own

Attends their team's meetings, and shares their views and opinions

Regularly communicates the status of their work

Participates in the delivery process, e.g.

• Moves tickets to done column when they are complete
• Goes to stand-ups and communicates progress

Knows who their project's stakeholders are and references them where appropriate, e.g.

• Explains a ticket in reference to a named stakeholder
• Explains a ticket in reference to a specific kind of stakeholder
• References named stakeholders in retrospectives

Acts with integrity, honesty and accountability

Is respectful to and inclusive of others, e.g.

• Listens to others regardless of role, social group, etc
• Treats remote and in-person meeting participants with equal respect
• Escalates to their line manager occasions when a colleague seems to be excluding or alienating others

Is engaged with their own personal development and follows through on agreed actions for this, e.g.

• Sees some code that they don't understand, and researches how it works
• Learns how to use a new tool/language feature
• Reads blog posts about technology
• Studies for and attains a technical certification
• Finds a training course and takes it
• Attends meet-ups or conferences