This month’s post is part of the T-SQL Tuesday #tsql2sday SQL Server community blogging effort, on the subject of interview ‘patterns’ and the opposite ‘anti-patterns’ for candidates for a SQL job posting , and is kindly hosted this month by Kendra Little here:
Rules and Rituals
Although I considered listing the interviews I had bombed this would make for a very long post. Before choosing to read for my PhD in Cybersecurity Management at Coventry University , I did more than my fair share of interviews on both sides of the recruitment fence, with varying degrees of success. So here’s the magic rule:
The magic rule is that there is no magic rule (within the legal boundaries of what can be asked at interview). At least, there are no hard and fast rules.
As developers or DBA’s it would help if there was a Books Online entry for this, or some kind of app that would tell you the parameters for a successful outcome, or indeed what a successful outcome would look like. Calling this article Patterns and Anti-patterns suggests a binary state of affairs that doesn’t apply to the world of interviews, business, or human behaviour.
Think of interviews as being a ritual. Humans like to participate in structured exchanges when engaging in matters of importance, and an interview is one such example of behaviour in action. What matters most is that a rapport is built up between yourself and the employer, a bond of trust that can be relied upon to reduce the risk inherent in developing and managing complex data and information flows.
Although we cannot see the future and know for sure if things are going to work as predicted, the relationship between the employer and employee (or client and consultant) is based on reliance on another party, and trust formation is used as a selection process so that each party can weigh up the potential benefits of collaboration. If you think that this sounds a bit idealistic, think about the time and money that is invested every year in searching for and interviewing candidates, businesses would not invest that kind of effort without reason.
Possibility Not Probability
As they display non-linear properties interviews are best handled by taking a fuzzy logic approach by using the ‘possibilistic logic’ of people, and not the ‘probabilistic logic’ of databases. Achieve success by statistically loading the interview in your favour. Although you should answer tech questions with tech answers, the interview relationship will be won by ticking the behavioural boxes that will enhance your edge over the other candidates when combined with your SQL knowledge.
Here’s a list to think through:
- Be honest. Honesty, openness, and transparency are valued by others, and if you don’t know answers, even vaguely, don’t try to cover it up. Best to give pointers to other resources or approaches that drill into details.
- Be creative. Show initiative when thinking of examples of your problem solving skills. Show that you are able to seek information from many different sources and viewpoints and synthesise these to make creative solutions. When logical avenues escape you, know how to feel the force and think of alternative non-technical workarounds.
- Work in Progress. We are all learning and adapting every day. Signal that, although your knowledge of your subject is comprehensive, there are always areas where you are seeking to improve and keep up to date. This shows you are adaptive, resilient and receptive to change.
- Know when to call a halt. I personally can clear an interview room (or bar) by talking SQL Server for hours on end. Most interviewers can’t, so know when to shut up before they get restless. Sometimes less is more.
- Manner. Although many recruiters emphasise the importance of making eye contact, this can present difficulties for technicians who are very strong technically but have gifts like Aspergers’ – not that uncommon in IT circles. If you find it difficult to engage eye to eye, aim for sincerity and authenticity by showing enthusiasm, willingness to learn and an affinity with the work.
- Reliability. Organisations need to know they can rely on the people they employ, and this can be shown by trying to get there on time, or by calling ahead if you are not able to. Small considerations like this disclose your reliability and thought for others.
- Team vs Individual. Don’t feel that the recruiter is just picking your brains for their SQL content, they may have to work with you every day. As such, knowledge sharing and communication is essential for maintaining working relationships. Some consultants aim to keep their clients captive by using their SQL knowledge as a dark art to crank up the day rate, but actually giving themselves a poor reputation and making their clients resentful. Make yourself more brilliant by taking responsibility but sharing the know-how, it will multiply your influence and probably your day rate.
- Shared Values. Although you possibly should have considered it earlier in the application ensure that your values are consistent with those of the interviewing company. If you are a pacifist and end up working on stealth bomber technology then it is possible this posting will conflict with your internal values. Have the confidence to wait for opportunities that are consistent with your beliefs.
- Economic Choices. Try to demonstrate by using examples that employing/ engaging you is the smartest move the organisation will make this week. Leave the impression that being associated with you will make the numbers stack up for the employing organisation.
The outcome of the process should be that the organisation has confidence in you. Your confidence in your skills and ability is the key to getting that engagement, by not only showing technical competence but by assuring the other person that you are motivated to give your best in all circumstances.
One other tip – Never accept the offer of a cup of coffee at interview. I did this once and ended up spilling it all over myself, my interviewer and his desk and paperwork. I didn’t get that job.
– Now go get that job!