Competency Based Questioning - part 1
03:30 Monday, 19 July 2021
UK Cyber Security Council
Graduate careers specialist Prospects describes the Competency Based Questioning (CBQ) interview process thus: “Competency-based interviews (also known as structured, behavioural or situational interviews) are designed to test one or more skills or competencies. The interviewer has a list of set questions, each focusing on a specific skill, and your answers will be compared against pre-determined criteria and marked accordingly”. They go on to point out that the approach works on “the principle that past behaviour is the best indicator of future performance”.
To be on the receiving end of a CBQ interview can be a daunting experience, particularly early on in one’s career because it relies heavily on the candidate being able to draw on real life experiences – which of course are few and far between when your career is in its infancy. This is the first of an occasional series of blog articles providing advice and examples of how to deal with CBQ; in this article we shall look at the key principles to follow when answering CBQ questions.
Although you will generally not be given the questions in advance of your interview, the pool from which questions are drawn tends to be shallow. There are many, many web pages dedicated to helping you predict what you might be asked and to give examples of the answers you could give, and there is a lot of commonality between the areas of competency they discuss. For example, in a search on five such sites1,2,3,4,5, all five included teamwork, decision-making, leadership and communication as likely areas for CBQ; four of the five listed problem solving and organisation. So even if you consider these seven subject areas and think of one or two examples in each, you will have a head start over those who have not taken the time to prepare examples.
Don’t be frightened to pause for thought
Sometimes the answer to a question will leap straight to mind – particularly if it is a question for which you have already planned an answer. If not, then pausing to think of an example is perfectly fine. By all means say: “Hmmm, that’s an interesting question … let me think for a moment” rather than just leaving an awkward silence, but don’t rush into an answer without giving it at least some thought.
Try to find a real relationship between your experience and cyber security
If you are a non-cyber person interviewing for a cyber job – as is common today, given the massive cyber skills gap from which the UK is suffering, try (if you can) to pick examples that have reasonably clear relevance to the field of cyber security. You can, of course, consider this in the pre-planning stage discussed earlier and select the example that has the clearest connection.
Structure your answer, if you can
There’s a common technique called STAR – Situation, Task, Action, Result. It’s a useful way to structure an answer, because you begin by telling the interviewer the situation you were in (the type of company and your role therein), then the task you were expected to carry out, then a high-level review of the actions you took, and finally a description of the outcome along with one or two highlights or lowlights. If you are relatively inexperienced, a good interviewer will usually not worry if your answer isn’t brilliantly structured, but if you are more experienced and/or the role is a fairly senior one, it would be a good idea to practise beforehand.
Bad isn’t necessarily bad
This latter point is important: everyone knows that things sometimes don’t go as hoped, and the interviewer is interested not just in how great the successful elements were, but also how you dealt with the parts of the task that didn’t go as well as hoped. In cyber security, things sometimes go badly – but the interviewer is interested less in what went wrong and how you dealt with it.
Telling the story of a bad security experience runs the risk of breaching one’s confidentiality agreement with the company in question; such agreements rightly remain in force after you and the employer part company, so be careful not to make it obvious which organisation you are referring to. It is perfectly acceptable to say to the interviewer: “I can think of an example but I need to be cautious not to identify the company, but here’s a high-level view of what I did”.
Me, not just us
Finally, remember that you, not your team, are the interviewee. As noted earlier, you are almost certain to be asked at least one question about teamwork – which is fair enough as you will almost certainly be working in or managing a team if you get the job – but do not be afraid to use the word “I” from time to time. If an interviewer hears answer after answer of the form: “We migrated the company’s cloud-based systems from Azure to AWS”, “We introduced a new DevSecOps regime” and “We implemented a new anti-malware estate”, it tells the interviewer nothing about the magnitude (or lack thereof) of the part you played in the example.