Advice to candidates - keep it brief and to the point!

The requirement is not to exceed a total of 12 pages for the whole application when printed.

Detail your main responsibilities and personal contributions rather than a bland job description. You should aim to provide roughly 3000 characters as it is unlikely that less will adequately demonstrate your relevant experience.

• Don't tell a story. As soon as you find you are writing "this happened...and then this happened...and then this happened..." you need to reign it in. It can be useful to use projects as examples, but keep it to the form "For example, on this project I was responsible for specification / design / signoff of this technology, which required me to develop this solution, which required me to gain an understanding of yyy which I did through..." And a very brief description to show the level of commercial and/or technical risk involved only if it isn't obvious from the project name.

• Don't describe other people's roles unless absolutely strictly necessary, and even then keep it very brief. You may need to describe those who work for you, or who you report to, to put your position in context, but this can be as brief as "I supervise the installation team of 6 staff at EngTech level and a team leader at IEng level" or "my reports are approved by the Technical Director for the division, however I hold full responsibility for the content and accuracy of those reports".

• Don't describe what other people did before you arrived. Definitely don't say "the equipment needed replacing because of previous bad decisions", a) that's nothing to do with how good your engineering is and b) it's not showing respect to other engineers. I can't really think of a case offhand where it adds value to your application to say why the projects you are working on needed doing.

• Similarly don't say "I was worried about...so I..." Mostly just say what you do. If you feel you really need to justify why you do what you do the best way is to show an outcome.

• And definitely don't say (I've seen a few of these recently) "I disagreed with the decision so I recorded my disagreement even though I had to implement the decision". That's an internal confidential matter for your organisation which you shouldn't be making "public". (And in any case, you might have been the one who got the judgement wrong!) What you actually want to show is that where you have access to company confidential information (including this) you keep it confidential.  

• Don't say "managing the project budget is important to keep costs under control", "installing equipment to the Wiring regulations is necessary to maintain electrical safety" or any other sentence that looks like that. The panels know that already! To show that you are competent say "I manage costs on my projects by...", "I manage safety on my projects by..." 

• And also on saying the obvious, don't say (for example) "I compiled a spreadsheet using Excel" - of course you used Excel! Ok, other tools are available, the point is more about what value your spreadsheet added to the organisation, not how you did it. So "I identified an opportunity for improvement for the logging and tracking of failure data, and developed a process and spreadsheet solution which now ensures all failures can be effectively analysed on a quarterly basis" (and ideally "...resulting in x% reduction in failures") - that's far more interesting.

• To sum up the above two points: assume that you are at the same level as the panels assessing your application. So you only need to explain engineering "life" if there is something specific about your organisation or industry that is strictly relevant to your competence. 

• Don't waste words describing technology. You may need to do it briefly to put your work into context, particularly if you are explaining how your work is novel, but keep it really, really, really brief. It takes more engineering excellence to design a better pencil sharpener* than it does to fit a 13amp plug onto a supercomputer - it's not the complexity of the technology you are working on that will impress in your application, it's the complexity of the tasks you had to carry out and the amount of your own judgement you had to make.

• A simple (and very common) one to save unnecessary words: if you find you've written "I looked at solutions...I identified xxx as the best solution...so I implemented xxx" actually only the middle bit is useful. If you've identified a best solution then we can assume you had looked at solutions and that you implemented the best one.

• Also on this, and again this is where it is common to put in far, far too much detail, it doesn't matter why xxx was technically the best solution or what the alternatives were, what is interesting is how you knew it was the best one. Where did your knowledge and judgement come from. How did you check it was the right decision.

• In general, don't treat the panels as university lecturers spending a long rainy day marking coursework. Treat them as very busy engineers who just want to be able to make a judgement, as quickly as possible, as to where you fit into the scale of engineering professionals. And one thing they'll judge you on is how well you can keep your application brief and to the point!