An Engineers Australia assessor opens your first career episode, reads "we migrated the platform to microservices," and has half-formed a verdict before the next paragraph: this is a delivery log, not engineering. A CDR report for software engineers fails on that one distinction more often than on any format slip, because the work that feels most impressive to a developer, shipping features, closing tickets, deploying to production, reads to an assessor as task execution rather than engineering activity. This guide stays inside software: the ANZSCO code you should claim, the projects that survive as career episodes, and how to rewrite a deployment call so it demonstrates the judgment EA is actually scoring.
The format mechanics that apply to every discipline (fonts, file limits, the four mandatory components) live in our CDR format guide, and the general craft of writing an episode is covered in our career episode guide. Everything below is specific to CS and software applicants, and assumes you have read those.
What Engineers Australia Assesses in a Software Engineer CDR
EA does not score your code. It scores you against 16 competency elements from the Migration Skills Assessment (MSA) framework, grouped into three categories: Knowledge and Skill Base (elements 1.1 to 1.6), Engineering Application Ability (2.1 to 2.4), and Professional and Personal Attributes (3.1 to 3.6). Your three career episodes supply the evidence, and the Summary Statement maps that evidence to each element by paragraph number. For how the whole process fits together, see our Engineers Australia skills assessment overview.
Software carries a burden the civil and mechanical pathways do not: it is not automatically read as engineering. A monolith rewrite counts when you show the problem framing, the design alternatives, and the reasoning that ruled options out. The same rewrite described as a sequence of merged pull requests counts for nothing. The assessor wants the same thing whether you build bridges or build services: a complex problem, real constraints, options weighed, a decision owned, an outcome measured.
Two facts shape how you write. Your assessor is almost certainly not a software engineer, so unexplained jargon (idempotency, sharding, blue-green deploys) does not impress, it obscures; translate every technical term into its engineering significance. Senior applicants also face a specific risk: generalizing responsibilities or leaning on managerial oversight instead of documenting specific technical decisions reads as thin evidence regardless of title. Seniority is not evidence. A named decision is.
Choosing the Right ANZSCO Code Before You Write
Pick the code first, because it determines which projects belong in your episodes and which duties an assessor expects to see. Most software engineers apply under 261313, but the code is set by your duties, not your job title.
261313 vs 261314 vs 261111
Three codes catch most ICT applicants, and they are not interchangeable:
261313 Software Engineer: designs, develops, modifies, documents, tests, implements, installs and supports software applications and systems. Its sibling codes in unit group 2613 are 261311 Analyst Programmer and 261312 Developer Programmer.
261314 Software Tester: specifies and writes test plans and test scripts, produces test cases, runs regression testing, and uses automated tooling to verify software behaviour and integrity.
261111 ICT Business Analyst: formulates and documents business requirements, analyses business processes, and applies data and process modelling to design systems.
One correction worth keeping: 263111 is Computer Network and Systems Engineer, a different occupation entirely. If you have seen 263111 labelled "ICT Business Analyst" on CDR advice sites, discard that source.
The Duty-Description Test
Job title is irrelevant to EA; duty match controls. Run three steps. Open the ANZSCO Dictionary and read the "Tasks include" list for 261313, 261314, and 261111. Tally how many tasks in each list describe your actual daily work across the projects you plan to document. Claim the code with the highest tally. A "Senior Software Engineer" whose real week is requirements workshops and process models belongs under 261111, and three episodes of 261313 design work under that claim produce exactly the mismatch that triggers a rejection.
Selecting Three Career Episodes That Cover Distinct Competencies
Your three episodes should not repeat the same evidence. Spread them so that between them they touch design, problem-solving, and professional attributes, and choose projects with a real arc.
Project Types That Work
Strong software episodes come from work with a multi-month problem-to-solution shape: a system design carried from requirements to architecture, a platform migration (monolith to services, on-premises to cloud), a security-hardening initiative, or a third-party integration where you owned the interface design. Two quick framing notes.
A monolith-to-microservices migration frames cleanly as engineering because it forces documented trade-offs: service boundaries, data consistency, failure modes. Map it to 1.3 (specialist knowledge), 2.1 (complex problem solving), 2.3 (systematic design process), and 3.2 (communication with stakeholders).
A data-pipeline build frames around throughput and correctness constraints: schema design, backfill strategy, idempotent processing under retries. It naturally evidences 2.1, 2.2 (fluent application of engineering techniques), and 2.3.
Project Types That Fail
Some work cannot carry an episode no matter how well it is written. Bug-fix sprints, routine deployments, short-term support contracts, and single-feature releases fail for one structural reason: there is no sustained engineering problem, only a queue of outputs. Building a career episode from sprint tickets is like handing an assessor your commit history and asking them to infer the architecture. Pick projects that span at least several months and contain a decision you can name.
Reconstituting Agile Sprints
Most software applicants work in sprints, and the sprint is the wrong unit for a career episode: too short, team-owned, logged as output. The fix is not to invent a waterfall project. Identify the multi-month initiative those sprints served (the platform your team spent two quarters rebuilding), extract the architectural and design decisions you personally made across that period, and narrate those as one engineering arc. The sprints become the delivery mechanism in the background; your decisions are the story.
Writing Each Career Episode for a Software Project
Each episode runs 1,000 to 2,500 words in first person, drawn from a project within the last ten years. Check the current MSA Booklet for the precise recency window before you select projects, as EA updates this periodically. The MSA Booklet does not publish a fixed word split across sections, but in practice the Personal Engineering Activity carries the majority of each episode, with a short Introduction and Background and a compact Summary. For the paragraph-numbering rules, see our career episode format guide.
The Introduction scopes the project in a few sentences without reciting the entire stack. The Background states your role, the constraints, and why the problem was non-trivial as engineering, not why the product mattered commercially.
The Personal Engineering Activity, Rewritten
The PEA is where software CDRs are won or lost, and the failure is always the same: describing what the team shipped instead of what you decided. Compare the two.
Before (IT task execution): "We deployed the API to AWS."
After (engineering judgment): "I evaluated three deployment architectures to meet a 200ms p95 latency target: serverless Lambda incurred cold-start penalties at our expected concurrency, so I selected ECS Fargate with auto-scaling configured to hold two warm replicas, cutting p95 latency from 340ms to 180ms in load testing."
The second sentence hands the assessor a complex problem (2.1), a systematic evaluation (2.3), specialist knowledge applied (1.3), and a measured outcome, all inside one "I" statement. The first gives them nothing to score. This is the core move for a CDR report for software engineers: every significant paragraph should name a decision only you could have made, the options you rejected, and how you knew you were right. For the finer points of "I" versus "we" framing, see our I-statements guide.
The Summary closes the episode by stating what you delivered and what it demonstrated about your engineering judgment, not a project retrospective.
Building the Summary Statement After Your Episodes Are Done
The Summary Statement is a cross-reference table, not an essay. For each of the 16 competency elements, you cite the exact career episode paragraph numbers that evidence it. That is why it cannot be written first: the paragraph numbers do not exist until the episodes are final, and every later edit that shifts a paragraph breaks the mapping.
Software applicants make two mapping errors more than most. They over-claim the Professional and Personal Attributes elements (3.1 to 3.6) from paragraphs that only describe technical work, and they cite the same two or three paragraphs against eight different elements, which signals thin evidence. Map each element to a distinct, genuinely relevant paragraph, and if an element has no paragraph behind it, the fix belongs in the episode, not the table.
CPD Activities Engineers Australia Accepts from Software Engineers
EA publishes minimum CPD hour requirements and activity-type definitions in the MSA Booklet; check the current booklet for the precise figures before you plan your log, as thresholds are updated periodically. The framework recognizes multiple structured and unstructured activity types, and software work maps onto them directly:
Cloud certifications (AWS, GCP, Azure): short courses and workshops.
IEEE or ACM conferences and internal architecture review boards: technical meetings.
Distributed-systems or security MOOCs and postgraduate units: formal education.
Open-source contributions with a documented technical outcome, plus self-directed reading: private study (subject to the cap stated in the current MSA Booklet).
Mentoring junior developers, presenting internal tech talks, and authoring peer-reviewed papers each fall under their own named categories.
The generic activity types are the same for every engineer; the value is knowing which of your actual software activities count under each.
Rejection Patterns in a CDR Report for Software Engineers
Three failures account for most ICT rejections, and all three are preventable before you submit.
Generic project descriptions with no personal decision trail. If your episode would read identically under a teammate's name, it carries no individual evidence. Name the decision, the alternatives, and the reasoning.
Team output presented as individual competency. "We built," "the team designed," and "our service" are invisible to an assessor scoring you. Even genuinely collaborative work (code review, pair programming, shared repositories) has to be narrated as your specific contribution within it.
Mismatched ANZSCO code and content. Episodes of pure 261313 design work filed under a 261111 claim, or configuration and support tasks dressed up as design, read as technician-level execution rather than engineering. The duty-description test above is the prevention.
The current EA assessment fee and the fast-track surcharge change with annual indexation, so rather than quote a figure that dates, check the current CDR fees breakdown before you budget.
Software Engineer CDR: Questions Assessors Ask Most
Which ANZSCO code should a software engineer use for an Engineers Australia CDR?
Most software engineers use 261313 (Software Engineer), but the correct code is the one whose ANZSCO "Tasks include" list best matches your actual duties, not your job title. If your real work is test planning and regression, 261314 fits; if it is requirements and process modelling, 261111 fits. Run the duty tally before committing.
Can an agile development sprint be used as a career episode?
Not on its own. A single sprint is too short and too team-oriented to show a sustained engineering arc. Use the multi-month initiative the sprints delivered, and build the episode around the architectural and design decisions you personally made across it.
How do you show personal engineering contribution when you worked in a development team?
Write in the first person about decisions only you made: the interface you designed, the data model you chose, the trade-off you resolved. Collaborative activities can stay in the narrative as context, but the scored evidence must be your individual judgment, phrased as "I" statements.
Does a software engineering degree need to be accredited by Engineers Australia to submit a CDR?
No. The CDR pathway exists precisely for engineers whose qualifications are not covered by an accreditation agreement. If your program is covered by an accreditation agreement such as the Washington Accord, a different assessment pathway may apply, so confirm your degree's status directly with Engineers Australia at engineersaustralia.org.au. For the many CS and IT graduates whose degrees are not covered, the CDR is the route regardless of the degree's title.
How much technical detail, code, architecture diagrams, stack specifics, should go into a career episode?
Enough to make your decision legible, no more. Skip code listings entirely. Reference an architecture only to explain a choice, and translate every technical term into its engineering significance, because your assessor may not be a software specialist. Depth of reasoning beats breadth of stack.
Where to Go Next
A CDR report for software engineers lives or dies on one habit: turning work you experienced as delivery into decisions an assessor can score. If you want to see that standard on the page before you write, read our career episode examples, or look at how our CDR writing service frames software projects for a positive assessment.