In an attempt to solve the problems described in Part 1, some companies came up with a different approach: the technical challenge - aka the homework.
A few examples from the security research and software engineering areas include:
- Solving various cracking exercises.
- Do a mock vulnerability assessment on a real target under the employer’s control.
- Pentest a vulnerable virtual environment.
- Analyse a piece of malware and provide a report.
- Do a small project from design stages till the end.
While the benefits of these approaches over the tactics in the previous post are clear, there are, however, a few pitfalls. I’m not saying they are not good or useful. Just the way we approach them is very important, from both sides of the fence.
From a candidate’s perspective:
- Establish a clear timeframe
- You need to make sure that there is a clear ending to the challenge (see rule no 4). Find out roughly how much time you should allocate for it and possibly how long it took other candidates to complete it. Otherwise you might end up wasting your time.
- Discuss the terms from square one
- Before doing actual work on any challenge or project, make sure you really want to work for that company. Have a discussion beforehand to understand the position you’re applying for and the relevance of the challenge.
- What is the purpose of the challenge? Is it evaluating report writing capabilities, logical thinking, technical investigation skills? Find out as much as you can in advance.
- Stay focused on the situation
- Be aware of any influence principles at work. Some employers/recruiters will try to exploit their authority position. Using phrases like “Are you up for…“,” “Now is your time to ..”, “Use everything you know to …“, “Feel free to impress us with …” can get candidates committed to solve the problem at hand.
- However, this will escalate quickly when you don’t have a clear purpose.
- Clear purpose
- Approach the interview challenge with a clear purpose. Your time is limited. Your goal could be “Do everything I can in 5 hours” or “Exploit the FTP server and get root” or even “Write a good report and highlight all the vulnerabilities found and mitigations” (if that’s your speciality).
- Because this is not possible with all challenges, you need to know where to stop! It’s perfectly reasonable to think of a list of future task you would do next and include it in the report.
- Errors
- An interview challenge can be clear and well written or it can fall short of expectations (to put it mildly) in this area. Whatever the case may be, this tells something about the person who wrote it.
- The first type of errors are grammar errors. Not the end of the world but still.
- Secondly and more important, if you find technical errors, or errors within the context, things that don’t add up, this should be a good thing to flag this with your interviewer.
- If somebody cannot invest time in doing a proper review of the exercises before releasing them, it seems legitimate to ask, why would you?
Bottom line is, from a candidate’s perspective, it all boils down to a few simple things:
- Think about what you want to achieve
- Be thoughtful and show consideration for the other side
- Be reasonable and don’t jump to any conclusion too soon
For the interviewer’s perspective, the goal is simple. You want to find people wired for security research or engineering logic. If you’re using the above homework approach, here are a few tips:
- Invest time to create a challenge that generates flow
- Fortunately in the Infosec area this is easily achievable. A state of flow is achieved when the skills are balanced by the perceived challenge.
- Although this is different from individual to individual, you should strive to create interesting challenges, with progressive levels of difficulty, clear objectives and a feedback mechanism.
- Put yourself in the candidate’s shoes
- This one is kind of obvious but often forgotten. It is also easier said than done most of the times.
- So as a candidate, would you spend you whole weekend attacking a problem which would turn up to be wrong? Probably not. See rule #3.
- Make sure all the details are right
- Verify the challenge is technically sound, solvable and without any errors (grammar or any other types).
Good luck!
