Doing your Developer interview well
An interview has many of the same intentions as the CV does in the first instance. Your employer usually doesn't know you and uses an interview as part of the decision making process. If you don't convey something well in the interview, the employer won't know.
Let me say that again because some people don't understand it. If you don't convey something well in the interview, the employer won't know.
Why? Because they don't know you. The number of times I have read a forum post where someone is complaining about not making the cut even though are "experienced", "very good at coding", "a great employee" etc. It doesn't matter if you can't communicate it.
There are two areas that are important in the interview: The objective and the subjective. You cannot control both and that is OK. Maybe you are not a good fit for the company. Maybe you are a good developer and the interview recognises that you would make the rest of the team look bad.
The best you can hope for, therefore, is to accurately convey who you are and let the employer decide if you are right for the job. Just like in relationships, you might really want to work for this company and they might not want you. Accept it and move on.
For that reason, your demeanour and confidence is critical and if you struggle with this, get some coaching!
Hopefully, I don't need to say that turning up on time and wearing appropriate clothes is important (ask before the interview what to wear) and don't be upset if you turn up late and get told to leave even when it wasn't my fault. The employer will simply assume wrongly or rightly that you are not organised or that you don't care enough about the role. If you are commuting and the trains are e.g. once per hour, ask BEFORE the interview if they are happy that you might be a few minutes late if the train is late. Better yet, turn up an hour early, find a coffee shop and make sure you are there on time. You should not be applying for lots of jobs, that shows that you don't really care about the role you get so this shouldn't be too hard.
Engineers are sometimes a shy and awkward lot but although employers will understand this, it doesn't mean that you will look very good if you cannot make eye contact, if you cannot answer questions confidently (more later) and if you don't seem like you know what you want. You might be nervous for a psychological reason so if so, get counselling. You are you and if you cannot convey yourself properly, you are really hurting your chances of success. "What if I am not good enough"? Then you are not good enough, you need to do some more training or get more experience.
Things that employers don't like: People who really overstate their skill. I had one guy told me he was an "expert" on HTML so I challenged that. What does he know as an expert that I don't know (I am not an expert). He couldn't think of anything in particular. There are, of course ways in which you can be an expert, he was just not one so immediately he creates a trust issue.
Things that employers don't like: People who don't seem to know themselves. A question like, "how proficient are you with microservice", should be an easy question to answer. "I have created some basic ones but don't know a lot about Kubernetes", "I have created several services that are used in production and did some interesting configuration with Jobs", "I am part of the Kubernetes public forum and frequently answer people's questions". Some people find questions hard like they haven't even thought about it.
At the end of the day, a lot of this section is just a feel. There are things that most employers will like: amiable, not cocky, not too brash, looks like they play well with others; and there are things that won't come across well: passive aggressiveness, awkwardness; indecisiveness; aloofness. You can work on some of these but, again, get some help! It is not weird to get counselling if you find yourself super anxious in a professional or group situation but it can often be traced to something that can be worked through and overcome.
An interview is a big deal for most people. It is either a promotion, a necessary evil for a house move or perhaps a life line after being made redundant so why don't people prepare more? Again, you should not be applying for lots of jobs, you should carefully think about your strengths, what you want to do and what works practically (a 2 hour commute anyone?) and then spend some real time investigating what the company does (as always, ASK if you can't find what you need) and be prepared in the interview.
At SmartSurvey, we are an online SaaS business so as a Developer, you should know what types of questions about experience/skills we are likely to ask in an interview (and you'd be right!):
Now something related to CVs that annoys me intensely, as someone who wants you all to sell yourselves well, is when someone just says things like "skills used: SQL Server, .Net MVC, Entity Framework". Guess what? Everyone in the .Net world pretty much uses those every day and it doesn't say anything about your skill or experience.
Things a 15 year old could do:
Things that you should be able to do after working in the industry for 10 years
Example question: Can you describe your level of expertise with SQL Server and an example of something you have done that demonstrates this?
Bad answer: I've used SQL pretty much for 10 years with most of the projects I have done so I really know it and am comfortable with it. I have created tables and added columns and stuff.
Good answer: I can do all the basics such as creating and updating tables and I understand about data integrity during schema modifications. I have also worked with migration of data, backups and bulk import of data from file. The hardest thing I have done is probably when I had to design a completely reliable way of performing a table maintenance on a production database to reduce its size down from 600GB to around 400GB. I had to identify large indexes, work out which could be dropped, removed a lot of unused columns in certain problem tables and then had to do extensive testing and work out how to rollback at any point if we had a problem. All of this had to be completed in a short maintenance window and we managed it in 3 hours.
The difference between the two (apart from the obvious): preparation.
Don't tell the interviewer, "I can learn that", to make up for not knowing very much. We can all learn it! We are looking for people who already know stuff, the fact that you might have to learn things is a given but the difference between someone who has already done something (and learned all those weird edge cases) and those who have to learn all those can be 10x or more.
Oh, and Preparation
Let me say that again because some people don't understand it. If you don't convey something well in the interview, the employer won't know.
Why? Because they don't know you. The number of times I have read a forum post where someone is complaining about not making the cut even though are "experienced", "very good at coding", "a great employee" etc. It doesn't matter if you can't communicate it.
There are two areas that are important in the interview: The objective and the subjective. You cannot control both and that is OK. Maybe you are not a good fit for the company. Maybe you are a good developer and the interview recognises that you would make the rest of the team look bad.
The best you can hope for, therefore, is to accurately convey who you are and let the employer decide if you are right for the job. Just like in relationships, you might really want to work for this company and they might not want you. Accept it and move on.
The Subjective Stuff
Let's be honest, in the duration of most interviews (1 hour) you have very little time to really understand somebody and the employer cannot realistically give you a great deal of their time unless they are really sure you are close to what they want.For that reason, your demeanour and confidence is critical and if you struggle with this, get some coaching!
Hopefully, I don't need to say that turning up on time and wearing appropriate clothes is important (ask before the interview what to wear) and don't be upset if you turn up late and get told to leave even when it wasn't my fault. The employer will simply assume wrongly or rightly that you are not organised or that you don't care enough about the role. If you are commuting and the trains are e.g. once per hour, ask BEFORE the interview if they are happy that you might be a few minutes late if the train is late. Better yet, turn up an hour early, find a coffee shop and make sure you are there on time. You should not be applying for lots of jobs, that shows that you don't really care about the role you get so this shouldn't be too hard.
Engineers are sometimes a shy and awkward lot but although employers will understand this, it doesn't mean that you will look very good if you cannot make eye contact, if you cannot answer questions confidently (more later) and if you don't seem like you know what you want. You might be nervous for a psychological reason so if so, get counselling. You are you and if you cannot convey yourself properly, you are really hurting your chances of success. "What if I am not good enough"? Then you are not good enough, you need to do some more training or get more experience.
Things that employers don't like: People who really overstate their skill. I had one guy told me he was an "expert" on HTML so I challenged that. What does he know as an expert that I don't know (I am not an expert). He couldn't think of anything in particular. There are, of course ways in which you can be an expert, he was just not one so immediately he creates a trust issue.
Things that employers don't like: People who don't seem to know themselves. A question like, "how proficient are you with microservice", should be an easy question to answer. "I have created some basic ones but don't know a lot about Kubernetes", "I have created several services that are used in production and did some interesting configuration with Jobs", "I am part of the Kubernetes public forum and frequently answer people's questions". Some people find questions hard like they haven't even thought about it.
At the end of the day, a lot of this section is just a feel. There are things that most employers will like: amiable, not cocky, not too brash, looks like they play well with others; and there are things that won't come across well: passive aggressiveness, awkwardness; indecisiveness; aloofness. You can work on some of these but, again, get some help! It is not weird to get counselling if you find yourself super anxious in a professional or group situation but it can often be traced to something that can be worked through and overcome.
The Objective Stuff
There are various aspects of the interview that are either correct or not. These mainly involve your skills and experience and here, preparation is everything.An interview is a big deal for most people. It is either a promotion, a necessary evil for a house move or perhaps a life line after being made redundant so why don't people prepare more? Again, you should not be applying for lots of jobs, you should carefully think about your strengths, what you want to do and what works practically (a 2 hour commute anyone?) and then spend some real time investigating what the company does (as always, ASK if you can't find what you need) and be prepared in the interview.
At SmartSurvey, we are an online SaaS business so as a Developer, you should know what types of questions about experience/skills we are likely to ask in an interview (and you'd be right!):
- Scalability
- Security
- Databases
- UI/UX
- A hard problem you've solved
- Leadership/management experience/interest
Now something related to CVs that annoys me intensely, as someone who wants you all to sell yourselves well, is when someone just says things like "skills used: SQL Server, .Net MVC, Entity Framework". Guess what? Everyone in the .Net world pretty much uses those every day and it doesn't say anything about your skill or experience.
Things a 15 year old could do:
- Create a database with tables
- Create an ORM mapping for these tables
- Create an MVC app with some admin tables for these objects
Things that you should be able to do after working in the industry for 10 years
- Analyze database queries to identify performance issues
- Understand various types of database scaling
- Understand advanced Linq to SQL queries and have dealt with a number of problems with EF (or NHibernate etc)
- Experience with Authorisation and Authentication on web applications, have written your own middleware(s), ideally some OAuth2/OpenID Connect
- Be an active part of Stack Overflow/Github/Some other tech forums
- Some JS front-end experience
Example question: Can you describe your level of expertise with SQL Server and an example of something you have done that demonstrates this?
Bad answer: I've used SQL pretty much for 10 years with most of the projects I have done so I really know it and am comfortable with it. I have created tables and added columns and stuff.
Good answer: I can do all the basics such as creating and updating tables and I understand about data integrity during schema modifications. I have also worked with migration of data, backups and bulk import of data from file. The hardest thing I have done is probably when I had to design a completely reliable way of performing a table maintenance on a production database to reduce its size down from 600GB to around 400GB. I had to identify large indexes, work out which could be dropped, removed a lot of unused columns in certain problem tables and then had to do extensive testing and work out how to rollback at any point if we had a problem. All of this had to be completed in a short maintenance window and we managed it in 3 hours.
The difference between the two (apart from the obvious): preparation.
Lastly
If you get asked about something you haven't done, say you haven't done it. We don't expect everyone to have done everything. If you've never used microservices, say so. Only add an explanation if it is relevant e.g. I haven't used it but I did do a training course; I have done some side projects to have a play with them etc. Otherwise it sounds defensive. In most cases, having training or a "play" is a tiny advantage over people who haven't since most of the hardest parts of programming are those weird edge cases that you only get when you deal with it in production.Don't tell the interviewer, "I can learn that", to make up for not knowing very much. We can all learn it! We are looking for people who already know stuff, the fact that you might have to learn things is a given but the difference between someone who has already done something (and learned all those weird edge cases) and those who have to learn all those can be 10x or more.
Oh, and Preparation