.svg)
📌 At each level, you are expected to both develop the competencies listed under the particular level and also mostly master the previous level competencies.
Junior Engineer
The primary job is to execute reliably — and to learn fast enough that you won't stay here long. You need to be comfortable having a steep learning curve in front of you and be motivated about it. A Junior engineer delivers well-defined work, builds the foundations of engineering judgment, and earns trust by being honest about what they know and what they don't. This is where you prove you can be trusted with more.
Understanding: Approaches unfamiliar code and systems with genuine curiosity. Asks clear, specific questions to understand what needs to be built and why — before building it. Doesn't accept confusion as a default state.
Execution: Delivers well-scoped tasks independently and follows through reliably. Keeps the team informed of progress and raises blockers as soon as they appear. When you say you'll do something, it gets done.
Fundamentals: Solid grasp of core programming concepts, data structures, and basic design principles. Understands or develops understanding of why patterns exist, not just how to apply them. This foundation is what everything else is built on — shortcuts here cost you later.
Quality: Understands the purpose of introducing determinism in workflows e.g. through testing and code quality assurance practices like linting and static analysis — not just as rules to follow, but as tools for building confidence in your work. Takes pride in getting the details right. Able to build and evaluate tests and their quality, follow style conventions, and reason about whether code actually does what it's supposed to do.
Documentation: Reads and writes clear documentation. Leaves code and context better than they found it. Clarity in writing reflects clarity in thinking.
Communication: Expresses ideas and asks questions clearly. Speaks up when something is unclear or needs more context — even when it feels uncomfortable. Being clear and honest is more valuable than being confident or right.
Collaboration: Shares context openly and keeps teammates in the loop. Engineering is a team effort — your work is only as valuable as other people's ability to build on it.
Feedback: Actively seeks feedback and acts on it. Comfortable with not knowing things yet — but not comfortable staying there. Growth at this level is directly proportional to how coachable you are.
Ownership: Takes responsibility for their work, including its quality and communicating about its status. Doesn't wait to be asked what to do next, but reaches out proactively.
AutoUncle business: Understands what AutoUncle does and who it's for. Curious about how their work connects to the product and the people using it.
Product awareness: Knows who the end user is for the features they work on. Asks what problem a task is solving, not just what the task requires. The habit of thinking "who does this help and how?" starts here.
AutoUncle engineering: Understands and carefully applies AutoUncle's development practices, tools, and conventions — with guidance where needed.
Engineer
Senior Engineer
Everything in Engineer (Level 2) +
The senior engineer role is the bread and butter of AutoUncle's Engineering teams. The primary job is to design systems, not just features inside existing ones. A Senior engineer is no longer just delivering features — they own the quality and direction of the systems they work in. They frame ambiguous problems, make architectural decisions that others build on, and start preventing classes of mistakes rather than just fixing individual ones. This is where engineering judgment becomes your primary output.
Problem framing: Takes ambiguous or loosely defined problems and turns them into concrete, well-structured plans. The real skill isn't just solving problems — it's making sure you're solving the right one. Asks "why are we building this?" before "how should we build this?"
System design: Designs complex systems that align with AutoUncle's architecture and long-term direction both product strategic and operational. Makes architectural trade-offs explicit and can defend them under scrutiny. A good system design isn't the one with the most elegant solution — it's the one with the fewest negative surprises.
System health: Takes initiative in improving the quality and performance of the systems they work in — migrating legacy code, establishing better patterns, raising the bar for the codebase. Doesn't wait for permission to make things better. Follows up on metrics consistently to validate that improvements are actually working. The difference between a mid-level engineer and a senior one often shows up here: seniors see decay and act on it!
Evaluation and review: Critically evaluates solutions — whether produced by teammates, themselves, or automated tools — with the same rigour regardless of the source. The goal isn't to find fault — it's to catch what others miss and raise the standard of what "good" looks like through educational impact and mentorship.
Testing your leadership skills: Defines what "done" looks like from a quality perspective. Designs and leads testing efforts for complex systems. If the team doesn't know when something is ready to ship, that's a Senior engineer's problem to solve.
Security and compliance in practice: Designs security into the systems they own from the start, rather than treating it as a bolt-on. Reviews others' work with security in mind — not just functionality. Understands threat modelling for their systems and can identify attack surfaces. Ensures compliance requirements (GDPR, data handling, consent) are built into system design, not handled as afterthoughts. When a security concern surfaces, owns the response end-to-end: assessment, fix, and prevention of the same class of issue recurring.
Mentoring and sparring: Mentors junior and mid-level engineers and spars with seniors. The goal of mentoring isn't to give answers — it's to help them develop the thinking that produces good answers. Teaching someone to frame a problem well is worth more than fixing it for them.
Strategic thinking: Sees the big picture and aligns engineering efforts with business goals. Understands why we're building what we're building — and has the courage to push back when the answer isn't clear. Stays open to being wrong — and changes course when the evidence says so.
Facilitation: Facilitates productive discussions, moves conversations toward decisions, and creates clarity in ambiguous situations, rather than keeping the conversation hanging in a limbo of uncertainty or lack of clarity. A meeting that ends without a decision or a clear direction is a meeting that should have been different and likely often shorter.
Influencing: Brings people along through reasoned arguments and evidence rather than authority. Advocates for or against technical decisions in a way that builds trust, even when the outcome is disagreement.
Resilience: Stays effective under pressure and handles setbacks without losing general momentum. When an approach fails or a system breaks, focuses energy on understanding why and moving forward. When technical disagreements escalate, steps in to mediate — lowering the heat rather than expanding it. Helps conflicting perspectives find common ground and move toward resolution. Setbacks are data, not defeat.
Steadiness: Maintains a grounded and constructive attitude during difficult periods — failed experiments, technical debt, organisational change. Encourages the team to take calculated risks without losing sight of standards. The team takes its emotional cues from how senior engineers respond to adversity.
Technical curiosity: Actively seeks inspiration from technical domains beyond immediate work — exploring new technologies, patterns, and approaches that could benefit AutoUncle. Pushes the boundaries for technological experimentation and adoption where it creates genuine value. Balances curiosity with pragmatism: not every new technology is worth adopting, but the best ones won't adopt themselves.
Leadership: Guides and motivates others through their own work and behaviour. Sets the standard for what good engineering looks like on the team — not just technically, but in how people grow, learn and are treated along the way. What you tolerate becomes the team's norm.
AutoUncle business: Deep understanding of AutoUncle's business model, products, and services. Can and actively takes responsibility for explaining them to new joiners and identifies opportunities for technical investment based on business understanding. Knows enough about the business to know when engineering effort is being misdirected.
Product ownership: Shapes what gets built, not just how it gets built. Understands user needs deeply enough to challenge requirements, propose alternatives, and identify opportunities that others miss. Can prototype and validate ideas quickly based on raw user and stakeholder feedback. The best Senior engineers don't wait for a product spec to tell them what matters — they seek for the input autonomously.
AutoUncle engineering: Deep understanding of AutoUncle's development processes and the systems they work on. Helps shape and improve engineering practices, and provides technical guidance to others. The systems you work in should be better because you've been there.
Staff Engineer
Everything in Senior Engineer (Level 3) +
The primary job is to design the system that produces "the system". A Staff engineer stops asking "how do I build this well?" and starts asking "how do I make it easier for everyone to build things well?" The leverage comes from what you eliminate, not what you produce — entire classes of problems, recurring friction, systemic weaknesses. Your best work is often invisible: it shows up as problems or roadblocks that never happen.
Systemic problem-solving: Leads the resolution of complex, cross-cutting technical problems. Develops approaches and patterns that others can easily follow. The goal isn't just to fix the problem — it's to make it structurally harder to reintroduce. If you've solved the same type of problem twice, that's a system failure, not a coincidence — and the curiosity and courage to ask "why does this keep happening?" is what leads to the systemic fix.
Meta-system design: Designs not just individual systems but the guardrails and harness, shared foundations, and patterns that shape how systems are built across teams. Makes the correct architectural choice the path of least resistance. The best harnesses don't feel like constraints — they feel like common sense and create a walled garden for product teams to thrive in, rather than a micromanaged web of rules.
Eliminating problem classes: Moves beyond fixing individual bugs to eliminating the conditions that produce them — through lint rules, generators, shared libraries, structural tests, or architectural constraints. This is the concrete expression of converting judgment into automation. Recognises which patterns are stable enough to codify — and has the discipline to wait until they are.
Performance and reliability: Diagnoses and guides resolution to performance issues in complex, distributed systems. Treats reliability, failure modes, and operational concerns as first-class design inputs. If reliability is an afterthought, it's already too late.
Quality strategy: Shapes quality assurance practices across teams — establishing standards, review patterns, and testing approaches that raise the bar beyond individual features. Quality at this level isn't about checking boxes — it's about building a culture where low-quality work is hard to produce in the first place.
Continuous improvement: Identifies the highest-leverage improvements across systems and processes. Balances investment in new work against investment in foundations. Knows that the unglamorous work — reducing friction, improving tooling, cleaning up what others ignore — often compounds faster than new features.
Engineering productivity: Elevates productivity through constant identification and optimisation of the product cycle and processes — where and how things get built and deployed effectively. Reduces time and friction in feedback loops. Cares about what external and internal stakeholders need, and designs systems to support more cohesive relationships with those stakeholders. Positions product & engineering internally through genuine desire to service and support the shared mission.
Security and compliance as systems: Elevates security from something individuals do to something the architecture enforces. Designs security patterns, guardrails, and automated checks that make insecure choices structurally difficult — so compliance doesn't depend on individual vigilance but on systemic design. Anticipates regulatory shifts and positions systems ahead of them. Bridges the gap between security as a technical concern and security as a business requirement, ensuring stakeholders understand risk in terms they can act on.
Relationship building: Builds and maintains strong relationships with key stakeholders across engineering and product as well as the broader business and departments. Acts as a trusted technical advisor. Trust at this level is earned by consistently being right about what matters — and honest about what you don't know.
Communication: Communicates complex technical concepts and trade-offs to non-technical stakeholders clearly. Translates between engineering and business language without losing precision. If the business doesn't understand the trade-off, it's your problem, not theirs.
Decision-making: Makes difficult decisions with incomplete information. Weighs technical and business risk, and communicates rationale and trade-offs clearly. Has the courage to make unpopular calls when the evidence supports them — and the humility to reverse course when it doesn't.
Mentorship at scale: Mentors and coaches engineers across levels — including senior engineers. Develops judgment, not just skills. The measure of success isn't how many problems you solve — it's how many problems your team can solve without you.
Leadership: Leads across teams through complex, ambiguous problems. Creates clarity where there is none and moves people toward aligned decisions. Doesn't need authority to lead — earns influence through the quality of their thinking and the consistency of their follow-through.
Strategic thinking: Advances the organisation's technical strategy. Helps teams make confident decisions that compound toward long-term goals. Measures the value of engineering investment by where it leaves the organisation in a year, not by what it delivers this week.
AutoUncle business: Deep understanding of specific, complex areas of AutoUncle's business. Understands how one detail in a system can be instrumental to the success in another. Engages effectively with cross-functional teams, provides domain-specific insights, and helps shape direction within their areas of expertise. Uses business context to prioritise engineering investment — not just what's technically interesting, but what actually matters to the business both in the short and long term as well.
Product strategy: Bridges the gap between product and engineering strategy. Understands user problems well enough to partner with product managers as equals — contributing to roadmap decisions, challenging priorities, and identifying where technical capability can unlock product opportunities that aren't yet on anyone's radar. Think in terms of user outcomes, not just system outputs.
AutoUncle engineering: Strong understanding of how AutoUncle's systems interact. Drives the long-term technical vision for the systems they are responsible for and ensures engineering practices align with company goals. The engineering organisation should be measurably better because of the systems and patterns you've put in place.
Principal Engineer
Everything in Staff Engineer (Level 4) +
The primary job is to design the engineering organisation and its foundations. It's a role that resembles more that of a manager or leader than that of the individual contributor. It revolves around culture, staffing and human interaction and systems - not only internally in the organization, but also towards the world around it. A Principal engineer defines the building blocks that everyone else treats as given — the architectural principles, the engineering standards, the decision-making frameworks. At this level, your decisions don't just affect systems; they shape how every engineer at AutoUncle thinks about and produces software. The impact is eventually measured in years and quarters, not months and days.
Organisational architecture: Designs the foundational systems and building blocks that teams across the organisation build on — shared platform services, API contracts, data architecture, deployment infrastructure, observability foundations, or the decision-making frameworks that guide how teams make architectural choices. Defines what "correct" looks like at AutoUncle — not just for one team or system, but as a standard that scales. The foundations you lay should still be serving the organisation long after you've moved on to the next problem.
Novel problem-solving: Develops new approaches and techniques for engineering challenges that don't have established solutions. Operates comfortably at the frontier of what's known. The curiosity and courage to explore uncharted territory is what keeps the organisation from stagnation — solving tomorrow's problems with yesterday's thinking is a risk only a Principal can see coming and address proactively.
Engineering processes: Designs and evolves the processes through which engineering happens — how decisions are made, how knowledge is captured, how systems are documented, how quality is defined. The goal isn't more process — it's the right process. Creates clarity that compounds across the organisation and removes friction that others have learned to live with.
Design vision: Shapes AutoUncle's approach to software design at a fundamental level. Develops the principles, patterns, and architectural direction that guide engineering across teams and survive beyond any individual system. A good design vision doesn't prescribe solutions — it makes the right solutions obvious.
Security and compliance: Expert in security best practices. Ensures security thinking is embedded in engineering culture, not bolted on. Anticipates emerging threats and builds them into architectural standards before they become problems. Security at this level is an organisational habit, not a checklist.
Engineering community: Shapes and sustains a high-performance engineering culture. Identifies and develops top talent, sets the norms for what excellent engineering looks like at AutoUncle, and creates an environment where strong engineers want to stay and grow. Culture isn't what you declare — it's what you consistently demonstrate and reward.
Innovation culture: Drives a culture of thoughtful innovation — not innovation for its own sake, but finding new approaches that create real, compounding value. Has the courage to champion ideas that challenge the status quo and the humility to abandon them when they don't work.
Thought leadership: Represents AutoUncle as a technical voice in the industry — through writing, speaking, or the quality of what we ship. Shapes how the organisation is perceived externally and how engineers inside it see themselves. The company's engineering reputation is partly your responsibility.
Executive influence: Advises senior leadership on complex technical decisions. Shapes company strategy through clear articulation of risks, opportunities, and long-term trade-offs. Translates engineering reality into business language with precision — not dumbing it down, but making it accessible.
An exceptional role model: Sets the standard for engineering excellence at AutoUncle through consistent demonstration of technical rigour, intellectual honesty, and ownership. At this level, your behaviour defines what's possible and what's acceptable. People don't just follow your decisions — they pattern their judgment on yours.
AutoUncle business: Unparalleled understanding of AutoUncle's business model, including its most complex domains. Engages with executive and cross-functional stakeholders to shape strategy, assess risk, and identify opportunities for sustained competitive advantage. Sees the business clearly enough to know which engineering investments will still matter in three years.
Product-engineering integration: Defines how the organisation thinks about the relationship between product and engineering. Ensures that engineers at every level develop product instincts, besides just technical skills - but also flags to leadership, when it consistently doesn't happen. Shapes the processes, rituals, and culture that keep engineering connected to user outcomes — so that building the right thing isn't a happy accident, it's a structural guarantee.
AutoUncle engineering: Influences and shapes the future of AutoUncle's engineering domain through research, innovation, and deep expertise. Develops and communicates a long-term technical vision that inspires teams to align behind it. The engineering organisation's trajectory should be visibly shaped by your thinking.