Logging Your Engineering Experience: A Guide for EITs

The P.Eng experience requirement is roughly four years long, and the competency-based assessment at the end of it asks you to prove, in writing, that you exercised 34 competencies across 7 categories. There are two ways to arrive at that point. You can keep a running record of your work and walk in with most of the evidence already drafted, or you can sit down after four years and try to reconstruct dozens of projects from memory. The first path is calm and the application is strong. The second is the single most common reason candidates stall, scramble, or submit weak narratives.

Logging as you go is not bureaucratic busywork. It is the difference between an application built on specific, dated, verifiable detail and one built on vague recollection. The habit costs a few minutes a week. The absence of it costs weeks of painful reconstruction and, often, a weaker assessment. This guide is about building the habit deliberately from your first year as an EIT.

Engineering work does not store itself in memory the way the competency assessment needs it to. Six months after a project, you will remember that you did the stormwater design. You will not reliably remember the post-development peak-flow target you sized to, the three outlet options you compared, the specific guideline edition you applied, the constraint that forced a redesign, or the number you can quote as a result. Those details are exactly what a reviewer wants, and they are the first things to fade.

Worse, projects blur together. After four years of similar work, the specific decisions that distinguish one project from another, and that make a competency narrative compelling, become a single averaged impression. You also lose the timeline: who supervised what, when a phase happened, which validator can speak to which piece of work. Reconstruction does not just take time; it produces narratives that are generic precisely because the distinguishing detail is gone. A short, contemporaneous note captures what memory cannot hold.

Keep each entry short but specific. A good log entry records: the date or date range; the project name and a one-line description; what you personally did, in concrete terms; the engineering judgment you exercised and the decisions you made; the tools, codes, and standards you applied by name; any alternatives you weighed; and the outcome, with a number attached wherever possible. Note who supervised or could validate the work, and which competency or competencies the work demonstrates.

Write the "what you did" part in the first person and in active terms, because that is the form the eventual narrative needs. "Sized the detention pond to the municipal post-development target, compared three outlet configurations, selected the orifice-plate option, and verified against the governing design guideline" is a sentence you can lift almost directly into a SAR narrative two years later. "Worked on stormwater stuff" is not. Capture the specificity while you still have it, even if the prose is rough.

The right cadence is frequent enough that detail is still fresh and light enough that you actually sustain it. A weekly note works well for most EITs: at the end of each week, spend five to ten minutes recording what you did that was engineering-substantive and worth remembering. Not every week produces a competency-relevant entry, and that is fine; the point is the routine, not the volume.

Layer a milestone habit on top of the weekly one. Whenever you finish a meaningful piece of work, a design package, a report, a site campaign, a phase, write a slightly fuller entry while the decisions and results are vivid. These milestone notes are the raw material for your strongest narratives. The combination, a quick weekly sweep plus a fuller note at natural milestones, captures both the steady accumulation of experience and the standout examples, without ever requiring a heroic catch-up session.

The step that pays off most is mapping each entry to the competency framework at the moment you log it, not at the end. When you record a piece of work, ask which of the 34 competencies it best demonstrates and tag the entry accordingly. This does two things. It tells you, in real time, which competencies you are accumulating evidence for and which are still thin, so you can seek out the work that fills the gaps while you still have years to do it.

It also means that by the time you write the formal application, the hardest intellectual step, deciding which experience proves which competency, is already done. You are no longer staring at four years of undifferentiated work trying to retrofit it onto the framework. You are assembling pre-sorted, pre-tagged entries into polished narratives. Candidates who tag as they go routinely discover, a year or two in, that they have no good example for a particular competency yet, and they have ample time to fix that. Candidates who tag at the end discover the same gap with no time left.

A log only helps if it survives the years and is usable when you need it. Keep it somewhere durable and under your control, not buried in a work email account you may lose access to when you change employers, and not only in your head. A personal document, a spreadsheet, or a purpose-built experience tracker all work; what matters is that it is yours, it persists across job changes, and you can search and sort it later.

Be mindful of confidentiality. You can record the engineering substance of your work, your role, the methods and standards you applied, and quantified outcomes without exporting confidential client data or proprietary documents. Capture what you need to write a narrative and validate it, and no more. A clean, portable, well-organized log is an asset you carry through your whole EIT period and lean on heavily in the final stretch.

When you reach the end of your experience requirement, the difference between logging and not logging is stark. With a running, competency-tagged log, writing the application becomes an editing task: you pull the relevant entries for each competency, shape them into SAR narratives, and hand your validators specific, accurate accounts they can readily confirm because the detail is real and dated. The work is finite and the result is strong.

Without it, the same milestone becomes a reconstruction project layered on top of a full-time job, producing narratives that are vaguer than they should be because the distinguishing detail is gone. The experience requirement is largely fixed at around four years; how painful and how convincing the application is at the end is mostly determined by whether you logged along the way. Start in year one, keep it light, and your future self will be grateful.