Interview / job application preparation

I’ve sat on both sides of the interview table several times. I certainly don’t think I’ve mastered either end of that game, but certainly, there are some common key things you need to think about before you submit a CV and again before you hopefully head into a job interview...

Reflect on the position

Picture by @clemono2 on Unsplash

Obviously, every position is at least a little unique. Spend some time thinking about what the “killer features” in a candidate for that position might be and figure out how you can best display them in yourself. Be very sure you’ve exhaustively pored over any job or person description they’ve given, and that you’ve reflected (at the very least) on the “essential” attributes, and wherever possible, on the “desirable” ones. Some people state that job descriptions are a wish-list and not a formula that must be met, but the degree to which that is true depends on a number of things, including the size of the applicant pool, the closely related desirability of the position and whatever “gatekeepers” you might need to pass (automated CV keyword searches, people that don’t understand transferrable skills within your specialised discipline, and so on). The more relevant you look on paper in the early application process the better, but make sure you don’t oversell yourself, and certainly, never lie. 

The documents they make available are quite literally your “cheat sheet” on what they’re expecting the job to be and how to identify yourself as the best candidate – but realise that some job descriptions can be quite generic (and all too often rather vague), or even a template HR downloaded from somewhere, and the job may end up with a somewhat different set of actual priorities (but it’s unlikely they’ll be completely outside of what that documentation says, at least in larger organisations). If you see a really weird set of criteria, one of two things may be happening – either they’re a genuinely unique place with an unusual set of requirements, or sometimes that they’re trying to hire a specific already identified candidate whilst meeting the letter of their hiring policies. Avoiding that latter behaviour is one reason job descriptions/specifications are quite vague and generic, and often don’t quite meet up to what you do in the role – and fear of this happening is why HR tend to take over the role of attaching job descriptions/specifications to roles, rather than departments or line managers. 

In some instances (from what I’ve seen this is quite rare) you might be able to get hold of an actual human at the organisation that has some interest in filling the position. If you see “for more information, contact…” do so! It can be worth taking this route and having a conversation about the position and, particularly, some of the key challenges or opportunities in that role. Definitely pin down the key priorities within the job description. It may also help you (early on) find any “red flags” for you about that organisation, and also means at least one person may recall having talked to you before and seeming like a decent prospect – so treat any such conversations as semi-formal interviews, because they may have influence during the hiring process. As much as people are supposed to ignore things they know aside from the CV in front of them and what the candidate said in interviews in the interest of a “fair” and “transparent” recruitment process, human nature tends to ignore that and use all available information – and, all too often, “gut feel”. Don't lose out to other candidates that have that advantage simply because they picked up the phone a few weeks ago!

Turn the table around completely – imagine you’re assessing CVs or interviewing candidates for that position – what do you expect to see, and which are the most important factors to you? (I realise you don’t have a panopticon to see what that specific organisation needs right now, but with some experience, you’ll have a general idea of what most organisations actually need). Make sure you're presenting those qualities!

How can you best meet those requirements and – vitally – conclusively and very concisely demonstrate that you do? 

What makes a good CV, anyway?

Picture by @markuswinkler on Unsplash

This is a moving target and standards and norms (and fashions) change. It’s worth seeking out topical advice on the sector you’re applying to in order to make sure what you present is similar to what they expect, and making sure that advice is still relevant – and relevant not only to your targeted industry sector, but the country in which you are planning to work (yes, this changes across sectors and countries!). Most recruitment experts suggest that not only should you tailor your CV (and particularly cover letter) to a position, but that you don’t simply want to list a bunch of skills; you want to list achievements. 

These achievements should be, if you’ll forgive me for slightly overloading the initialism often used for project targets- SMART. Specific, Measurable, Accolade, Relevant, Topical. Achievements in this context are Specific examples which you can (ideally) put a number (Measurement) to; focus on things that have brought you Accolades (or an internal sense of great Achievement) - i.e. their value or importance was recognised by others beyond "meets expectations"; they should be Relevant to the job you hope to have; they should be Topical to the industry and current trends in order to illustrate your work behaviours, continuing education and development, and show your insights into key business realities. You may get some good ideas as you do the STAR exercise discussed later. 

"SMART" achievements might be:

"Reduced costs of wireless LAN by 50% by selecting a different vendor." 

It's specific - what you did and how; 

Measurable - there is a value there;

Accolade: your manager was pleased about it;

Wi-Fi forms part of your job, so it's Relevant;

and well, Wi-Fi is just Topical these days!). 

"Introduced an Ansible-based system of playbooks to move the network access layer to infrastructure-as-code, resulting in vendor neutral new edge switch installs, corrupt configuration restoration and upgrades taking less than 5 minutes, with version controlled configuration."

Again, it's a specific example, with some measurement of the impact (5 mins); you bet you got some accolades around the office for that; it's super-Relevant and extremely Topical. 

Hopefully you see the pattern? 

Change a boring job profile from list of tasks, KPIs, skills (and a possibly rather irrelevant list of every software program you’ve used since you were twelve) into something that demonstrates what and how you did that is worth specifically noting, emphasizing and focusing on those that have at least a modest “wow” factor to them. 

Don’t just state you’re good at something, back it up with some form of evidence. If you say you’re “good at mentoring”, what is evidence of that? Did your team end up all getting promotions from the outcomes of your mentorship, or did 360 degree reviews bring this up as a big plus for you? If you did a major project, what happened to the business as a result? Did you save money in some way? Better meet or smash SLA targets as a result? How much?  You’re a good communicator, eh? Prove it! 

Another question to keep asking yourself is a somewhat cynical “so what!?” – what about this statement makes you great? If I’m hiring a systems administrator, I’d expect them all to be able to do the things listed in the job profile, and I don’t necessarily want a list confirming that hey, you’ve had a similar job profile before (your career history, where you list your positions kind of tells the reviewer that in way fewer characters). Always qualify a statement in some way with some form of evidence. In a CV, you don’t have a lot of space, and you need to really focus in on the best ones. It may be better to have some longer lists of achievements, and select and include the ones you feel best illustrate your suitability to any particular position, staying within acceptable page limits. 

If there are some major “wow” achievements, consider elevating them to a “Key Achievements” section just above the chronological listing section – but don’t repeat them under the position where you achieved them, as you are then wasting valuable space. Some people are a little obsessive over page count limits for CVs; as most of them are parsed electronically first, you probably don't need to worry about page limits as much, but don't go overboard (and respect a limit if it is explicitly mentioned) - and more words means more keywords to stoke the interest of those algorithms!

The more your career achievements follow this sort of pattern, the more impressive they apparently are. In some cases, it can be quite hard to put numbers to things you’ve done, but anywhere you can put some numbers about how you made things better or saved/earned money, do so – but be certain you can justify and defend any figures you give – do NOT make them up, and do not overinflate them. I’ve been given advice to push them as far as you feel comfortable defending (and, presumably, not so far that a referee would laugh or be very surprised when questioned about it - indeed, you should always send your referees your current CV and perhaps even a sample reference letter or suggested talking points). You may be able to put figures in from sources like ticketing (time to resolve without re-opening) or monitoring systems (uptime – but in the Age of Patches, years of uptime is a bad thing – but on time upgrades during maintenance windows are good. It’s unplanned downtime that is bad). It is worth regularly filing away achievements, like a time a customer, peer, co-worker or boss gives you a complement on something you do, and keeping some notes somewhere of major things you’ve done (indeed, a long-form CV may be a good place to keep such things, but make sure you cut it down to the best examples before you send out a CV). 

I find this a particular challenge, perhaps because I don’t think in those terms, or (my wife suggests) my internal standards are such that I don’t view things I’ve done as particularly noteworthy or remarkable. Also I can’t actually quantify the results of many of the changes I’ve made, because all too often some of the changes I’ve introduced are to have any numbers whatsoever, so there’s nothing to compare back to!

You’ve got a few seconds

Even if a company isn’t using one of those systems that attempts to use keyword mining to cut down on the applicant pool to select the most “promising” candidates, you often only have a few seconds to make an impression. I spend notably longer reviewing applications than I’ve seen other colleagues spend – they will often spend less than 30 seconds looking at an application before deciding which pile the applicant belongs in (at most, there are 3 piles “nope”, “shmaybe” and “interview”). So you want to make it really easy for people to find the key things they’re looking for in a candidate. If your application form, CV and cover letter don’t make it into that 3rd pile, you have no hope of landing an interview. Spend the time getting those "good CV" things right! 

“Stan” that organisation

If you’ve not come across “stanning”, it’s a portmanteau of “stalker” and “fan”. Leverage your hopefully considerable information literacy to find out as much as you can about the organisation you’re applying to work at. This can pay off two ways; firstly, you can often throw some bait out in your cover letter, and secondly this is even most useful when you get to the interview stage. 

This is where you can go beyond the job description and person profile and get a broader sense of that organisation and/or department, where it’s been, where it’s going and how you’re most effectively going to contribute to those successes. In many cases, you can glean a lot of information from websites (particularly of public sector organisations) – but careful and judicious googling will often turn up gems such as where their staff have presented the upcoming network expansion plans at a technical conference. Reflect on any of those! If the information is a bit obscure, it shows some really good sleuthing and a very positive amount of interest in the role and organisation you’re applying to. Look at broader patterns, trends, threats and opportunities in that sector, and how IT – and particularly you in that position – might serve to strengthen them. Be sure to bring those insights up in the interview in an appropriate question or discussion topic. 

Use any of those insights wherever you can. Your last chance of course is the “do you have any questions for us” part of the interview. If it hasn’t come up, try and find out a bit more about the role and critical immediate priorities you’ll meet. Ask them about some of the obscure details you uncovered. Discuss how your role might meet the mission and vision of the organisation, or the current challenges and hot topics of that market, industry or profession.

Interview the interviewers

I’ve always been hesitant to ask questions in the “so do you have any questions for us?” stage, but this can be quite useful, and so it pays to prepare some good ones – notably as some people think negatively of people who don’t have questions at that juncture! 

One thing that is annoying about modern recruitment is that you scarcely ever get any feedback, other that “yeah, you got the job” or “sorry, better luck next time” – or, all too frequently – radio silence! A key question you could ask that can help you going forward, notably if you’re not sure it went well or actively feel it wasn’t a success is something like “Is there anything that concerns you about my CV / experience / answers I have given today?” – or, if you feel that is too negative ask if “there is anything on your CV / experience / answers you would like more information about”. Vitally, this may well give you a little insight into where you’re perhaps falling a little short (take it on the chin and seek to improve that for next time!). If you feel the interview has gone particularly well, you may like to ask something more along the lines of “what you expect me to achieve in the first 30 / 90 days on the job” – having them think of you in the role might work in your favour, and also gives you some more to think about in terms of preparing for getting the role – or further experiences you need to seek out, and it may spur some further conversation that may clinch the deal in your favour. 

Many people talk about interviewing being a two way process – and if you have the luxury of choice, do take that time to ensure that you take that last chance to address any insights, questions or misgivings you might have developed about the role or organisation during your “stan” research phase, and find out more about things that matter to you in a position (organisational culture, benefits, training, career prospects, etc). 

In many organisations, there is not just one interview, but a series of them (and sometimes various tests). The further you go down that road, the more invested they are in you as a candidate. After a few interviews, they are normally looking for reasons NOT to hire you! Likewise, those are your last chances to find out about any policy, corporate or team culture or work/life balance issues that may be bad for you before it is “too late”. Make sure you understand what your personal limits and non-negotiables are!

Be a shining STAR

Picture by @denisdegioanni on Unsplash

If you’ve spent any time at all trying to “hack” the recruitment process by learning about how to interview well or successfully apply for jobs, you’ve no doubt come across the STAR technique or something similar. 

In IT, we’re prone to listing skills, software or gear without any sort of measurable qualifiers of just how proficient we might be with them (other than perhaps some industry standard certifications). If you list Cisco ASR9000 on your CV, did you just look at it once or twice in a rack in the datacentre, or did you regularly execute commands on it? (I can confirm they can blow paper an impressive distance across a floor when first turned on, but as it belonged to a REN and not me, I never saw its CLI, although I’ve definitely “remote hands”-d optics into one). I would never list this on my CV, nor bring it up in an interview – but a lot of people (particularly at more junior levels) are prone to listing everything they’ve ever seen. Also, if you last used it 15 years ago or it’s obsolete, you can probably drop it off your CV (and, sure you might have been a wizard at autoexec.bat and config.sys in the 1990s, but they’re irrelevant today)! 

These exercises give you two things – firstly, a list of somewhat quantifiable achievements that you could list in your CV, and secondly, a script for answering a lot of common interview questions. The more prone you think you are to freeze up in an interview, the more you want to prepare, because if the answers are second nature to you, then you’ll typically freak out less and be less likely to “forget your lines” – but seriously, don’t treat this exercise as being an unchangeable script, because you don’t know ahead of time what the other actors are going to throw at you as a prompt. It’s more like high stakes comedy improv than reciting Shakespeare!

STAR should help you form coherent answers to questions that should touch on a few key points that make sure you cover the key points they’re looking for in a format that is easy to follow. The panel need to understand your thought processes, and they like that broken down into a few key (spoken) paragraphs that are nice and easy to follow. 

So what are interview panels looking for here? 

They’re going to be virtually marking you on a few key points. 

Firstly, are you actually capable of communicating with other human beings? You may even like to ask to what audience tech level you should address each of your answers (particularly if the advertisement says they want to you communicate to non-technical audiences)! If the interview is specifically billed as a "technical" interview, go deep, and do not be afraid of jargon or technicalities! Generally, you will find that each panel member asks at least one question – if you know who they are and what their function is, assume they’re asking those specific questions to assess you at their level – so if technical people ask you questions, be technical; if a generic non-technical manager asks you questions, tailor your answers to that interest/expertise level. I have a habit of immediately following this on with “does that answer your question adequately?” – giving them a chance to interrogate me further, or ask for me to expand on something. The length of the interview appointment should also give you an idea of roughly how detailed you can expect to need to be – although you don’t necessarily know how many questions they have up their sleeves. You also want to be very aware of rambling on somewhat aimlessly, and finding a careful balance between giving enough information, and being overly wordy, or disastrously incoherent (eek). You can also obviously ask them how much detail they want where you think you might be about to tie up a lot of time in something they wanted a sentence answer to. In exams, this is easy – you can see the marks allocated the question (or the amount of blank space to fill in) to guide your answer; in interviews, this is trickier, but often, the question itself gives you subtle clues as to how complex an answer they’re asking you to give.

Secondly, they’re going to be assessing how you react to some “curve balls”. Most people think these are silly, but they come up a lot, so be prepared to handle them. The common advice is to simply re-frame them or, if they’re asking you for a negative character trait or incident, spin it to be a good thing. Have an answer for “what is your greatest weakness / mistake?” and so on. My go to, because it is true, is I find it hard to say “no” – but that leads into a quick discussion about time management and learning to set appropriate boundaries – and customer-centric (but appropriate) support. Always have a few stories about disasters, and what you learnt, and why that will not happen again. 

Thirdly, they’ll be looking to see how you “think under pressure” and that you come up with reasonable, considered and cogent answers to their challenges. Just like written exams, some people are good at this, and other people aren’t, but you can (and should) prepare and practice, because you can never demonstrate how well you do in the job until you ace this stage of the game. It is unlikely you will think up every single possible question and practice it – but if you practice a fair few across a broad family of questions, you’ll be reasonably prepared. 

Fourthly, they’re trying to figure out how you think – do you display a high aptitude to solving the kinds of business problems that they encounter, or, more relevantly, expect you to encounter in that role, and how you handle them. They want to make sure you can get the job done, and get it done without causing World War Three to break out between you and Janice in accounting – or causing a lawsuit, and get the work done without being micro-managed or leaning too much on co-workers or managers. Therefore picking (recent) business cases is better that “the time when you did <x> as a camp counsellor many years ago as a teenager” or something from a less relevant previous job or role – make it easy for the panel to visualise you as a professional working in their organisation in the job you’re applying for – and importantly in a tech-focussed role –  that you’re regularly digging your organisation out of tech holes, or displaying mastery of the soft skills needed around high functioning technical departments! 

OK, great, so we now know why STAR is a useful thing. What is STAR again? 

Situation(s)

Task(s)

Action(s)

Result(s)

Firstly, the interview panel need the scene (Situation) set out for them. “Everything was broken”

Secondly, describe your assessing the problem (a skill!) – that’s the Task. “I needed to find out the <root cause>”.

Thirdly, they’re going to want to know your technical Actions (possibly illustrating many skills). “I figured <root cause> out by <….>, and did <x> to sort it out, verifying this was resolved with <y>”. 

Finally, they’re going to want to know what the Results were. (i.e. do you manage to do the job, or prevent things from getting that bad again, etc). “After these actions, things weren’t broken any more, and I took the following steps to avoid <root cause> from happening again”. 

Although most people will advise you to have positive STAR stories, note that result doesn’t always have to be glowingly positive – as long as you demonstrate learning from the experience and your resulting experience went on to save bacon later! You can double the R to add “Reflect” which is where you can either tie the result back to the question, or show that you’ve thought about the repercussions in some depth. Another example is that in some cases, not making a change can be a good thing! 

If you can, try to avoid over-stretching the scenario – if the one you think of isn’t really going to meet the question, don’t use it –  you can look like an absolute prat, or worse, come off as underhanded, deceitful or dishonest. If you literally have never experienced that, say so, but immediately go on to say something like “however, how I think I would react to Situation… is Task…, which leads to Action…, which I expect would Result in…”. You may also come up with an example that isn’t necessarily from your work life – that can be fine, if the question warrants it, or is outstanding enough that it makes sense to answer with that scenario. 

Remember if you had access to sensitive details, you want to be cagey around those – be up front with the panel and say “OK, this is the situation, but because <reasons>  I can’t share all the specifics, however, broadly… <stuff>”. Be particularly cautious about anything that could be considered covered by an NDA, unprofessional to reveal, or deals with privileged personal information about others (the usual protected classes like age, gender, sexual orientation, religion, politics, health). If you’ve got a great example, but it involves one of those, it is by definition NOT a great example – choose something else. In any mid-level to senior role, you are expected to be the very definition of discreet – demonstrate that when you interview by not badmouthing co-workers, companies, vendors, etc – and don’t let privileged information slip. 

I’ll give you a few prompts to start thinking about this (mainly from a networking role perspective), but you should develop your own, and particularly, figure out how to “spot” likely questions from a specific job profile, and developing good STAR answers to them. You can find many lists like this online (go find some) – writing down answers to them is good practice. Better still, practice talking your way through it, and not by mumbling it at your desk - deliver those lines, superstar! Remember STAR makes an excellent framework to all sorts of behavioural interview questions, not just technical ones. Use them to frame inter-personal relationship questions from the HR panel member too (Situation: difficult team member, or boss; Task: getting the job done; Actions: what you did and why you did it that way; Result: you got the job done, and learnt <X>, and achieved <Y>)! If you want to take this to the next level, and you know that the things they are going to want you to handle as soon as you start (from your “stan” search) are things you’ve got good examples of, emphasize those!

Some examples of questions to prepare for

Here are some fairly typical examples of questions you might get asked (prefix them with “tell us about …” or “describe”… as appropriate). Obviously, tune your list for the roles you're interested in!

• A time when you used your advanced troubleshooting skills on a network problem
• A time when you used your design skills on a network
• A time when you had to prioritize / time management
• A time when you used information literacy
• A particularly strange network / IT problem
• A disaster
• A problem you’re proud of solving
• A network design you’re proud of
• A security issue you found and fixed
• An innovative solution to a problem
• Dealing with organisational silos
• A policy issue you found and fixed (not like group policy – a written policy like an AUP)
• A situation where you couldn’t figure the problem out
• Providing exceptional customer service – i.e. over and above expectations
• How you work in a team
• Your management / supervision / coaching style
• A failing project and what you did to turn it around
• A difficult situation (generic, but it comes up a lot – have both inter-personal and tech answers to this one)
• How you handle conflict (have team, manager, vendor and customer examples)
• How do you keep up to date, as technology changes so fast
• Any other noteworthy achievements? (Make sure you have something to slot into questions like this, and another favourite “What did you not have room on your CV/cover letter you wish the panel knew about?”)
• Be prepared to field questions about diversity and inclusion, particularly in markets, countries or organisations where these are important values. 

Those are just a few to get you started on developing your own set of precompiled answers to what, on the spot having never thought about it, can be quite horrible questions! Another way is to turn each key or desired feature/attribute/skill on a job profile/description into a question and answer each this way. That reminds me, I need to go work on my answers to these… 

Another angle is your library of “dragon slaying stories”. Every technical person has a library of experiences from the technical adventures of their lives in the trenches. Get a bunch of techs together, and sooner or later, people will be talking about these stories – most techs LOVE to hear them, and many equally love to tell them. 

I'll emphasise this again - the only thing you must be careful about is being insulting about people or organisations (or letting slip anything confidential) – that can leave a very negative impression of you as a person. Remember, not everyone on that panel will agree that most (l)users are best hit by a clue by four until they no longer suffer from ID-10-T problems (and some will categorically disagree, not least because of the bad PR of having people BOFH the staff or customers). There is a line you ought not to cross! Remember, IT is ultimately a service function…! Similarly (and to reiterate this point), don’t expose sensitive or delicate information, but don’t be strangely evasive – note that there are limits to how much detail you can go into on a situation “because x” (ethics, NDA, propriety, and so on), and that you may have to not answer if they probe too deeply. This can be an excellent way to demonstrate discretion!

Sit down and figure out one of these stories for each key point in your CV, and for each key point in the job profile or person description. If you’ve had to cut your CV or application down to meet arbitrary page limits, develop them for the points you’ve trimmed, too. Consider adapting those legendary stories into STAR format. Don’t borrow other people’s stories and pass them off as your own in an interview! Similarly, if you’ve listed quantified or qualified “achievements” on your CV, make sure you can back them up and recite/defend them as STAR talking points. Seriously consider writing them out as responses to each point, because it is quite common for you to immediately forget every great story you have under the pressure of a number of pairs of possibly unfriendly-looking eyeballs glaring at you across a room (or videoconference), and practicing concretely like that helps burn them into your brain, and makes recalling them easier (much like note-taking when learning for exams!). 

Get good at doing “STAR” responses to questions, as they’re a useful framework. Obviously, you don’t want to be unnecessarily wordy – if they’re actually looking for a very short answer, give one! Good interviewers should avoid yes or no questions, but you should also usually avoid yes or no answers – give your responses some substance! Be wary of putting your foot in your mouth – some interviewers think it is good to leave an uncomfortable silence hoping the interviewee will fill it with something unfortunately telling. If you can find a willing victim (or torturer?), get them to role-play this with you – ideally by throwing new questions your way, not a list you’re prepared (if you’ve done enough of this, you’ll end up in a position where you’ll rarely have an entirely out of the blue question). Remember you can always do two useful things – pause for a few moments and think before you open you mouth, and ask clarifying questions. STAR gives you the scaffolding to hang a reasonable answer off for behavioural interview questions, no matter what. I find it useful to think of key points, mentally stick out that number of fingers, and tick them off as I explain them to the interview panel so I don’t forget anything key. (Hmm, there are 5 things about that I need to do, they are…). You can easily claim 3-5 seconds of thinking time without it being too awkward. Sometimes you will be given a question you can’t immediately think of a real world example of, or even haven’t actually come across – here, still use STAR to describe the hypothetical situation, what you’re going to do about it, and what are the likely or possible results, complications, resolutions, etc. That can really highlight your thinking processes (in a good or bad way – make sure it’s the former). 

It is also worth using the considerable effort you probably put into this to further good use by using those same examples to flesh out the achievements listed in your CV – if you haven’t already done so – focussing particularly on the Results of your Actions.  I’ve found this the most challenging part of doing what is apparently a better CV - answering the “so what?” when you list an achievement! Also, a lot of what I think are important things to have on a CV aren’t achievements, so you have to work to turn the raw ore of a list of skills into a refined and polished crown, diademed with specific and measurable achievements. 

What’s “good enough” to apply?

Picture by @helloimnik on Unsplash

I’ve had conflicting advice from various people about this. 

A recruitment consultant has said (I paraphrase, of course): “if you don’t meet every single one of the essentials and probably all of the desirables, don’t bother applying, because they will get candidates who meet them all, and dump your underqualified CV in the bin”. 

When asked a similar question, someone in the industry laughed and said “Heh, they’re a wishlist – if you meet most of the major points, apply”.

I’ve seen that it can be quite hard to find candidates that even meet the most basic requirements sometimes (specialised skills in an area that lacks qualified candidates). 

 Exactly where on that continuum the truth lies probably depends on the market you’re in and the job role you’re applying for. If you have scarce skills in that market, and they’ve asked for scarce skills across a lot of areas of expertise, even if you don’t meet all the “core” requirements, you might still be the best candidate they see. If, however you see that 1,237 other people have applied to the position, it’s more likely they’ll get exactly what they’re wishing for, and your “taking a chance” CV will not get far.

From a “sound investment of your own time” point of view, you’re better off selecting jobs you’re a better match to, particularly if you take time to craft your applications to specific openings! 

Prepare for some tech questions

Picture by @scienceinhd on Unsplash

In going for IT positions, you can expect the odd technical question (Surprised? Thought not!). Make sure you can answer any reasonable question that is likely to come up from reading about what the job will entail (notably if it is listed in the description). Have a plan for how to deal with curve-balls; use them to illustrate you problem-solving and information literacy, if nothing else. Spend a few days reviewing key technologies they’re asking for; the details you don’t regularly use often get rusty. You should be aware that some interviewers like to see how in depth you go – sometimes way further than they’d expect you to be in that position, which can leave you feeling like you failed that part of the interview, even if you actually nailed it. 

That said, the degree of depth that is reasonable to expect in a helpdesk technician is rather different from a senior engineer/architect position, so if you need to, hit the books to refresh your memory. If you’re going to be expected to work with a vendor, product or protocol you’re not that familiar with (assuming you then get to the interview stage…) come armed with some thoughts on how you’re going to adapt to it, and demonstrate existing progress to meeting their needs. 

It should be pretty easy to realise how to prepare for this - go look at the job description or any other information you have gathered about the role and think how someone might try to ascertain that you'll be able to do the job - what questions could you ask to see if the person lived up to the CV or a former job title - and particularly, can deliver on the one being applied for? If specific technologies or vendors are listed, spend some time refreshing your memory. You can even google things like "technical interview questions <role>" if you're stuck for inspiration.

Not all tech questions should be answered with STAR – a straight “factual” question is not a STAR question – “describe the best path selection algorithm in Juniper’s implementation of BGP” does not warrant setting out an answer in the same way as “describe a weird routing issue you’ve seen” – make sure that you hit the key facts you’re expected to know, and perhaps highlight some interesting interactions or gotchas to show you’ve really “got it” on an operational level. How RPKI origin validation changes BGP bestpath is an interesting, topical example, as we think about BGP! 

Think about how to handle questions where you don't know the answer. Saying you don't know, but know how to find out (and demonstrating that) is quite valuable in employees, particularly when you get to upper levels of IT, where you are where the problem will sit until you resolve it. Again, sometimes, this is put in there to find out where you limits are, it is not necessarily a "game over" situation (unless of course you literally can't answer it, and being able to answer that is a requirement of the position; learn, address the knowledge gap, move on and nail the next interview). Treat this like any novel problem; explain what you would do if you hit that "on the job"; if you feel it's a deficiency, tell them (truthfully) how you're working on that skill or qualification, or how you plan to do so in the next <period of time>. Questions you can't answer (or feel your knowledge was inadequate) are always things you should immediately note after the interview and go and research. 

Consider using illustrations if they help – if you’re discussing a complex software architecture or network, draw a diagram, and illustrate it as you talk through it; don’t be afraid to refine and annotate this as you go along – in fact, do this wherever possible (practice doing so if you don’t regularly diagram things). Annotating diagrams is helpful to all involved. Indeed, if you can “spot” a question that lends itself to this treatment, prepare it so you look like a real pro when you effortlessly sketch it out on a piece of paper or a whiteboard and it isn’t immediately a huge mess – but don’t turn to one in a notebook you happen to have brought with you. A simple example is to be able to diagram the network of the last place you worked, or sketch out a workable system architecture for an organisation or ICT system based on a few key requirements, and be able to discuss and defend a particular design. Of course, if drawing a picture won’t help understanding, don’t spend time on it, either! If you think you’re going to do something “left field” in an interview, you can always say “To answer this question, I’d like to…. Is it OK if I do that?”. 

Are there any #lifehacks to get ahead of the curve? 

Maybe. Firstly, make sure you absolutely nail your initial application or other early approaches. Check if that company or industry “vertical” or job role typically has any strange standards and norms and that you live up to them. Get the basics right first!

Some people say that the “unadvertised job market” is considerably larger than the advertised job market. I find this hard to believe, but it is plausible, particularly for more senior roles, that word of mouth and careful networking can get you ahead. I’m not certain how effective reaching out to random executives or managers (even with very nice stationery and a first class stamp) might be – but it’s a thing you could consider. If this interests you, research this approach (and no, this is not about randomly mailing out your CV!). 

You may be able to jump the queue a little, particularly if the advertisement says to contact someone to find out more about the position. You don’t want to hard sell here, but you do want to ask carefully considered questions that show your interest in the role, and perhaps nudge the person on the other end of the line into thinking about your suitability for the role. Obviously, this is your call (literally and figuratively). Then, make sure your CV crosses their desk, and they might just remember you from the phone call!

Maybe you need professional help

Picture by @sctgrhm on Unsplash

Job hunting is a weird game. Think for a minute about what you typically do when you encounter a new field that is full of unknown skills, pitfalls and rules you're not sure about. You, as a technically minded person with a moderately healthy professional income, will generally go one of two ways. 

The first is to set out to master the topic on your own. This can take a long time.

The second is to pay someone who has already developed mastery to help you out, which can really short-cut you to the "getting results" stage. 

The first pays off for things you're going to use frequently, or perhaps for which mastery is its own personal reward (things you need to do and things you like to do). 

The latter is better for "once off" or particularly "hard" skills or practices you don't have a good handle on - or perhaps don't even "get" - things you have to do, but only very rarely (or, of course, areas you might not legally be able to do things in).

There are lots of people who will help you with various forms of career coaching, from basic CV drafting through to an in-depth career coaching service that may even go as far as considering large career changes and how to get there. Take a little time to think whether you feel confident in your job search, CV/résumé and interviewing skills, and if you might need some help developing those beyond reading a few articles on the internet and setting some time aside to think and act on those insights. 

Only you know what you need, but if you're finding it hard to get any interviews, and/or all your interviews go poorly, your game is probably not "on point" and you could possibly use some assistance. Consider money spent here to be an investment in yourself of a sort (much like any training or certifications you self-fund). If you're not getting interviews, you go through the process and get interviews, you're already seeing "ROI". 

Another way to think about it is how long it might take you to independently master the career game - and whether that time would be better put to some other use (like learning every day job-relevant skills). There is a cost/benefit curve here, of course, but on the whole, for something like this, I'd argue getting someone else to help you out, particularly if you're not confident in your job prospects, has enormous value. 

It can also be really helpful to have a "cheerleader" in your corner to reflect on the process and give you critique, encouragement and advice - and a sense of accountability for your job search process - and sometimes, even a network of people to plug into. 

If you feel this is something you might benefit from, have a look around and find someone who you can work with. I spent a fair chunk of change on a service like this, and I think I've derived considerable value from it. 

What’s the tl;dr of recruitment, anyway? 

At the end of the day, recruitment (from the recruiting organisation’s side) is a game that seeks to try to answer two major questions. 

Firstly, can this candidate do the job? 

Secondly, in doing the job, are they going to fit in (to the team and/or company culture) without causing us unwarranted (management) dramas? 

The person the interviewer(s) feel best answers those two overarching questions will be the “best” candidate, and the only one they’d offer the position to. 

To some degree, it is a pretty silly game – it’s very hard to conclusively answer either of those two key questions from a few bits of paper and what is generally a fairly short conversation, but there are lots of people that think they’re able to do that (conversely, there are those that spend several days getting to know candidates, but that is vastly more expensive to the company – and your time, too). To a huge degree, of course, that means people that have “hacked” (or simply naturally “get”) interpersonal relationships will tend to do better in interviews (and those that are naturally pre-disposed to being their own best salespersons and shouting their greatness from the rooftops do better than those who sit quietly in the background fretting under the grip their “impostor’s syndrome” – I naturally trend towards the latter end of that particular continuum, unfortunately). 

Each organisation (and even each team within an organisation) has a culture. Some will value the pure technical might of a candidate. Some will value the “soft skills”; most will value both. Work hardest on the thing you’re weakest on, multiplied by how important that skill looks to be in the marketplace.

This is also a reason why having more people meeting a candidate can be a good thing for the organisation – people have different skills in relating to other people, so the most technical person might be really good at figuring out the first question (can they do the job?), but might also be someone who would never pick up on the “creepy vibes” they hypothetically give to another co-worker, which could negate the interviewee meeting the second important question (do they fit in?) completely, and make them an entirely unsuitable candidate. You will therefore typically find that you will be interviewed by a panel, but all reasonable employers will let you know what the recruitment process looks like, and should tell you who the interviewers on your panel will be (or at least how many will be on it) and if there are additional phases or stages to the organisation. 

Don’t just take my word for it though – go and do some of your own research and reading!

See also: https://schoolsysadmin.blogspot.com/2020/02/funemployment.html