A competency review rewards evidence you can defend under follow-up questioning, and the hard part of building that evidence is separating what you personally decided from what your team achieved. Start by auditing your project history against each competency area and writing a one-sentence decision statement for every example: what you chose, what you rejected, and why. Then stress-test each story with layered 'who decided' and 'what else' probes until it survives without borrowing credit from colleagues. This guide shows how to select evidence projects, reason through ethics and risk scenarios, and rehearse against a concrete rubric.
What the Review Examines: Ownership of Your Engineering Judgments
The review examines your competence across technical work, ethics, problem solving, leadership, communication, and risk. Whatever form the questioning takes, evidence stands or falls on whether the judgments you describe were genuinely yours.
The distinction that drives everything else is involvement versus competence. Being on a project team, attending meetings, or producing drawings under supervision demonstrates involvement. Competence means you made consequential decisions: you chose between options, accepted or rejected a risk, resolved a conflict, or took responsibility for advice given to a client. When a follow-up question asks who decided, what the alternatives were, and why yours was chosen, an involvement-based story stalls because it has no decision at its center.
This changes how you should read the competency areas — professional engineering competence, ethics and legal obligations, complex problem solving, leadership and teamwork, communication and stakeholder engagement, and risk, safety, and sustainability. Treat each area as a claim you must evidence with a decision. Build a simple map: for each area, name the project, the decision, the alternatives you considered, and the consequence of your choice. Gaps in that map tell you where preparation needs work before the review, not after.
Choosing Evidence Projects: Depth Beats Prestige
Select projects where you owned real decisions, not the largest or most impressive projects on your CV. A modest piece of work you controlled evidences competence better than a landmark project where you were a small contributor.
A plausible mistake is leading with a flagship project because it sounds impressive. Consider an engineer who presents a major rail interchange where they ran clash-detection reviews within a large multidisciplinary team. Probing — who set the tolerance criteria, who approved the resolution strategy, what happened when disciplines disagreed — reveals those calls sat with the lead engineer. The candidate then scrambles, and the conversation drifts toward the team's achievement rather than their judgment. Prestige cannot substitute for ownership once questioning goes deeper than the summary.
A better selection strategy is a coverage matrix. List the competency areas from your application down one axis and your candidate projects along the other, marking where you personally made the key decision. Aim for each area to be covered by at least one strong, uncontested example, and expect to use one project through several lenses — the same job can evidence technical judgment and stakeholder communication if the decisions differ. Covering every area with defensible examples is more persuasive than one spectacular story with thin personal ownership.
- Coverage check: every competency area maps to at least one project where you made the deciding call
- Ownership check: for each example, you can name the decision, the alternatives, and the outcome without borrowing credit
- Recency and relevance check: the evidence reflects work at the professional level you are claiming
Ethics Scenarios: Escalate, Verify, and Put It in Writing
An ethics prompt may present a workplace dilemma. Strong answers apply a named ethical duty — community safety and wellbeing first — then describe a concrete escalation path with documentation, rather than deferring to hierarchy or improvising.
Worked scenario: you discover, two days before a construction deadline, that a steel connection detail installed on site deviates from the issued drawings. The contractor argues it still works, and your project manager wants to accept it verbally to avoid delay. Weak answer: accept the manager's call because the contractor is confident and the program is critical. This fails on two counts — it outsources your engineering judgment to a non-technical authority, and it leaves no record of the decision or the reasoning behind it.
Better decision: treat the deviation as a design change requiring engineering assessment. Review the as-built condition against the design intent and the relevant standards, form your own technical view, and if the change is acceptable, document the assessment and obtain approval through the formal variation process; if it is not, escalate in writing to whoever holds the authority to accept or reject it. The reasoning chain — verify, judge, document, escalate — is a reusable structure that holds up under follow-up; an improvised answer is not.
Complex Problem Solving: Surviving the 'What Else Did You Consider' Probe
Problem-solving questioning digs past your solution to your reasoning: what alternatives existed, what constraints shaped the choice, and what trade-offs you accepted. Preparing one linear narrative per problem leaves you nothing to say at the second follow-up.
A realistic mistake is presenting your chosen path as the only sensible one. Suppose you are asked how you resolved a foundation issue on a constrained inner-city site, and you describe the piled solution you adopted. The follow-up — why not ground improvement, what did the shallow option cost, how did you weigh program against capital cost — tests whether you genuinely compared options. If your answer is that the team simply always uses piles there, you have demonstrated habit rather than judgment, and the story offers nothing further to draw on.
Rebuild each key technical story as a decision with a visible comparison set. For the foundation case: state the problem in one sentence, name two or three alternatives you seriously evaluated, identify the deciding constraint — for example, adjacent heritage structures limiting vibration — and explain the trade-off you accepted and how you monitored it afterward. Two rejected alternatives with concrete reasons demonstrate more competence than five pages describing the adopted design. Where information was incomplete, say what you did to reduce uncertainty rather than implying certainty you did not have.
Leadership and Teamwork: Separating Your Judgment From the Team's
Leadership claims invite questions about what you personally directed, delegated, or decided when the team disagreed. Distinguish outcomes your team achieved from judgments you made, because blurred credit collapses under a single 'who decided' question.
Prepare answers that show judgment in three distinguishable forms. Direction: you set the technical approach or review structure for others to follow. Development: you identified a capability gap — say, a graduate uncertain about independent checking of calculations — and acted on it through delegation, review, or structured feedback. Conflict resolution: when two disciplines or a client and a contractor pulled in different directions, you framed the issue, facilitated a decision, and carried accountability for it. Each form needs its own example with your specific action stated first.
A useful self-test is to retell one team achievement sentence by sentence, marking every claim as 'I did', 'I directed', or 'the team did'. Anything you cannot honestly mark as yours should either be cut or reframed as context. This is accuracy, not modesty: any competency you claim is fair game for probing, so an over-claimed leadership story is a liability, while an honestly scoped one with a real decision inside it is an asset. The table below shows how ownership language changes under probing.
| Claim as stated | Typical follow-up probe | Ownership marker to add |
|---|---|---|
| We delivered the design two weeks early | What did you personally do to achieve that? | I resequenced the deliverables and reallocated two review tasks |
| The team resolved a major clash between services | Who set the resolution criteria? | I defined the acceptable clearances and signed off the revised layout |
| Our client was very satisfied | How did you know, and what was your role? | I ran the monthly reporting and handled two scope-change negotiations myself |
| The project had no reportable safety incidents | What was your contribution to that outcome? | I owned the pre-start risk reviews and closed out corrective actions weekly |
Risk, Safety, and Sustainability: Show the Reasoning, Not the Buzzwords
Risk and sustainability questions test your reasoning process: how you identified hazards, ranked controls, and documented who accepted residual risk. Naming a framework you actually used beats reciting principles you cannot connect to a real decision.
Worked scenario: during commissioning of a processing upgrade, an interlock fault means a safeguard is temporarily bypassed while production continues under manual observation. Weak answer: the operations manager accepted the risk and the schedule held. The failure is that risk acceptance was never linked to engineering analysis or authority — an observation-only control was treated as equivalent to the engineered safeguard, and no one recorded the decision or a restoration date. A well-prepared answer needs to address all three gaps at once: analysis, genuine control, and recorded acceptance.
Better decision: assess the hazard that the interlock controls using the site's risk framework, apply the hierarchy of controls to identify what temporary measures genuinely reduce exposure — engineered barriers, restricted access, or a defined shutdown — and require the residual risk to be formally accepted in writing by the person whose authority covers it, with a dated restoration plan. The same structure generalizes to sustainability trade-offs: state the requirement, quantify the realistic options, make the trade-off explicit, and document the decision. A reasoned, recorded process is the reusable skill.
A Preparation Sequence and Readiness Rubric
Run preparation in four phases: audit your evidence against the competency areas, rewrite each story around a decision, rehearse under layered probing, and finish with a full simulated review. Use the rubric as a milestone check, not a pass prediction.
Phase one: build the coverage matrix and identify gaps while there is still time to choose different examples. Phase two: for every mapped example, write a one-sentence decision statement, list two rejected alternatives with reasons, and note the standard, code, or ethical duty you relied on. Phase three: run the probe drill — a colleague takes one story and asks 'why', 'what else', and 'who decided' five times in a row; wherever you stall or borrow credit, rebuild that story. Phase four: a full mock run across all competency areas, answered aloud rather than read.
Self-check rubric — score each prepared story from 0 to 2 on five points: the decision is stated in one sentence (0 = story starts with project background; 2 = decision is the first thing you say); at least two alternatives are named with reasons; the relevant standard or ethical duty is identified by name; your personal role survives a 'who decided' question without revision; and the outcome includes what you monitored or changed afterward. A story scoring eight or more out of ten is review-ready by this learning milestone. If several stories score below six, return to phase two rather than adding more projects — depth, not volume, is what the sequence builds.
- Readiness check 1: every competency area has at least one story scoring eight or more on the rubric
- Readiness check 2: you can deliver each decision statement from memory in under thirty seconds
- Readiness check 3: the probe drill no longer surfaces borrowed credit in any prepared story
- Readiness check 4: you can reason through an unfamiliar ethics or risk scenario aloud using your documented framework
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.