This discussion is locked.
You cannot post a reply to this discussion. If you have a question start a new discussion

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

Hi,


The biggest challenge I find candidates face is actually getting around to writing their applications, and very often when I see their draft applications I can see why it took them so long - they have written FAR FAR too much! (Ok, some write too little, but that can be for another post.)


The guidance says:

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.



https://www.theiet.org/media/4251/cengieng-guidance.pdf


Trust me, "roughly 3000 characters" is plenty of room to describe what you are responsible for and what knowledge you use for your role.  A few hints for keeping it under control, these are common across many applications I've seen recently:

  • 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! 


As usual, I'd greatly appreciate any comments and other advice (especially if it contradicts the above ? ) from PRIs / PRAs.


Cheers,


Andy

* It really does. It is extremely rare that I come across an excellent pencil sharpener!
Parents
  • Ed,

    I think you are falling into a common trap. The way that UK Spec is written gives the competence, then potential ways it can be demonstrated and alongside it gives suggested evidence for these examples. Taking the one you mention, D2, this is a sub-competence of D Demonstrate effective interpersonal skills and is D2 Present and discuss proposals. It is not prepare and deliver presentations on strategic matters, nor is it lead and sustain debates with audiences, nor feed the results back to improve the proposals, though if you do these things then they can be put forward as examples. If you are writing about a project you were involved in and there was a point where you developed a design (or a project plan or a suggestion for using a different widget) and went to the project manager and discussed your idea with him/her and it was accepted, then this meets the Present and discuss proposals. Also note it is not necessary for the proposal to be accepted to show this competence, but if it wasn't accepted you will have a harder job convincing that you presented and discussed the proposal in a competent manner.

    Look at the other competences in the same way - read  the headline as the requirement and the bullet points as merely suggested examples.

    Alasdair
Reply
  • Ed,

    I think you are falling into a common trap. The way that UK Spec is written gives the competence, then potential ways it can be demonstrated and alongside it gives suggested evidence for these examples. Taking the one you mention, D2, this is a sub-competence of D Demonstrate effective interpersonal skills and is D2 Present and discuss proposals. It is not prepare and deliver presentations on strategic matters, nor is it lead and sustain debates with audiences, nor feed the results back to improve the proposals, though if you do these things then they can be put forward as examples. If you are writing about a project you were involved in and there was a point where you developed a design (or a project plan or a suggestion for using a different widget) and went to the project manager and discussed your idea with him/her and it was accepted, then this meets the Present and discuss proposals. Also note it is not necessary for the proposal to be accepted to show this competence, but if it wasn't accepted you will have a harder job convincing that you presented and discussed the proposal in a competent manner.

    Look at the other competences in the same way - read  the headline as the requirement and the bullet points as merely suggested examples.

    Alasdair
Children
No Data