A job interview doesn’t have to be stressful
Most people I talk to are either intimidated or scared by the process of interviewing. I’m not saying that I don’t get nervous, and my level of anxiety increases when I am employed and looking for a job vs. unemployed and looking.
I believe that this stems from an incorrect mindset when looking for a job. I have talked about this before but to reiterate, <– Programming Joke, you should approach a job interview like you are the person selling the car, not the person buying.
Sorry for the crude analogy but think about it like this. When you sell your car, you are in charge of the process. You have the power to accept or decline an offer, and you have more information than the person buying. The majority of people who are buying a car are doing so because they need one.
Don’t approach your job interview like this. You are the one with the skills, you are the one that can create revenue for a prospective company, and you are the one that will add value to the team.
When you go in, or even on the phone, try and keep the mindset that YOU are the seller and THEY are the buyer.
Junior job interviewers read on
The last section is good advice, I don’t care who you are.
The remainder of this post is going to be geared towards developers who are just starting out. Whether fresh out of College, starting from scratch, or changing from one domain to another, like me. 🙂 If you are a Senior Lead Architect Code God then you probably don’t have much trouble getting a job and interviewing is probably a breeze for you.
Nonetheless, if you are a Senior developer with a serious case of Imposter Syndrome, (like me), then keep reading.
You are allowed to have fun
This may not apply to everyone but people want to hire people they get along with. I’m not suggesting that you fake a personality but rather the opposite.
I have interviewed people who were totally dead-pan during an interview and refused to laugh or make any jokes themselves. Then after hiring then based on experience we find out that they are amateur comedians.
Can you take a joke?
If your interviewer tells a joke it’s ok to laugh. I once interviewed a College student with a freshly minted CS degree.
I asked him to describe his process for finding an answer if he got stuck. He gave the standard answer of, “Reading books or articles online, Googling, asking coworkers.”
Then I said, “Wrong, we’re a Microsoft Shop so ‘Bing’ was the correct answer.” He laughed, we laughed, etc. He ended up not getting the job but it wasn’t because he laughed at a joke.
If the situation arrises then it is even appropriate to tell a tasteful joke. I like to use a bit of tasteful self-deprecation to lighten the mood.
I had an interviewer ask me what I had accomplished at a previous job. After rattling off the 10 or 12 things I did while there I ended with, “all of that, and I was one of the worst developers there”.
You obviously need to be careful and this is of course a more advanced technique, but I am good at it. I have found that there are so many developers that interview and basically make themselves out to be perfect, flawless, code machines.
Most interviewers like to know that you aren’t to good to improve. They don’t want to hire someone who isn’t going to learn anything new the entire time they are employed there.
They also want to know that you can take criticism and don’t take yourself too seriously.
…but they have a great personality
In my experience if an employer is considering two applicants with similar skills they usually go with the person they think will be the best fit for the team.
You want to try and avoid the following:
- Being too argumentative
- Thinking you have nothing more to learn
- Talking overly negative of previous coworkers or employers
- Telling, (hopefully this goes without saying), rude, crude, sexist or racist jokes
You are allowed to ask questions
Part of your preparation for the interview should be collecting several questions to ask your interviewers. A good place to start is the job description. Look over the job description and take notes like:
- “They use the MVVM pattern instead of the more common, MVC pattern, why?
- “This is an iOS developer job but the description lists PERL as a “good to have”. Why is that?”
- “The description says, ‘Must be willing to work long hours’, what is the extent of that? Is it all the time or just occasionally?”
Your turn to become the interviewer
Another favorite method I use is to ask their questions back to them. This is one you kind of have to do on the fly, but you can take notes during an interview. I take notes in the interview, its something that almost no one does and I have gotten a lot of complements about doing it.
If they ask you, “So why do you want to work here?”, you can take a note of that. At some point, (usually towards the end which is why notes are good), they say something like, “Well, do you have any questions for us?”.
You can just re-ask some of their questions:
- “Why do you like working here?”
- “What is your favorite thing about working here?”
- “What is your most pressing development project currently?”
You are allowed to take a stand
I had a previous coworker that got into a pretty heated discussion about Entity Framework with an interviewer. He knew what he was talking about and even though this Senior Architect that was interviewing him had a different opinion he stood his ground. He got the job.
I think one of the biggest problems in software development is the “rubber stamp”. This is something I have seen numerous times from Junior Developers when interacting with more Senior Developers.
The senior person says, “Use X framework”, or “Do Y when you write that class”. The junior thinks, “Well they know better, they know more than me so I’ll just do what they say without question instead of researching the solution for myself.
This is doubly detrimental because a) you don’t learn anything, and b) you lose confidence in your abilities.
Acquiescing to senior people
The Senior person says, “Why did you do this, you need to change your code and do this…” Usually, the junior person goes, “Oh, okay”, and walks back to their desk to change the code. Don’t do this.
Now if you have absolutely no experience with the particular issue you shouldn’t take a stand immediately. However, you shouldn’t just go back to your desk and start implementing the plan that the senior developer came up with.
Head back to your desk and do 30-60 minutes of research. Inform yourself. If it turns out that the senior dev had it right then you at least have more knowledge on the subject and can better implement it.
Stickin’ it to the ‘man’ or ‘woman’
If you discover that they are wrong then you should let them know. I don’t mean you should stand on your desk and go, “HA! I KNEW IT! You were so wrong, it’s like you don’t even know what you are doing!!!”
You should just tactfully broach the subject. Let them know what you found and why you think that ‘X’ is a better solution. If they argue with you, stand your ground. Don’t be afraid to say something like, “with all due respect I think that ‘X’ is the best solution and unless you can give me a solid reason why it is a bad idea then I would like to implement it the way I have chosen.”
Proof that I practice what I preach
In closing I would like to provide a personal example. Recently I have been playing with writing my UI entirely in code instead of using Storyboards.
I actually prefer the code method and I believe very strongly that it is the better approach for most situations. In an interview for an iOS position I was asked if I preferred Storyboards or writing UI code. Here is what I said from the best of my recollection:
“When I started working with Swift and Xcode the part that I struggled with the most was Storyboards. There is really no equivalent in the .NET world.
Sure you can graphically design a form by dragging controls onto the form and laying out the form the way you want it but no one in my experience does that. Almost every form I have seen in .NET in the last 5 years has been all done in code.
I struggled with Storyboards and AutoLayout Constraints. I would get the view looking exactly the way I wanted it and then I would switch orientation, (also something you don’t deal with in Windows development), and everything would go crazy.
Once I learned to build views in code I never went back. Can I use Storyboard now? Yes. After all the late nights I spend struggling with it I am actually pretty good at Storyboarding now, but I still prefer creating views in code. It is the best solution for 90% of all projects.”
I don’t know for sure but I think they were impressed that someone applying for a Junior iOS position was so opinionated. I didn’t get the job but it was because the position was pulled by their finance department. The internal recruiter told me that I did a great job, and that they really liked me and he said he would be in touch if the situation changed.