Tips for an interview (both sides)

In my last job, I did some interviews (technical/skills part). Adding to that that working in consulting and having changed four times of job I've done a significant number of interviews, I am not an expert, but I can give a few advices to both sides in order to achieve the best results (get hired, or hire the correct person).

Candidates

  • Do not lie. The first and most important advice. Except if you're opting for a big company in which you can "stealth" between the masses, "what you sell is what will be expected from you". You souldn't say "I'm an expert in AJAX" and then spend a week for your first asynchronous call in ASP.NET.
    Your real skill levels might be tested or might be not, but if they are the negative impact will be way bigger than if you just said "I've played with AJAX but I'm not yet confort with it".
  • Don't cheat on your past job positions. It is very very rare to end being a project manager with just one or two years of experience. It is unusual to ask for references to past companies, but a "sudden position increase" from developer to project manager in just two years of working smells like cheating.
  • Big CVs are a burden. When I had to read a 7 pages CV, I skip directly to direct work and skills, and if those sections were long too, sometimes I just looked at time worked + technology used.
    You should keep either a "clean CV" (might be 8 pages, but if each page is a separate section is ok) or a small one (4-5 pages max, with more bulleted lists than text paragraphs).
  • Dead or old technologies are not important. If you coded in C++ eight years ago and since then you haven't touched it, either leave the language for your job position where you used it, or completely remove it. Think that if you say you know C++ and then someone asks you for a small pointer exercise and you fail, it's a bit embarrasing.
  • Avoid large chunks of text in the CV. As mentioned before, a simple list or two-column table is faster and easier to read.
  • Avoid misspellings. Check and recheck the CV...
  • Try not to be aggresive or too shy. For a technical position, it is good to have initiative, but I once did an interview of which I got out scared of the person because was way too agressive speaking.
    Also, be polite! using bad language will almost surely substract points.
  • Don't be afraid to speak of related hobbies or personal projects. At my last job we took note of things like having a personal web or blog, reading technical RSS (not everybody yet knows what are RSS!) or purchasing technical books at Amazon or similar.
  • Expect to do small exercises or technical tests. If you're opting for a mid or high technical position, it is perfectly reasonable to be asked to perform small tests, code evaluation, or questions related to your skills.
    If you've been working for 4 years with ASP.NET, you might not have had the opportunity to create an HttpHandler, but you should know PERFECTLY what a Postback is (and if you can explain the difference between an HttpModule and HttpHandler, you will give a good impression ;)
  • Multiple interviews are good: If you're requested to perform multiple interviews (3,4 or even 5), don't panic. It is a good sign, at least the company takes the interview seriously.
  • Some additional points from one of the biggest technological companies in spain, Tuenti.

Interviewer

  • Avoid stupid questions. Like "why we should hire you instead of the other candidates" or "describe yourself with four adjectives". They don't know other candidates, or your company, and people usually answers with a typical, polite answer like "because I'm very professional" or "because I adapt quite well to changes".
  • Take a test as it is, a test. Exercises and tests are good, but you should take into account factors as nervousness, pression or shyness.
  • Analyse how the candidate resolves the tests. Sometimes it is more important "the how" than the solution itself. A non-recursive approach to a "do a factorial sum function" test works, but is not so good as a recursive one (that implies the candidate knows at least a bit of recursion).
  • Be clear about what you are asking for. A lot of times people get nervous and don't know exactly what are you asking them. If you want them to describe what are DataSets and DataReaders, instead of asking "do you know what are DataSets and DataReaders" ask "Can you briefly describe me what DataSets and DataReaders are and why both of them exist?".
  • Do not panic your candidates. If you are a small company and the candidate may have to do tasks not closely related to their skills, tell them so. But do not start saying "you will have to work very hard" or "you may have to do overwork from time to time" or you will scare them.
  • Do not request for a hundred skills. It is better to put a job offering for "a .NET analyst-programmer with extensive knowledge in .NET and web services" than a big list of .NET technologies. The result is the same but people tend to get overwhelmed if they see a huge list of requirements.
  • Do not try to get a 2x1. A graphic designer with knowledge of ASP.NET is an added value, but shouldn't be a requisite. If your candidate knows how to manage IIS or SQL Server configuration he will probably do those tasks without problems, but if not you could be discarding a good developer anyway.
  • We're here for the money. At least in Spain, this happens a lot in some areas like game development. Poor salary but "hey, you will work developing videogames!" (as if that were the same that playing them ;)
    Some companies take this approach to avoid salary risings, they just have a big pool of cheap junior developers and keep adding more to catch up with the high rotation/quitting, but at the end the reputation of the company gets affected.
    Try to offer a fair salary and people will always be happier.
  • Try to learn the questions and answers you're going to ask. At least for me, it gives a very bad impression to see an interviewer just reading a list of questions and annotating my answers.
    I'm a bit too talkative, but when I did interviews I explained the incorrect answers to the candidates, or asked them why the answered something.
  • It's in the details. A candidate that spends a minimum amount of money yearly on technical books, or that has studied a certification by it's own (not paid by a previous company) usually denotes interest to learn and keep up. Ask questions like that to try to gather non-basic info of them.
  • Research the interesting candidates. If they have a blog or website, surf it and look at what they write about. If they have given speeches or participated in events, try to get the materials or recordings to see what they were about. Passionate people are great options.
  • Feedback is important. Always remember you are interviewing people, not robots. People with expectations, desires (hopefully to work with you ;), etcetera. If, for any reason (doesn't has to be just the "we don't want him" typical one) the process is going to be on hold, cancelled or postponed, give feedback to those candidates you told they would be contacted/emailed in few days.
    Not giving any feedback can have both impact on your image ("they don't care too much") and on the job offer itself (candidates might go anywhere else, thinking they have been discarded).

Well, I am probably leaving a lot of tips off, but this are all I can think about right now.

Above all, try to be sincere (both parts) and things will go well; And if they don't, it was not your destiny :)

Tips for an interview (both sides) published @ . Author: