02 November 2018
I don’t mean preparing code-wise, I mean prepare by learning anything and everything you can about the company. I have literally seen a candidate get turned down because they, “didn’t even know who the CEO was!”.
You need to research the company website, look at the staff, read the blog, read financial data if they have it posted, etc.
Most of the time, when you go in for the in person interview they tell you ahead of time the name of the person you are going to interview with. Look that person up on LinkedIn or twitter. See if you can figure you who they are, what they like to do. See if you have anything in common, like maybe you went to the same school.
You should spend a minimum of 1 hour researching the company. If the company makes a product, like a web or mobile app, you should download or install it. Create an account, play with it, see how it works.
If you can show that you did a TON of research before the interview it will make you look REALLY good.
Standing your ground doesn’t mean you should be argumentative, or just unpleasant. But it does mean that you should have an opinion. You should make your opinion known and defend it. If they ask you if tabs are better than spaces and you say, “Yes, I think tabs are better”, and they tell you that you are wrong.
Go to bat for yourself. Tell them that you disagree and list off several reasons why. This method can be tricky. First of all you have to actually know what you are talking about, don’t “blow smoke”. If you feel passionate about a subject feel free to defend it.
Let’s say your interviewer just asked you a question. Maybe you know the answer but because of the stress of the interview you are having trouble voicing it. If you ever find that they have asked you a question and you are going, “Um…uh…..ummmmm….uhhhhhh” then just start asking questions.
It makes you look like a really smart developer. Developers who are good at their job ask questions. When they are given a task they don’t just start hacking away. They make sure they fully understand the problem…by asking questions. It would look like this:
Interviewer: “Write me a function that takes two numbers as inputs and squares each number, adds them together, then returns the total.”
This is a simple example for demonstration purposes, but you get the picture. Now, lets say that you don’t know the answer or you are trying to think of the best way to write it. You can ask polling questions to get extra time.
Interviewee: “Ok, let’s see…will I have to account for negative numbers? Should I account for inputs of other types, like strings, arrays? What would you like the answer to look like when it is returned?”
This is probably the most important one. Basically, you want to be yourself. If you are funny, you should tell a joke or two. If you are really knowledgeable on a subject try and steer the conversation to that thing. Most importantly, don’t “blow smoke”. If you don’t know the answer don’t try and “invent” an answer just say that you don’t know but you would definitely look into it later after the interview.
You can say something like, “I actually don’t know the answer to that but I’ll make a deal with you, I’ll have the answer for you my first day on the job.”
What I mean by “Best” version of yourself, is that you should be yourself but try and accentuate the positive things and downplay the negative things. If you know that you tend to complain a lot and they ask you why you are looking to leave your current company don’t go on an hour long tirade about how terrible the company was.