Study for the CPEng assessment by building evidence, not by revising theory. Inventory your projects, map each to a competence element, rewrite activity descriptions as claims that name the problem, your judgement, and the outcome, then test each claim with follow-up 'why' questions until your reasoning holds without prompting.
Why This Assessment Tests Evidence, Not Recall
The CPEng assessment is a peer review of whether you practise competently and independently at the required standard. Your study material is your own project record, organised against competence elements, not a syllabus to memorise.
Engineering New Zealand operates CPEng as a chartership assessment in which experienced peers evaluate your demonstrated practice. That structure changes what studying means. There is no set list of technical topics to cover; instead, each competence element must be supported by work you can describe, defend, and discuss in depth. The unit of preparation is therefore the element-plus-evidence pair, and every hour of study should produce or sharpen one of those pairs.
Contrast this with a knowledge exam. In a knowledge exam, a gap means learning a topic. Here, a gap means you cannot yet show independent judgement in that area, and the fix is either finding better evidence from work you have done or deliberately seeking that work before you apply. Trace your last two years of projects and ask, for each one, which element it could evidence and what your own judgement contributed. Projects where you executed decisions made by others support a claim of technical competence, but they are weak evidence of independent practice.
Rewriting Activity Lists as Competence Claims
A competence claim states the situation, the engineering judgement you exercised, and the verified outcome, tied to one element. An activity list states only what happened. Convert every activity statement by asking what decision was yours and why it was sound.
Use a four-part structure when drafting each claim: context in one or two sentences, the specific judgement or action you owned, the reasoning that connects your action to the element's standard, and the outcome or verification. The reasoning sentence is easy to leave out of a draft because the decision felt obvious at the time, so check explicitly whether each claim contains one. Compare 'I prepared the structural design for a three-storey building' with 'I chose a post-tensioned floor system over a precast option after a construction-access analysis, and documented the deflection criteria I set for the contractor's shop drawings.' The second names a judgement that a peer assessor can probe.
The table below gives you a rewriting pattern. Apply it mechanically at first: take each line of your draft evidence, find the verb, and check whether the verb is a doing verb (prepared, attended, checked) or a judging verb (selected, justified, recommended, rejected, set the criteria). Doing verbs signal an activity statement. Your goal is a set of judging verbs across your evidence, because competence elements describe standards of judgement, not standards of attendance.
| Activity statement (weak) | Competence claim (strong) | What changed |
|---|---|---|
| I ran site inspections during construction. | I identified a rebar spacing deviation on site, judged it a non-conformance against the specified cover, and required a documented fix before pour, which the contractor recorded. | Names a specific judgement and its verification. |
| I was involved in the flood study. | I selected the design storm inputs and sensitivity cases for the flood model, justified them against the catchment data available, and defended them in the peer review of the report. | Shows ownership of parameters and scrutiny of the work. |
| I attended client meetings. | I presented the trade-off between programme risk and a design change, recommended a staged option, and recorded the client's accepted residual risk in the decision log. | Converts presence into communication and risk judgement. |
Ethics Elements Need Decisions, Not Quoted Codes
Ethical competence is evidenced by a real situation where you recognised a conflict, weighed your obligations, and acted and documented the result. Quote the code only to frame the analysis; the evidence is the decision.
Worked scenario one. A draft claim read: 'I uphold the Code of Ethics and always put public safety first.' That is a restatement of the standard, not evidence of meeting it. The candidate replaced it with this: during a residential development, the geotechnical report flagged settlement uncertainty at two lots, the developer pressed to proceed to slab stage without further investigation because of a financing deadline, and the candidate declined to release the foundation design, set out in writing the specific unresolved risk and the investigation needed to close it, and briefed the project manager on the programme consequence. The claim then named the obligation to the public that took priority, the commercial pressure it overrode, and the written record left behind.
Why the rewrite matters: a peer assessor cannot evaluate whether you meet an ethical standard from an assertion that you do. They can evaluate a decision with a named tension, a defensible weighing, and an outcome. Build one ethics claim this way. Look for times you disagreed with a client or colleague on a safety, quality, or sustainability matter, escalated a concern through a formal channel, or declined to certify work you could not verify. If your history genuinely contains no such situation, that is a preparation finding in itself, and the responsible step is to discuss with a mentor how such judgements arise in your practice area rather than inventing one.
When you test a finished claim, ask the 'two whys deeper' question: why did you make that choice, and why was that reason sufficient given the constraints? If the second answer references only habit or a supervisor's instruction, the claim does not yet show independence. Rework it or find a different example where the reasoning was genuinely yours.
Safety-in-Design Evidence for New Zealand Practice
Risk evidence should show risk being designed out or reduced through your own choices, with residual risk communicated to those who inherit it. A hazard register you populated is supporting material, not the competence itself.
Worked scenario two. A draft claim listed: 'I completed the health and safety design hazard register for the project.' The register proves a form was filled in; it does not show engineering judgement. The rewritten claim described the decision the register served: the candidate had specified a maintenance access route to plant on a roof, then reconsidered after a design review, replaced fixed access with a guarded walkway and a fall-arrest anchor layout during an early design workshop, documented why the elimination and guardrail options were preferred over reliance on personal fall protection, and carried the residual access constraints into the operations and maintenance manual handed to the building owner. The claim cites the design change, the reasoning about which control tier was relied on, and the communication of what remained.
The generalisable lesson is to identify, for each risk example you cite, three things: the design decision you owned, the reasoning that ranked the options, and the party who received the residual risk. In New Zealand practice, that final step is anchored in the health and safety duties that apply to your work, so study the applicable legislation and any client or industry design-review processes for your sector and reference them in your reasoning. A claim that stops at 'hazards were identified and recorded' leaves the assessor unable to distinguish you from a template.
- Name the design decision you owned, not the safety paperwork you completed.
- Explain why one control tier was preferred over the alternatives available at that design stage.
- Identify who received the residual risk and in which document it was communicated.
- Keep risk examples inside your own discipline so you can defend every technical detail.
Proving Complex Problem Solving When Your Work Feels Routine
Complexity is shown by ill-defined problems, incomplete information, and competing constraints, not by difficulty of calculation. Select examples where you defined the problem yourself and justify your choice of method and assumptions.
Separate two ideas in your evidence: complicated work and complex work. Complicated work is technically demanding but well defined, with a known method and a checkable answer. Complex work involves ambiguity about what the problem actually is, incomplete or conflicting data, and judgement about which constraints govern. Both belong in your evidence, but the elements that address problem solving require at least one example where you did the definitional work: identified that the brief as given was not the real problem, framed the options, and argued for a method under uncertainty.
A useful test when selecting examples: could a competent engineer following instructions have produced your output? If yes, the example evidences technical execution, which is still valuable, but not independent problem solving. Re-search your history for work where inputs changed mid-project, where analysis revealed the stated scope was wrong, or where you had to bound a problem with explicit assumptions and flag which conclusion would change if an assumption failed. Write the claim around that bounding and revising behaviour, and be ready to explain in your own words what made the problem open-ended.
Communication and Stakeholder Claims Beyond Report Writing
Communication competence is evidenced by tailoring, influencing, and handling disagreement, including obligations that affect public safety. Describe what the audience needed, what you changed because of them, and what the exchange produced.
Most engineering work involves writing and meetings, so 'I wrote the report' evidences nothing distinctive. Claims in this area should show audience analysis and effect: what the stakeholder's decision or knowledge gap was, how you adapted the technical content, and what the interaction changed. Strong examples include translating a technical risk into commercial terms for a client board, resolving a disagreement between two contractors about an interface responsibility, or briefing a community group in plain language about what a design does and does not control.
Include at least one example where communication carried a safety or quality consequence, because those show the professional weight of the skill: a written instruction that prevented a wrong installation, a clearly framed caveat that stopped a client from over-relying on a preliminary result, or an escalation when verbal assurances were not being implemented. Prepare to discuss how you verify that your communication worked, for example by confirming the recipient's understanding or checking that the document was actioned, since that closing loop is what separates transmission from engagement.
A Preparation Sequence, Exercise, and Readiness Rubric
Prepare in a fixed order: read the competence elements, inventory your projects, select and map evidence, draft claims, get an independent review, then rehearse defending each claim aloud. Use the rubric below to decide when you are ready.
Practical exercise. Take three projects spanning your recent practice, ideally including one with a client or stakeholder conflict and one with a design risk decision. For each project, list every judgement you personally made, then map each judgement to the competence element it best supports. Expected observations: some elements will attract several mapped judgements while others attract none, and the none-column is your gap list. Self-check rubric for each draft claim: score one point each for a named decision you owned, an explicit reasoning sentence, a verified outcome, and a surviving round of two 'why' questions. Four out of four per claim is the working milestone; treat it as a quality check on your evidence, not a prediction of any assessment outcome. Repeat the mapping with a fourth project only if the first three left gaps; adding volume without mapping just produces more activity statements.
A realistic sequence, adaptable to your timeline: first, read the current CPEng competence standard and element descriptors on the Engineering New Zealand site so your claims use the assessor's language; second, run the project inventory and mapping exercise above; third, draft one claim per element using the context-judgement-reasoning-outcome structure; fourth, give the drafts to a colleague or mentor who was not involved in the projects and ask them to mark every sentence that does not name a decision you owned; fifth, rehearse aloud, answering 'why did you do that' twice in a row for each claim; finally, re-check current administrative requirements, which are published by Engineering New Zealand and change over time.
Readiness is a defensible evidence set, and defensible means each claim survives a stranger's scrutiny. When your reviewer can state, in their own words, what judgement you exercised and why it was sound, without you prompting them, that claim is finished.
- Every element has at least one example from recent, independent practice where you owned the decision.
- Each claim contains an explicit reasoning sentence connecting your action to the element's standard.
- A reviewer unfamiliar with the projects can restate your judgement and reasoning back to you accurately.
- For each claim, you can answer 'why' two levels deep without reverting to 'that was the standard approach'.
- Ethics and risk claims each contain one documented decision with a named tension and a recorded outcome.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.