1. Compiling your CV
Maybe you’ve not compiled a CV in a while or think your CV needs a refresh…..read on
Tell a story
A good Developers CV should tell a story, clearly detailing the projects you’ve worked on, how you were involved in that project, interspersed with the technologies you used to get the job done. You should then ensure that each role is well defined, with bold type at the head of each role, when you were there and the overall achievements / successes you had while you were in that role.
You should provide as much personal project detail as possible that’s digestible. Describe the project, what its written in and ideally any source code (e.g. githib) you can display is highly appealing to potential employers. Don’t forget to include any social meet-‐ups, open-‐source project code commits (if relevant to your skill set) that you’ve attended/contributed to. Employers love to see a passion for technology and offering up your own passions, ideally but not exclusively if they’re commercially relevant is a great first impression on your CV.
Clients want to know how you’re used to working. Bigger teams, smaller? What do you use for unit-testing? TDD/BDD literate? Ensure you’ve put in the types of methodologies you’re used to working in; Agile is the mainstay of many a technology organisation, and any contributions you’ve made to facilitating the running of or simply taking an active part in Agile sprints and subsequent projects, the better. What toolsets within Agile have you been exposed to, etc. (For those Agile specialists wanting to pick up on that, I realise Agile isn’t a methodology but a mind-set, but wanted to illustrate as simply as possible!)
Don’t turn technical keywords into spam!
Lastly, try to keep the keywords in your CV succinct to apply to projects you’ve worked on. In other words, be mindful of not putting in large numbers of technical key words in order to get yourself noticed. It can work in terms of catching you on database searches, but if it’s too much, it can impede on the quality of your CV Skills matrices should be succinct and relevant to a type of role you’re realistically going for.
2. Research your interviewer
It is well understood that if you’ve made the effort to look up the background (and potentially commonalities) of anybody you come into contact with, there’s instantly an easier rapport. So, in the same spirit, an interviewer will always appreciate that you’ve made the effort to establish rapport early on in the interview, so ensure you’ve researched them.
Simple means to this end are LinkedIn, Twitter and of course, assuming they’re more technically persuaded, any code they may display on Github, StackOverflow, or indeed more generally, any communities they’re engaged with (e.g. Ruby User Groups, .Net User Groups, Agile Practitioners Groups, Prince Practitioner Groups, Technology Groups, whatever their professional persuasion) and blogs they’ve written. Get a feeling for hot topics they’re interested about and take the time to understand them, where you can. You don’t have to be an expert, but going that extra distance to show interest can make all the difference.
3. Get an inside referral
As recruiters, we’ll have the inside track to information about roles and opportunities with any given number of clients. We can highlight your profile to the best around, tell them your project successes and generally market your CV by telephone or face to face with managers. But, when presented with an opportunity, bear in mind anyone you’ve worked with that can give you a positive recommendation at a particular job application. One caveat to this is be 100% sure revealing this will be of positive influence to the process; as well as you got on with someone, they have tremendous power to sway the decision to interview one way or the other and they may be overtly “honest” about a small thing that can have an undue influence. Do consult with your recruitment consultant on that, they will know the politics of an organisation and its processes and help make that judgement call.
4. Learn to solve algorithm based problems
Many technical job interviews include questions that require you to solve a coding problem, on-‐ paper or on-‐screen, yet a lot of developers can find this a daunting prospect and fail to get across their full potential.
We would highly recommend you practice and practice at doing algorithmic problems in coding to equip you for that eventuality. Some people resist coding problems at interview (and it can be gotten around if you have a strong github /stack overflow account and can show your code to them) but it will come up at some point, and you’ll improve your competitiveness if you take on these challenges regularly, making you less nervous and building your confidence atinterview.
5. Show passion in interview
Something that so many people fail to get across is how much they love technology and thus fail to engage properly with the interviewer. You may have a real love for Angular.js, but if you only explain that you “have used it and what for”, you aren’t offering up your insight into why you’re passionate about it.
You need to show the right sort of passionate display that will make you not only functionable to work with, but downright interesting too. What are you reading at the moment? What are your thoughts on Continuous Integration, progressive enhancement, Agile tools such as Kaizen, Lean, SAFE etc?
When you’re asked about this sort of thing (or better still, can offer up information on these sorts of subjects at an appropriate time in the interview) you’re being asked to show off your own opinions
and basis for those opinions to see what makes you tick. Most teams will want to see how you would gel with them, and this is a perfect opportunity to display what makes you interesting as an IT professional, whatever technology you’re in, project / product you deliver or technical teams you have put together.
It is worth noting, not all interviewers think the same way, and you have to be a little empathetic of when it is time to let them speak, but the point is you should try and show some passion in your answers and expand upon them if possible.
6. Avoid “trick” questions
“Why are you looking for a new opportunity?”
“What don’t you like about (delete as appropriate) Project Managers / Business Analysts / Developers etc?”
“Name your greatest strength and your greatest weakness.”
“When you last came into conflict with a colleague, how did you resolve it?”
It’s important to think ahead about the type of response you want to give to these questions. Granted you’ll need to think on your feet, given how vast the array of these questions can be, but remember one rule, keep it positive and ask yourself how you think you’d sound…. to you.
For example, “name your greatest weakness”
You would answer this as if you saw something negative in what others might ambiguously see as a positive. E.g. I sometimes take my work home with me, I’m a perfectionist, I may spend too much additional time on a particular issue in order to complete it.
Likewise, when talking about Strengths, arrogance or over-‐confidence (if not backed up by real-‐ world examples) can put your interviewer on the back foot. Saying you’re looking for a new opportunity “because you don’t get on with your boss” or “don’t like colleagues” will only give negative connotations so think about the positive spin you have for your current company, what you’ve learnt etc, and then explain that you’re looking for “enhanced challenges”, “certain projects in X technology” etc.
7. Don’t over-inflate your experience
(and certainly don’t lie)
This can also go back to CV layout too. Firstly, as mentioned before don’t spam a million technologies on your CV , to then have to try and explain something you mildly touched on 5 years ago. Keep that CV relevant to what you can bringto a practical working environment. Nothing wrong in listing a few technologies as interests, but don’t ever say you’ve worked on a technology that you haven’t.
There is a good chance whatever an interviewer is going to ask you about is something they are familiar with. For that reason, even if you consider yourself a good “blagger”, most of your blagging will be instantly detected and you’ll immediately lose your integrity, which is very hard to ever gain back in interview.
8. Don’t ever be brutally honest
Many candidates can over-‐emphasise certain personal details about themselves with the desired effect being they’re open, honest and that that endears themselves to employers. It can often have the very opposite effect.
Keep all the minutiae about your life and personal issues out of the conversation, in the same way as you want to create a positive image from your work history, so too should you maintain a professional demeanour by not releasing every raw detail about your life.
Personality is good, character flaws are bad.
Don’t ever lie, but don’t offer up details that will paint you in a bad picture. The interviewer may, internally, react negatively to those details and then infer you may have a certain lack of judgement as a result.
9. Make sure you’re Computer Science
knowledge is in some shape….
For programmers, while you may not have a University or College background, these days its becoming a standard requirement to have a formal qualification and understanding the academic and subsequent practical theory is important. We’re seeing more and more specifications for roles that require a formal degree or training background in addition to practical experience, so do get to understand the basics at least.
Clients will, for the most part, want to know there’s some quality control in what you know about Computer Science before hiring you.
10. Be Creative with your approach
Most people who work in technology who’re either starting out or moving to a different area ask: “How do I get the experience that these employers are looking for in the first place?”.
For Project Managers or Business Analysts, this may be requirements to get into an Agile-‐oriented role or a certainindustry. For Developers a specific technology that’s becoming more popular. For Business Intelligence professionals, new tools and analytics practices. The list goes on.
This comes down to being creative and hungry to get into / or move to new areas of technology. For Developers:
Here are just a few ideas:
· Start or Join an open source project and display it on Github or StackOverflow
· Build a mobile app and put it in the app store
· Build a small web app and display it on Github or StackOverflow
· Start a blog
· Present at / Attend technical meet-‐ups or other user groups
The same principle applies to pretty much any discipline. There are meet-‐ups often in your local area, for Project Managers, Business Analysts, Quality Assurance Specialists, Business Intelligence Specialists and Graduates in all these areas. Blog about latest software delivery techniques, new products that have benefitted from methods used, new innovations. Anything that will make you stand out and start to add interests and achievements on your CV for your chosen area.
Always be asking how you can improve your CV and interview approach, keep an eye on new phenomena in the industry you work in and engage the community around it. You’ll find people respond greatly when you put in that little bit of effort.
Lastly, if you’ve enjoyed reading the tips here, do get in touch with Leo Townsend at Recommend, who can provide you with great CV advice, insight into the market and the latest hot jobs in the Technology space. Email him at firstname.lastname@example.org