Skip to main content
DevScallix

DevScallix Residency

Planned

For the gap between a course and a job: a realistic engineering environment.

Engineering Residency is a planned program where participants, selected through assessment, work in a team environment using real engineering practices.

01Workflow

How you will work in the Residency

  1. 01

    Backlog

    Planning from a prioritised list of work.

  2. 02

    Tickets

    Tasks with clear requirements and acceptance criteria.

  3. 03

    Git workflow

    Branches, commits and team conventions.

  4. 04

    Pull Requests

    Every change is submitted through a PR.

  5. 05

    Code review

    Feedback from mentors and teammates.

  6. 06

    Testing

    Automated tests that protect each change.

  7. 07

    Architecture decisions

    Discussing and documenting decisions.

  8. 08

    CI/CD

    Automated verification and delivery.

  9. 09

    Deployments

    Running the work in a real environment.

  10. 10

    Demos

    Presenting completed work to the team.

12 weeks

Week-by-week syllabus

This is the planned syllabus: order and depth may be adjusted to the group. It is not a job or title guarantee.

01 · Weeks 1–2

Sprint 1: onboarding and first delivery

Phase goal: Form the squad, agree the working agreement and Definition of Done, get the repo and CI running, and ship the first small tasks through pull requests.

  1. Week 1

    Kickoff, working agreement and backlog

    • What the Residency is and is not
    • Roles: mentor, product owner, rotating scrum master, developer
    • Working agreement, Definition of Done, branching and PR rules
    • User stories, acceptance criteria and the sprint-1 backlog

    Lab: The squad writes its working agreement and DoD, sets up the repo and CI, refines the backlog and plans sprint 1.

    Assignment: Individual: a PR for the first task (your intro in the README, CI green); submit the PR link.

  2. Week 2

    Daily standups, PR flow and sprint 1 execution

    • Daily standup: three questions and raising blockers
    • Small PRs, commit messages and review turnaround
    • The board and WIP limits
    • Sprint review (demo) and the first retrospective

    Lab: Execute the sprint-1 backlog with a daily standup; end with a 10-minute demo and a retro.

    Assignment: Individual: a sprint-1 contribution note (PRs, reviews, lessons) and one improvement proposal for the retro.

Checkpoint: A working CI, the agreed working agreement and DoD, and a sprint-1 demo (at least one merged PR per participant).

02 · Weeks 3–4

Sprint 2: delivering with quality

Phase goal: Stabilise testing, code review and QA habits; deliver the first full feature slice.

  1. Week 3

    Sprint 2 planning and test strategy

    • Backlog refinement: splitting, dependencies, risk
    • Estimation and capacity: the team's real velocity
    • Test pyramid: unit, integration and API tests
    • Quality gates in CI

    Lab: Sprint 2 planning; a test plan per story; add test and lint gates to CI.

    Assignment: Individual: tests plus a PR for one story; the PR description explains the test strategy.

  2. Week 4

    Code review culture and QA

    • Writing reviews: specific, respectful, justified
    • Responding to reviews and resolving disagreement
    • Manual QA, exploratory testing and bug reports
    • Sprint review and retrospective: trends

    Lab: Cross-review: every participant reviews at least 3 PRs; the squad runs an exploratory QA session and triages bugs.

    Assignment: Individual: a curated note of 3 reviews you wrote and your responses to reviews you received (links plus one reflective paragraph).

Checkpoint: Sprint-2 demo: a tested, reviewed feature slice meeting the DoD; metrics (PR cycle time, test coverage).

03 · Weeks 5–6

Sprint 3: design decisions and mid-evaluation

Phase goal: Deliver larger tasks with recorded design decisions, make technical debt visible, and hold a mid-point mentor evaluation.

  1. Week 5

    Design decisions and ADRs

    • A lightweight design doc and ADRs
    • Feature flags and incremental release
    • API contracts and backward compatibility
    • Recording technical debt

    Lab: The squad holds a design discussion for a large story, writes an ADR and ships the first part behind a feature flag.

    Assignment: Individual: a personal-contribution ADR or design note (as a PR).

  2. Week 6

    Mid-point evaluation and sprint 3 close

    • Mentor evaluation: criteria and feedback format
    • Collecting portfolio evidence (PRs, reviews, ADRs, demos)
    • Sprint review: stakeholder questions
    • Retrospective: team health and dynamics

    Lab: Sprint 3 demo; the mentor holds a 15-minute mid-point evaluation conversation with each participant.

    Assignment: Individual: a portfolio index (README) with at least 5 evidence links and a plan responding to mentor feedback.

Checkpoint: At least one squad ADR, a technical debt list, and a written mid-point mentor evaluation.

04 · Weeks 7–8

Sprint 4: operations and the incident drill

Phase goal: Complete delivery with deployment, monitoring and incident response; practise a blameless postmortem.

  1. Week 7

    Deployment, configuration and monitoring

    • CI/CD deploy to staging
    • Configuration and secrets handling
    • Logs, metrics and simple alerts
    • Release checklist and rollback plan

    Lab: The squad builds a staging pipeline, adds a health endpoint and two alerts, and rehearses a rollback.

    Assignment: Individual: a PR adding one metric/alert or a runbook section, showing how you verified it.

  2. Week 8

    Incident drill and postmortem

    • Incident roles: commander, communicator, investigator
    • Triage: impact, hypothesis, mitigation
    • Blameless postmortem format
    • Sprint 4 review and retrospective

    Lab: The mentor injects a controlled fault in staging; the squad assigns roles, resolves the incident and runs a 30-minute postmortem.

    Assignment: Individual: a postmortem document with timeline, root cause and three action items (blameless language).

Checkpoint: Automated deploy to staging, key metrics and alerts, and a written postmortem from the incident drill.

05 · Weeks 9–10

Sprint 5: hardening and cross-squad integration

Phase goal: Raise quality and security, pay down technical debt, and integrate across squads through contracts.

  1. Week 9

    Technical debt, refactoring and security

    • Prioritising technical debt
    • Safe refactoring on a test net
    • Dependency checks and a basic security checklist
    • Sprint planning focused on big risks

    Lab: The squad prioritises debt items, ships two refactoring PRs and works through the security checklist.

    Assignment: Individual: a refactoring PR with before/after evidence (tests, a metric or simplification).

  2. Week 10

    Cross-squad integration and contracts

    • API contracts and versioning
    • Contract testing and mock servers
    • Dependency coordination and updates
    • Sprint 5 review and retrospective

    Lab: Two squads agree a contract, write a contract test and show an integration demo.

    Assignment: Individual: a PR for the contract or contract test, with the thread of discussion with the other squad.

Checkpoint: A cross-squad integration demo, evidence of technical debt reduction, and a security checklist.

06 · Weeks 11–12

Sprint 6: release, portfolio and final assessment

Phase goal: Prepare the product for release, present the final demo, complete the portfolio evidence and take the final assessment.

  1. Week 11

    Release readiness and final demo

    • Release candidate and regression checks
    • Documentation: README, runbook, API docs
    • Final demo script and presentation skills
    • Final sprint planning and risks

    Lab: The squad prepares a release candidate, runs regression and rehearses the final demo.

    Assignment: Individual: a documentation PR (README/runbook/API docs) and the demo script for your part.

  2. Week 12

    Final demo, portfolio and final assessment

    • The final demo and stakeholder questions
    • The mentor's final evaluation
    • Portfolio: selecting and presenting evidence
    • Final retrospective and next steps

    Lab: The final demo before a panel; an individual 20-minute final assessment conversation with each participant.

    Assignment: Individual: the completed portfolio (selected PRs, reviews, ADR, postmortem) and a self-assessment.

Checkpoint: A release (staging/demo environment), the final demo, a completed portfolio and a written final assessment.

02Engineering Residency

To be clear

Who it is intended for

Graduates of the Java Backend Career Track and external candidates with equivalent preparation. External candidates go through an assessment, an interview and a technical defense; people make the decision.

  • The Residency is not a job offer, employment or an employment contract.
  • We do not promise “a year of work experience”. The Residency is structured project experience in a realistic engineering environment.
  • Participation will be assessment-based; not everyone will be admitted.
  • Format, duration and terms are still being defined and may change.

03Engineering Residency

Apply as an external candidate

If you are not a graduate of the academy but have equivalent preparation, you can apply. Applying is not admission, and it does not mean the Residency has started.

  1. 01 Application
  2. 02 Assessment
  3. 03 Readiness review
  4. 04 Interview and technical defense
  5. 05 Human decision

Academy graduates apply from the Residency section of the platform.

Stay informed

Write to us to be among the first to hear when the Residency opens.

Join updates