{ "id": "java-backend-2027", "title": "Java Backend Roadmap 2027", "subtitle": "Four tracks you learn together… and one project that grows with you.", "language": "en", "contentVersion": "2026-10-19", "videoUrl": "", "tracks": [ { "id": "ai", "number": 1, "color": "#8B5CF6", "name": "AI", "short": "AI", "description": "Use AI to learn, reason, implement, and review from day one, and later build evaluated AI features into the product." }, { "id": "java", "number": 2, "color": "#14B8A6", "name": "Java Backend & technical foundations", "short": "Java Backend", "description": "Understand, write, test, debug, and operate software." }, { "id": "engineering", "number": 3, "color": "#F59E0B", "name": "Business, design & delivery", "short": "Business, design & delivery", "description": "Understand the domain and the user's need, choose a suitable solution and design, and deliver value. Architecture and business understanding both belong to this track." }, { "id": "professional", "number": 4, "color": "#3B82F6", "name": "Communication & professional work", "short": "Communication & professional", "description": "Explain, agree, collaborate, document, and lead as your responsibility grows." } ], "stages": [ { "id": "stage-1", "number": 1, "name": "Stage 1", "level": "Beginner", "short": "Beginner", "focus": "A small Java program you understand", "title": "Stage 1 — Beginner: a small Java program you understand · Steps 01–04", "goal": "Start using AI and build a foundation that helps you understand and review, with an in-memory program that manages courses, students, and enrollments.", "gate": "You run the program and explain its behavior, add a new rule, and diagnose a bug and prove the fix with a test.", "overview": { "ai": "Explanations, hints, and review", "java": "Java, OOP, Git, and tests", "engineering": "Enrollment rules and simple responsibilities", "professional": "A clear question and an explained decision" }, "outcome": "An in-memory course program", "steps": [ "01", "02", "03", "04" ] }, { "id": "stage-2", "number": 2, "name": "Stage 2", "level": "Junior foundations", "short": "Junior foundations", "focus": "Backend, APIs, and a database", "title": "Stage 2 — Junior foundations: backend, APIs, and a database · Steps 05–07", "goal": "Turn the program into a backend with persistent data and APIs for courses, lessons, and enrollment.", "gate": "You trace a request to the database, justify the model and the API contract, change a requirement and test it, and someone else can use your documentation.", "overview": { "ai": "Data-model critique and an IDE assistant", "java": "SQL, HTTP, and Spring Boot", "engineering": "ERD and API contracts", "professional": "Documentation and work with Frontend and QA" }, "outcome": "A backend with persistent data", "steps": [ "05", "06", "07" ] }, { "id": "stage-3", "number": 3, "name": "Stage 3", "level": "Capable Junior", "short": "Capable Junior", "focus": "A secure, deployed, maintainable application", "title": "Stage 3 — Capable Junior: a secure, deployed, maintainable application · Steps 08–10", "goal": "Add accounts, permissions, lessons, quizzes, and results, and deliver a complete student journey on a deployed environment.", "gate": "You deliver a small feature from understanding the requirement through deployment and follow-up, and you know when you need help or review.", "overview": { "ai": "Review, tests, and a bounded agent", "java": "Security, Docker, and CI/CD", "engineering": "Permissions, quality, and releases", "professional": "Demo and runbook" }, "outcome": "A deployed student journey", "steps": [ "08", "09", "10" ] }, { "id": "stage-4", "number": 4, "name": "Stage 4", "level": "Mid-level", "short": "Mid-level", "focus": "Owning a complete feature and handling complexity", "title": "Stage 4 — Mid-level: owning a complete feature and handling complexity · Steps 11–14", "goal": "Handle business rules, concurrency, performance, integrations, and failure with more independence, and build a first useful AI feature for teachers.", "gate": "You own a medium-sized feature from requirements to operation, handle integrations and failure cases, and explain your trade-offs, with review matched to the risk.", "overview": { "ai": "Analysis and model integration", "java": "Concurrency, performance, and integrations", "engineering": "Consistency, payments, and value", "professional": "Ownership, estimation, and trade-offs" }, "outcome": "A complete feature that tolerates failure", "steps": [ "11", "12", "13", "14" ] }, { "id": "stage-5", "number": 5, "name": "Stage 5", "level": "Preparing for Senior responsibilities", "short": "Senior responsibilities", "focus": "Designing and operating parts that matter", "title": "Stage 5 — Preparing for Senior responsibilities: designing and operating parts that matter · Steps 15–18", "goal": "Handle more ambiguity and risk, and improve both the system and the team; add a content assistant and permissions, and study SaaS, reliability, and distribution when they are needed.", "gate": "You own an important part across design, implementation, and operation, reduce its risks, guide others, and work with incomplete requirements. Doing this with a real team and real users is a core part of proving it.", "overview": { "ai": "RAG and tool calling", "java": "Multi-tenancy and observability", "engineering": "SaaS, SLOs, and scaling", "professional": "Leadership and mentoring" }, "outcome": "An important part you can operate", "steps": [ "15", "16", "17", "18" ] }, { "id": "stage-6", "number": 6, "name": "Stage 6", "level": "Staff / Architect and beyond", "short": "Staff / Architect", "focus": "Impact beyond a single team", "title": "Stage 6 — Staff / Architect and beyond: impact beyond a single team · Steps 19–21", "goal": "Connect technical direction to platform economics and enable multiple teams. Staff and Architect may be different paths, not necessarily consecutive ranks.", "gate": "Initiatives adopted by several teams, lasting measurable results, and knowledge and ownership that continue without depending on you day to day.", "overview": { "ai": "Operating, evaluating, and enabling teams", "java": "Platform and deep specialization", "engineering": "Strategy and economics", "professional": "Influence and growing leaders" }, "outcome": "Impact across teams", "steps": [ "19", "20", "21" ] } ], "steps": [ { "id": "01", "stage": "stage-1", "title": "Your environment and a clear question", "platform": "Run a Java program that shows course data, and define the teacher, student, course, and enrollment as the platform's first scope.", "tracks": { "ai": { "title": "A learning assistant", "what": "ChatGPT or Claude basics: a clear goal, context, follow-up questions, and the limits of trust and privacy.", "why": "You use it to explain, practice, and review from day one.", "evidence": "You summarize a concept in your own words, try an example, and verify the answer." }, "java": { "title": "Your environment and understanding a program", "what": "The JDK, an IDE such as IntelliJ IDEA, the terminal, files, running a Java program, and tracing inputs and outputs.", "why": "You set up an environment to experiment in and understand the write-and-run cycle.", "evidence": "You run a program that shows course data, change the inputs, and explain the result." }, "engineering": { "title": "Understanding the journey project", "what": "The user, the problem, the goal, and the scope: teacher, student, course, and enrollment; stating your assumptions.", "why": "You connect learning to a real need and start with a small scope.", "evidence": "You write a short description of the platform and three questions you need the teacher to answer." }, "professional": { "title": "The clear question", "what": "Describing the goal, what you tried, and the expected versus actual result; basic English technical vocabulary.", "why": "You get useful help and reduce misunderstanding.", "evidence": "You write a question someone else can understand and reproduce." } } }, { "id": "02", "stage": "stage-1", "title": "Java basics and problem solving", "platform": "The enrollment-eligibility rule: who can enroll in a course, with written success and rejection cases that match the program's behavior.", "tracks": { "ai": { "title": "How to learn with AI", "what": "Asking for a hint, breaking the problem down, explaining one step, then verifying and trying on your own.", "why": "You turn help into an ability you can use yourself.", "evidence": "You solve a similar exercise and explain the solution after the help ends." }, "java": { "title": "Java basics and problem solving", "what": "Types, variables, conditions, loops, methods, strings, arrays, scope, and the debugger.", "why": "You express the platform's rules in code and follow how they run.", "evidence": "You implement a simple enrollment-eligibility rule, trace a wrong condition, and fix it." }, "engineering": { "title": "Turning a rule into behavior", "what": "Inputs and outputs, pseudocode, success and rejection cases, and concrete acceptance examples.", "why": "You define the required behavior before implementing it.", "evidence": "You write cases for an eligible and an ineligible student, and the program's results match them." }, "professional": { "title": "Explaining your thinking", "what": "Explaining the steps of a solution, writing down assumptions, and clearly stating what you don't understand.", "why": "Others can follow your logic and help you.", "evidence": "You explain the enrollment rule and a counterexample in two minutes." } } }, { "id": "03", "stage": "stage-1", "title": "Modeling code in Java", "platform": "An in-memory model of students, courses, and enrollments that prevents duplicate enrollment and respects course capacity.", "tracks": { "ai": { "title": "Exercises with gradual help", "what": "Examples, exercises, and edge cases; predicting the result before asking for an explanation.", "why": "You uncover gaps in understanding instead of just following a ready answer.", "evidence": "You predict the output and explain any difference between expected and actual." }, "java": { "title": "Modeling code in Java", "what": "OOP, encapsulation, composition, interfaces, collections, generics, and exceptions; data-structure and complexity basics.", "why": "You represent students, courses, and enrollments and choose how to work with them.", "evidence": "You build an in-memory model that prevents duplicate enrollment, add course capacity, and test it." }, "engineering": { "title": "Clear responsibilities and rules", "what": "Entities, invariants, separating business rules from the user interface, and a simple design that can change.", "why": "You know where the enrollment rule lives and what is affected when it changes.", "evidence": "You justify where the capacity rule lives and change it without copying it to several places." }, "professional": { "title": "Explaining decisions", "what": "Explaining what each part is responsible for and why you chose a collection or an interface, plus a simple alternative.", "why": "The code becomes open to discussion and review.", "evidence": "You give a short walkthrough, and a colleague can add a new rule." } } }, { "id": "04", "stage": "stage-1", "title": "Developer tools and early testing", "platform": "The platform's first repository: a build from a clean checkout, a test that prevents duplicate enrollment, and a reviewable PR.", "tracks": { "ai": { "title": "Reviewing an existing attempt", "what": "Showing your attempt and asking AI about a specific flaw or alternative, then examining the diff and the suggestions.", "why": "You learn to evaluate a review and avoid accepting changes you don't understand.", "evidence": "You accept or reject a suggestion based on a test and an explanation." }, "java": { "title": "Developer tools and early testing", "what": "Git, commits, branches, pull requests, Maven, and JUnit; refactoring and reading stack traces.", "why": "You keep the project's history and change code with confidence.", "evidence": "The project builds from a clean checkout, and a test fails before the duplicate-prevention fix and passes after it." }, "engineering": { "title": "Delivering a small change", "what": "Breaking down the task, acceptance criteria, a definition of done, and separating behavior changes from structural improvements.", "why": "You finish a reviewable unit and know when it is done.", "evidence": "A small task with code, tests, and acceptance criteria that are met." }, "professional": { "title": "Code review and documentation", "what": "A short README, a clear commit and PR, requesting review, and responding to comments.", "why": "Someone else can run the project and understand the change.", "evidence": "A colleague runs it from the README, reviews the PR, and knows why the behavior changed." } } }, { "id": "05", "stage": "stage-2", "title": "Databases and data modeling", "platform": "Move students, courses, and enrollments to PostgreSQL, with an Enrollment table and constraints that prevent duplicates.", "tracks": { "ai": { "title": "Critiquing the data model", "what": "Comparing schema alternatives, raising cases that expose missing constraints, and generating test data.", "why": "You test the model's assumptions before relying on it.", "evidence": "You review a suggestion and prove your choice with data and an experiment." }, "java": { "title": "SQL and the database", "what": "PostgreSQL, tables, keys, constraints, joins, transactions, index basics, JDBC, then migrations.", "why": "You store students, courses, and enrollments and enforce their consistency rules.", "evidence": "Data persists across runs, a forbidden duplicate fails, and an incomplete operation is rolled back." }, "engineering": { "title": "Data modeling", "what": "ERD, cardinality, normalization, transaction boundaries, and rules for deletion and change.", "why": "You turn the domain into a model that serves its use and stays consistent.", "evidence": "You justify the Enrollment table and test enrollment, deletion, and failure." }, "professional": { "title": "Documenting and discussing a model", "what": "Explaining relationships and constraints, naming terms, and recording open questions.", "why": "The team interprets the data the same way.", "evidence": "Someone else reads the diagram and writes a correct query for a student's enrollments." } } }, { "id": "06", "stage": "stage-2", "title": "The web and API contracts", "platform": "An API contract for listing courses, enrolling, and rejection cases, agreed before implementation.", "tracks": { "ai": { "title": "Understanding tools and requests", "what": "Interpreting HTTP requests, responses, and errors, and proposing specific diagnostic experiments.", "why": "You learn to trace a request and verify hypotheses.", "evidence": "You explain a failed request and prove the cause instead of settling for the model's guess." }, "java": { "title": "The web and API contracts", "what": "Client/server, an introduction to DNS and TCP/TLS, HTTP, REST, JSON, status codes, headers, and curl or Postman.", "why": "You understand how the platform's interface talks to the backend and how requests behave.", "evidence": "You write and try an enrollment request and explain the correct and incorrect responses." }, "engineering": { "title": "Use cases and API contracts", "what": "Actors, scenarios, request/response, errors, pagination, and acceptance criteria.", "why": "The meaning of each operation is clear to the interface and to testing.", "evidence": "You define the contract for listing courses and enrolling, including rejection cases, before implementation." }, "professional": { "title": "Working with Frontend and QA", "what": "Clarifying questions, example requests and results, and describing a reproducible bug.", "why": "You agree on behavior and reduce rework.", "evidence": "A colleague implements a client or a test from the contract without guessing." } } }, { "id": "07", "stage": "stage-2", "title": "Spring Boot and data storage", "platform": "A Spring Boot backend with APIs for courses, lessons, and enrollment, and documentation someone else can use.", "tracks": { "ai": { "title": "A first coding assistant in the IDE", "what": "File context, specific instructions, a small suggestion or change, reviewing the diff, and running the tests.", "why": "You speed up implementation while understanding what changed.", "evidence": "You implement a bounded endpoint, explain every change, and catch an unsuitable suggestion." }, "java": { "title": "Spring Boot and data storage", "what": "Dependency injection, configuration, controllers, services, DTOs, validation, error handling, and Spring Data JPA, with an understanding of SQL, migrations, and API docs.", "why": "You turn the program into a usable backend.", "evidence": "APIs for courses, lessons, and enrollment, and you trace a request from the controller to the database." }, "engineering": { "title": "Organizing the application", "what": "Separating responsibilities and simple module boundaries, domain rules, the use-case flow, and a feature's definition of done.", "why": "You control the impact of a change and keep behavior clear.", "evidence": "Changing an enrollment rule affects only the expected parts, and you prove it with a test." }, "professional": { "title": "Demo and feature review", "what": "Showing the user journey, explaining the decision, documenting the API, and taking feedback.", "why": "The team confirms the meaning and the result before expanding.", "evidence": "Someone uses the API from the documentation, and you absorb a change request and explain it." } } }, { "id": "08", "stage": "stage-3", "title": "Accounts and permissions", "platform": "Accounts and roles: a student sees only their own enrollments and a teacher edits only their own courses, even with a direct request.", "tracks": { "ai": { "title": "Security review", "what": "Using AI to suggest misuse cases and review specific settings or code, with independent verification.", "why": "You widen the set of cases you examine.", "evidence": "You find an unauthorized-access scenario and prove it is blocked with a test." }, "java": { "title": "Accounts and permissions", "what": "Spring Security, authentication, authorization, password hashing, sessions/tokens, resource ownership, secrets, and CORS/CSRF depending on the login mechanism.", "why": "You protect the platform's accounts, content, and operations.", "evidence": "A student can't read another student's enrollment and a teacher can't edit someone else's course, even with a direct request." }, "engineering": { "title": "Access rules and risks", "what": "A matrix of roles, ownership, and access conditions; least privilege; and simple threats.", "why": "Permissions follow the platform's rules and cover the required records.", "evidence": "You turn every access rule into a success case, a rejection case, and an acceptance test." }, "professional": { "title": "Communicating risk", "what": "Explaining impact, priority, and reproduction steps, and avoiding sharing sensitive data.", "why": "The team handles the problem clearly.", "evidence": "You write an issue report that shows who is affected and how to verify the fix." } } }, { "id": "09", "stage": "stage-3", "title": "Testing strategy and quality", "platform": "Tests for the lesson, quiz, and result journey that catch any grading bug before it is fixed.", "tracks": { "ai": { "title": "Generating useful test cases", "what": "Boundary cases, negative cases, fixtures, critiquing assertions, and examining suggested tests.", "why": "You expand coverage around real risks.", "evidence": "A suggested test exposes a real defect, and you explain what it proves and what it doesn't." }, "java": { "title": "A practical testing strategy", "what": "JUnit, Mockito when needed, integration tests, Testcontainers, Spring test support, and core journey tests.", "why": "You verify business rules and the real connection to the database.", "evidence": "The lesson, quiz, and result journey works, and a grading defect fails the test before it is fixed." }, "engineering": { "title": "Quality and evidence of done", "what": "A practical test pyramid, regression risks, acceptance tests, and release criteria.", "why": "You tie testing to behavior that matters to the user.", "evidence": "Every critical rule has a suitable test, and a requested change doesn't break the core journey." }, "professional": { "title": "Collaborating on quality", "what": "Bug reports, review with QA, explaining the limits of testing, and documenting the fix decision.", "why": "Bugs become easy to reproduce and prioritize.", "evidence": "A colleague reproduces a defect from your report and verifies its fix." } } }, { "id": "10", "stage": "stage-3", "title": "Operations, deployment, and a first release", "platform": "A complete student journey on a deployed environment: sign in, choose a course, enroll, take a lesson and a quiz, and see the result.", "tracks": { "ai": { "title": "A small agent task", "what": "A clear scope of files and tools, checkpoints, reading the diff, limited permissions, and verifying it runs.", "why": "You delegate a bounded step and keep the ability to review it.", "evidence": "The agent completes a task such as run setup or documentation, and you verify it from a clean environment." }, "java": { "title": "Operations and deployment", "what": "Linux basics, Docker and Compose, environment configuration, CI/CD, secrets, health checks, logs, migrations, and backup/restore.", "why": "You ship the service, follow it, and have a way to recover.", "evidence": "It runs from a clean environment with an automatic pipeline; you deploy an update and restore a test data backup." }, "engineering": { "title": "A first deliverable release", "what": "MVP, prioritization, a release checklist, migrations, rollback, and a simple operating plan.", "why": "You deliver a complete student journey instead of separate features.", "evidence": "Sign-in, choosing a course, enrolling, a lesson, a quiz, and a result on a deployed environment." }, "professional": { "title": "Demo, handover, and diagnosis", "what": "Showing a user journey, release notes, a runbook, and an update about a blocker or an incident.", "why": "Users and the team know what was done and what needs attention.", "evidence": "Someone runs the service and follows the diagnostic steps for a problem from your documents." } } }, { "id": "11", "stage": "stage-4", "title": "Concurrency and consistent rules", "platform": "Protect the last seat in a course from concurrent enrollments, with a test that proves the result.", "tracks": { "ai": { "title": "AI as an analysis partner", "what": "Change-impact analysis, design alternatives, critiquing assumptions, and providing context from specific files.", "why": "You test your idea before and during implementation.", "evidence": "You pick an alternative based on a constraint and an experiment, and document why you rejected another." }, "java": { "title": "Deeper Java and concurrency", "what": "Streams, immutability, JVM/memory basics, threads, executors, synchronization, race conditions, virtual threads, and complexity analysis.", "why": "You understand how code behaves under concurrency and choose suitable tools.", "evidence": "You reproduce concurrent enrollments that break capacity, then fix them and prove the behavior." }, "engineering": { "title": "Consistent platform rules", "what": "Invariants, transaction boundaries, optimistic/pessimistic locking, and what success means under contention.", "why": "The last seat in a course is never sold to more than one student.", "evidence": "A concurrent test proves the result, and you explain the cost of your choice." }, "professional": { "title": "Ownership and estimation", "what": "Breaking down a feature, identifying dependencies and risks, and updating the estimate as you learn.", "why": "The team relies on a clear commitment.", "evidence": "You deliver a small plan and flag early when new information changes it." } } }, { "id": "12", "stage": "stage-4", "title": "Performance and non-functional requirements", "platform": "Speed up course and progress listings with a specific measurement, and protect lesson files from unauthorized access.", "tracks": { "ai": { "title": "Investigating with evidence", "what": "Analyzing query plans and logs with sensitive data removed, with AI's help, and proposing experiments.", "why": "You speed up the investigation.", "evidence": "You measure before and after the change and separate the hypothesis from the proven cause." }, "java": { "title": "Data and content performance", "what": "EXPLAIN, indexes, N+1, fetch strategies, pagination, connection pools, k6, Redis when needed, object storage, and signed URLs.", "why": "Showing courses, progress, and content stays practical as data grows.", "evidence": "You improve a slow endpoint with a specific measurement and prove that access to an unauthorized file is blocked." }, "engineering": { "title": "Non-functional requirements", "what": "Latency, throughput, data volumes, storage cost, cache invalidation, and the content-access policy.", "why": "\"Fast\" and \"scalable\" become requirements you can check.", "evidence": "You define a target load and an acceptable result, and test both." }, "professional": { "title": "Presenting results", "what": "A short performance report and an explanation of the trade-offs.", "why": "Decisions are revisited based on evidence.", "evidence": "You show the improvement, its cost, and the limits of the test." } } }, { "id": "13", "stage": "stage-4", "title": "Integrations and background jobs", "platform": "Payments and notifications: a duplicate payment webhook doesn't duplicate the enrollment, and an email outage doesn't lose the job.", "tracks": { "ai": { "title": "An agent builds a bounded feature", "what": "Project instructions, checkpoints, file and tool limits, reviewing changes, and verifying acceptance criteria.", "why": "You delegate larger work while keeping control.", "evidence": "You detect a deviation from the rules and correct it before delivery." }, "java": { "title": "Integrations and background jobs", "what": "HTTP clients, timeouts, retries/backoff, idempotency, webhooks, scheduling, RabbitMQ for example, DLQs, and an introduction to the outbox pattern.", "why": "Payments and notifications tolerate delay, duplication, and failure.", "evidence": "A duplicate payment webhook doesn't duplicate the enrollment or the financial effect, and an email outage doesn't lose the job." }, "engineering": { "title": "The payment and enrollment journey", "what": "Order, payment, and enrollment states; refunds; reconciliation; and separating financial facts from success messages.", "why": "Payment success, enrollment, and notification are not one operation that is automatically guaranteed.", "evidence": "You map and test successful, failed, delayed, and duplicate payment paths." }, "professional": { "title": "Working with external parties", "what": "Reading integration docs, asking precise questions, and documenting incidents and the limits of responsibility.", "why": "An integration depends on more than one team and system.", "evidence": "You file a support request with a correlation ID, steps, and the expected result." } } }, { "id": "14", "stage": "stage-4", "title": "A first AI feature in the product", "platform": "Draft quiz questions generated by AI and reviewed by the teacher, who can edit or reject them, with quality, cost, and latency measured.", "tracks": { "ai": { "title": "A first model integration in the product", "what": "Model APIs, prompts/templates, tokens, context limits, structured outputs, streaming, timeouts, budgets, and a small evaluation set; Spring AI is a Java option.", "why": "You add real help for teachers.", "evidence": "Generating a draft of questions the teacher reviews, with quality, cost, and latency measured and failures handled." }, "java": { "title": "Operating an AI integration", "what": "Key management, client integration, output validation, rate limiting, saving job state, and monitoring calls.", "why": "A model call stays part of a service you can operate.", "evidence": "A provider outage or invalid returned JSON doesn't break the teacher's journey." }, "engineering": { "title": "Defining the feature's value", "what": "Defining the user and the desired outcome, a manual baseline, the review workflow, and a success criterion.", "why": "You test whether AI saves time while keeping acceptable quality.", "evidence": "A comparison on fixed examples shows the feature's benefit and where it needs review." }, "professional": { "title": "Clarifying the output's limits", "what": "Presenting the draft and its assumptions and asking for the user's assessment.", "why": "Users know what needs review.", "evidence": "The teacher can edit and reject the output and report a specific defect." } } }, { "id": "15", "stage": "stage-5", "title": "A content-grounded assistant", "platform": "An assistant that answers students only from the course content they are allowed to access, with citations and tests that prevent leaks.", "tracks": { "ai": { "title": "A content-grounded course assistant", "what": "Embeddings, chunking, retrieval, metadata filtering, pgvector for example, RAG, citations, and evaluating retrieval and answers separately.", "why": "Students ask about content they are allowed to see.", "evidence": "Known and out-of-scope questions, and tests that prevent retrieving data from an unauthorized student or course." }, "java": { "title": "Search and retrieval architecture", "what": "Ingestion jobs, parsing, indexing, updating and deleting indexes, metadata, and module boundaries.", "why": "The assistant's content stays consistent with current content and permissions.", "evidence": "Editing a lesson or revoking a permission is reflected in retrieval according to a documented policy." }, "engineering": { "title": "Boundaries of authority and trust", "what": "Threat modeling, prompt injection, source and refusal policies, and authorization before retrieval and execution.", "why": "Content or the model can't change the system's permission rules.", "evidence": "Adversarial tests that try to leak content or execute embedded instructions are rejected." }, "professional": { "title": "Communicating quality and risk", "what": "Explaining what was measured and what wasn't, the feature's limits, and a gradual rollout plan.", "why": "A clear launch decision.", "evidence": "You present successes, failures, and the criteria for stopping or improving the feature." } } }, { "id": "16", "stage": "stage-5", "title": "Architecture and turning the platform into SaaS", "platform": "The platform serves centers and teachers with isolated data, plans and subscriptions, and a gradual migration plan.", "tracks": { "ai": { "title": "Architecture review with AI", "what": "Critiquing boundaries, dependencies, and migration plans, and comparing scenarios.", "why": "You widen the alternatives you examined.", "evidence": "An architectural decision backed by constraints and an experiment that you can defend without going back to the model's answer." }, "java": { "title": "Architecture and multi-tenancy", "what": "Modular monolith, practical DDD, bounded contexts, dependency boundaries, isolation strategies, tenant context, tenant-aware queries/cache/jobs, and isolation tests; Spring Modulith is a helpful option.", "why": "You serve teachers and centers with clear data and boundaries.", "evidence": "One center can't reach another center's data through the API, files, jobs, or cache, with tests." }, "engineering": { "title": "Turning the platform into SaaS", "what": "Tenants, memberships and roles, plans/entitlements, quotas, onboarding, support and operations, and the shared-versus-dedicated decision.", "why": "The product model differs from a single teacher's platform.", "evidence": "A context map, an ADR, a gradual migration plan, and acceptance tests for every plan." }, "professional": { "title": "Leading a design discussion", "what": "RFC/ADR, listening to objections, and facilitating a decision.", "why": "Important decisions need shared understanding.", "evidence": "The discussion ends with a decision, its reasons and risks, and an owner for follow-up." } } }, { "id": "17", "stage": "stage-5", "title": "Reliability and incident management", "platform": "Monitor the platform with metrics, logs, and traces, and run an exercise of a failing external dependency and service recovery.", "tracks": { "ai": { "title": "AI in operational investigation", "what": "Summarizing signals and failure hypotheses from controlled context and verifying them with measurements.", "why": "You speed up diagnosis and keep a record of the evidence.", "evidence": "You confirm or rule out hypotheses with experiments and real indicators." }, "java": { "title": "Observability and reliability", "what": "Metrics, logs, traces, OpenTelemetry, Micrometer, Prometheus/Grafana, profiling/JFR, load tests, graceful degradation, and backup/restore drills.", "why": "You know the impact of failures and restore service.", "evidence": "Injecting a failure into an external dependency, detecting it, reducing its impact, and restoring service to a defined target." }, "engineering": { "title": "SLOs and incident management", "what": "SLIs/SLOs, error budgets, capacity, RTO/RPO, runbooks, postmortems, and prioritizing reliability work.", "why": "You balance feature development with service stability.", "evidence": "A documented incident exercise with follow-up actions that have owners and dates." }, "professional": { "title": "Leading an incident and mentoring a colleague", "what": "Splitting the investigation, updating stakeholders, separating facts from hypotheses, and blameless guidance.", "why": "Less confusion and better team learning.", "evidence": "A colleague takes over part of the investigation using your explanation and the runbook." } } }, { "id": "18", "stage": "stage-5", "title": "Distributed systems and scaling decisions", "platform": "An assistant that reads a student's progress and suggests a plan without changing an enrollment or a grade, and splitting a service only with proven justification.", "tracks": { "ai": { "title": "Tool calling and workflows", "what": "Tools with defined contracts, schema validation, permissions, bounded workflows, approval for sensitive operations, evals, and audit trails.", "why": "The assistant performs specific functions safely.", "evidence": "It reads a student's progress and suggests a plan, and doesn't change an enrollment or a grade outside the application's permissions and policy." }, "java": { "title": "Distributed systems when there is a need", "what": "Partial failure, consistency, delivery semantics, ordering, idempotent consumers, outbox, sagas, deeper messaging, and splitting a service when clearly justified.", "why": "You understand the consequences of distributing a system.", "evidence": "Redelivering an event doesn't repeat its effect, and a failure in part of the journey has clear recovery and tests." }, "engineering": { "title": "Scaling decisions and trade-offs", "what": "Scale estimates, a cost model, buy versus build, monolith versus services, contracts, and a migration plan.", "why": "Added complexity must pay for itself.", "evidence": "You prove a bottleneck or a need for independence, compare solutions, and have a rollback plan." }, "professional": { "title": "Negotiation and mentoring", "what": "Negotiating scope, time, and quality; delegation; mentoring; and resolving disagreement with evidence.", "why": "A senior's impact includes enabling others.", "evidence": "A colleague delivers an independent part while you review the risks and the result without doing every detail." } } }, { "id": "19", "stage": "stage-6", "title": "A shared platform and its economics", "platform": "Reproducible environments for several teams, and measured cost per center, student, and AI session.", "tracks": { "ai": { "title": "Operating AI at product scale", "what": "Versioned prompts/evals, model selection, routing/fallback, caching, budgets, monitoring, data policies, and reviewing provider changes.", "why": "Quality, cost, and behavior are tracked as usage and models change.", "evidence": "A model or prompt change goes through tests, gradual rollout, rollback, and a cost and quality comparison." }, "java": { "title": "Shared platform engineering", "what": "Cloud architecture, IAM/networking, Infrastructure as Code such as Terraform, IaC review, deployment strategies, supply-chain security, and Kubernetes when operationally justified.", "why": "Multiple teams build and operate on reliable foundations.", "evidence": "Creating a reproducible environment, testing its isolation and recovery, and measuring its operating cost." }, "engineering": { "title": "Platform economics", "what": "Cost per tenant, student, and AI session; budgets; quotas; customer support; investment priorities; and vendor risks.", "why": "Growth stays sustainable.", "evidence": "A technical decision that improves a measured cost or experience, with its side effects explained." }, "professional": { "title": "Communicating with management and product", "what": "Executive summaries and presenting options in terms of impact, cost, and risk.", "why": "You connect engineering investment to the organization's goals.", "evidence": "A non-technical decision maker understands the alternatives and can choose between them." } } }, { "id": "20", "stage": "stage-6", "title": "Architecture and strategy across teams", "platform": "API and event governance across the platform's teams, and shared migrations that don't break consumers.", "tracks": { "ai": { "title": "Enabling teams with AI", "what": "Task and context templates, tool guardrails, evaluating workflows, and quality and rework metrics.", "why": "The benefit extends to the team and can be measured.", "evidence": "A pilot that shows delivery time, defects, and rework, then a recommendation based on the results." }, "java": { "title": "Architecture across teams", "what": "API/event governance, compatibility, schema evolution, platform boundaries, migration at scale, and reliability/security standards.", "why": "One team's changes don't break the rest of the platform.", "evidence": "A migration shared across teams without unplanned downtime or broken consumers." }, "engineering": { "title": "Technical strategy and portfolio", "what": "Capability maps, build versus buy, sequencing, technical debt, investment priorities, and tying the technical roadmap to the product.", "why": "You direct several teams' effort toward the organization's most important problems.", "evidence": "A strategy that turns into deliverable, measurable initiatives and is revised with evidence." }, "professional": { "title": "Influence without direct authority", "what": "Stakeholder alignment, proposals, managing disagreement, and mentoring technical leaders.", "why": "The scope of the work is larger than one person's authority.", "evidence": "Teams adopt a decision, implement it, and keep it going after you step back from the daily details." } } }, { "id": "21", "stage": "stage-6", "title": "Deep specialization and growing leaders", "platform": "A deep specialization that solves recurring problems in the platform, and leaders and teams who carry the direction forward independently.", "tracks": { "ai": { "title": "Choosing opportunities and the limits of automation", "what": "Assessing where AI helps and where rules or traditional search are enough, with an exit strategy from a costly dependency.", "why": "You choose an investment that fits the problem.", "evidence": "You accept or reject an AI project with a reviewable comparison." }, "java": { "title": "Deep specialization by direction", "what": "Choosing a field: JVM/performance, distributed systems, security, data, platform, or AI systems.", "why": "You build depth to solve hard, recurring problems.", "evidence": "A solution that affects several systems or teams, and reusable knowledge." }, "engineering": { "title": "Staff / Architect scope", "what": "An ambiguous problem across teams, a target architecture, a transition roadmap, organizational consequences, and measuring long-term impact.", "why": "You expand the organization's ability to build and change.", "evidence": "Sustained improvement in delivery, reliability, cost, or product growth across more than one team." }, "professional": { "title": "Growing leaders and continuity", "what": "Coaching, succession, communities of practice, and distributing knowledge and ownership.", "why": "The results continue without permanent dependence on you.", "evidence": "Leaders and teams develop the direction and make suitable decisions independently." } } } ], "statuses": [ { "id": "not-started", "label": "Not started" }, { "id": "learning", "label": "Learning" }, { "id": "applied", "label": "Applied" }, { "id": "can-explain", "label": "Can explain and adapt" } ] }