Here’s another example from my engineering experience record for the PEO. The company developed software for the television industry and it was my first job after grad school.
Work Experience
The only wrinkle in this introductory section is that my direct supervisor at the company was not licensed engineer. Fortunately, one of my team members was licensed and agreed to act as a reference.
| Start Date | (after school finished) |
| End Date | (a couple of years later) |
| Company | A company in the TV industry |
| Position | Software Developer |
| Supervisor | (My direct supervisor, not a P. Eng.) (Mailing address) |
| P. Eng reference (colleague) | (A former colleague, who was a P. Eng.) (Mailing address) License: 123456789 (PEO) |
| Responsibilities | Member of a software development team that developed and tested (programming language)-based software for digital cable television. My team was focused on (specific feature list) functionality on the client (set-top box or TV) and server. |
2.2.1 Application of Theory
The most notable thing here is that I put N/A for the implementation section. Some might say “but you developed software – surely you implemented something?”. Perhaps, but that is not my interpretation of the categories in this section. Software development is part of synthesis (Design & Synthesis). Implementation means putting what you created into practice. This company did that, of course, deploying our software to millions of customers. I was not, however involved in that process (release engineering). We developed and tested the software, but were not involved in deploying it. Besides, I have the Implementation section covered in other jobs.
| Analysis | To support multiple hardware platforms (different set-top box and TV models), the software team maintained a set of automated tests to confirm that a particular platform confirmed to the expected application programming interface (API) behaviour. I wrote tests in (programming language) to evaluate if specific engineering change notices (ECNs) had been included in a firmware version. I executed these tests on beta releases of new hardware and reported issues found to the 3rd party hardware vendor. |
| Design and Synthesis | I co-designed and developed the module responsible for the (general feature) implementation. Specifically, I developed the software module responsible for enabling and managing (specific feature). |
| Testing Methods | We employed the test-driven-development (TDD) method of software development. For all software that I wrote, I first wrote unit tests to verify the basic functionality of new (programming language) classes. Then, I wrote integration level tests to verify correct functional behaviour from a collection of classes. These tests were run continuously on the team's software as it was developed. I investigated test failures to determine whether the failure was a defect in the production software, test software, hardware platform, or environment (example environment elements when developing for TV). |
| Implementation Methods | N/A |
2.2.2 Practical Experience
If you’re anything like me, when you are writing your experience record, you’ll feel good and confident about some of what you write and then you’ll write things that feel shaky and a bit of a stretch. This section, for this job, is one that I felt went well.
| Function of components as part of the larger system | The (description of software that I helped develop) was one component in a system that delivered a functional (TV feature descriptor) experience to the user. The middleware interfaced with the set-top hardware via the firmware. The user interacted with the system via the Electronic Program Guide (EPG) software running atop the middleware. The middleware retrieved program data via the digital cable network from the head-end (central server). Debugging and resolving issues discovered by the QA team required an understanding of the entire system. I investigated and uncovered defects in both the firmware and EPG layers which were originally filed as a defect against the middleware layer. |
| Limitations of practical engineering and related human systems in achieving desired goals | The (specific TV) schedule was required to contain specific duration days of data. The resultant size of the data file meant that download time from the head-end to the client was unacceptably long. I co-developed and tested a modification to the specific software to unpack a compressed version of the schedule (packed at the head-end). The compressed file was less than 10% the size of the original file and reduced the download time to an acceptable value. |
| The significance of time in the engineering process | One hardware vendor, located in Japan, was late in bringing their platform up to the expected level of API conformance. In order to get back on schedule, the vendor's principal engineer visited our site, where we worked a significant amount of overtime together for one week. I demonstrated the areas of API non-conformance to this engineer and verified the firmware patches he developed to address those issues. |
| Knowledge and understanding of codes, standards, regulations and laws that govern applicable engineering activities | The middleware I co-developed was required to conform to the (speicific software standard) to satisfy a requirement of the (regulatory body) that by July 1, 2007 set-top boxes and other digital cable television 3rd party devices should be interchangeably usable on any proprietary cable television network. I read and interpreted the relevant sections of the specific standard in order to design and develop the (software description). For one issue related to (specific feature), I discovered an ambiguity in the (spec name) specification, which I worked with the specification authors and various hardware vendors to clarify. |
2.2.3 Management of Engineering
As I mentioned previously, sectioned marked as N/A are covered in entries for other jobs. If you’re only writing up a single job for your experience record, I recommend breaking your experience record into different projects. Either way, make sure that each sub-section has at least one answer throughout your record.
| Planning | Our software development followed the Agile methodology, instead of the more traditional Waterfall method. This entailed planning our work in bi-weekly iterations. I participated in and eventually led iteration planning meetings where team members discussed and then estimated upcoming tasks in terms of effort required. |
| Scheduling | Adhering to the Agile methodology, I updated burn-down charts that showed the progress for a given bi-weekly iteration, represented the team at company-wide stand-up meetings to discuss blocking issues and participated in retrospective meetings to review the strengths and weaknesses of our scheduling and estimation techniques. |
| Budgeting | N/A |
| Supervision | I represented the team at daily company-wide stand-up meetings intended to review and address any schedule-blocking issues. When the (name of my team) team's manager was not present (e.g. due to sick leave or vacation), I fulfilled his duties, including moderating the team's daily internal stand-up meetings and being the team's external representative to other development teams and 3rd parties. |
| Project Control | N/A |
| Risk Assessment | N/A |
2.2.4 Communication Skills
If there’s one thing you get exposed to quite a bit during graduate studies, it’s communication. Heck, I took a graduate level course on scientific communication. Let’s face it, in the majority of jobs when you are fresh out of school, you will rarely have the opportunity to give presentations, internally or to the public. However, even the most junior positions involve some form of communication.
| Preparing written work | I wrote daily e-mail correspondence with internal and external team members, management, and 3rd party partners. I wrote weekly status reports on my activities during the previous week. I wrote and revised design documents for (general feature) components, such as (specific feature). |
| Oral Reports or Presentations | I provided daily oral updates to management at the company-wide stand-up meeting on the progress and challenges facing the (name of my team) team in their current development iteration. |
| Presentations to General Public | N/A |
2.2.5 Social Implications of Engineering
If I can describe a benefit to the public, from developing software that enables people to watch television, you can do it for your past work experience.
| The value of benefits of engineering work to the public | The implementation of the (standard name) platform on the (big North American cable company) cable network meant that (cable company) customers were no longer required to rent or buy hardware from a single vendor. This introduction of competition into the set-top technology space resulted in increased choice at competitive pricing for the consumer. |
| The safeguards in place to protect the employees and the public and mitigate adverse impacts | I co-implemented and tested the parental control module, which allowed parents to implement a PIN-protected access to a subset of viewing content (e.g. content inappropriate for children). This module included a PIN lockout functionality, which would disable PIN entry for a period of time if the PIN was erroneously entered on 3 consecutive tries. If the set-top box lost communication with the program schedule server, all non-described content would become PIN-locked, in order to protect children viewers. |
| The relationship between engineering activity and the public at large | N/A |
| The significant role of regulatory agencies on the practice of engineering | The FCC's ruling that cable customers must be able to use 3rd party hardware to view digital cable content is what motivated the development of an standard name-capable middleware. The deadline of the ruling (July 1st, 2007) also placed an aggressive constraint on the engineering timelines. |
That’s it for my stint in TV land. If you actually read through the whole thing, please take the time to leave a comment, tweet at me, or send me an e-mail. It would be invaluable for me to hear whether these posts are of use to anyone. If I’m not providing the type of information or advice you need, let me know and I’ll do my best to rectify that!
Next up: my first position in the medical devices field.