Preparing For a Developer Job Interview

I've been preparing for a QA position that has been open at Intel over the last few weeks. This tedious preparation made me want to create an easy guide that will help everyone, especially apprentices (like me), to be successful in landing the job offer they want. Don't blame this post if you don't actually get the job, I'm not offering 100% satisfaction guarantee like this guy.

My first reaction after I got called for an interview was to google for “job interview tips”, obviously. I only found basic recommendations and I was disappointed with all the generic advice. Like "don't talk bad about your last boss *Sirias exhales deeply as he is out of danger* "  or "be sure to arrive 10 minutes early to the interview". Sure, you should still follow these tips, but they are very obvious.

Here you will read tips focused on our field. Interviews for developers are very different than interviews for any other type of positions. Our interviews are rigorous; they might involve solving a programming problem right there on the spot. But hey, look at the bright side! At least tech jobs are on the rise and in high demand. *Don't read this out loud if your sibling majoring in political sciences is right next to you*

This post is designed to help you answer common questions that often come up in tech interviews. Questions that you actually don’t know how to answer the way interviewers want you to do!

Let's help him! He wants that job, so badly.

Job Interview basics

First of all: Why do companies interview?

• So an employer can make sure that the job requirements match up with a candidate’s skills and past experiences. 
• For you as a developer to meet new people and learn a little bit about the work environment before you even decide if you want to work for a specific company. Managers value if you ask questions about the position, what are the day to day tasks, responsibilities, work environment, etc.

Don't think of this process as an opportunity for others to judge you and find your flaws, view it as a chance for you to shine and show what you already know. 

What employers are looking for? 

Many developers think that the only thing important is job specific knowledge, having skills in Ruby on Rails, C# or Java. While it’s important to have skills in the specific programming language, it's definitely not the most important qualification.
For example, many developers don't even think about work ethic when a potential employer is evaluating them. And surely, recruiters are going to be looking at what kind of work ethic a person has. No one wants to hire someone with WFH privileges that is only going to work two hours a day or that is not used to putting all their effort into projects. 

Other soft skills that companies value strongly are:

• Ability to deal with people, good communication skills.
• Problem solving
• Ability to learn.

Many software development environments today are agile environments, and everyone in Pernix knows that in an agile environment you're much likely to be dealing with customers and be working in teams. If you're an excellent programmer but you can't talk to people you're not going to be useful to the company.

Don't make the mistake of never learning anything about your interviewer or the company that you're applying for. This is a big error to avoid. Nowadays, every company has a website, at least do some research about their industry and dig through their social media.

Finally, carefully read the job description and adapt your answers to that specific role, this is the biggest hint you will get about what type of person they're looking for.

Solving Algorithm Based Problems

Many developers don't know this very well, you might be asked to solve a problem right there and this can be very stressful if you don't follow the steps that I'll provide.

Facts:

• Most of these problems are not designed to test your mathematical ability, in reality, all you need to know to solve the problem is contained within the problem itself. 
• These problems often sound much more complex than they often are. You can usually boil these kinds of problems down to a simple task you're trying to do even if the description is very long. 
• These problems often have an edge case that you have to be aware of with a special handling of that case

1. Reading the problem: time spent here can save you a large amount of time trying to figure out why your code doesn't work. It's crucial to understand the problem before we can solve it.
2. Solving the problem manually: the goal here is to recognize and document what your brain is actually doing to solve the problem.
3. Optimize the manual steps: We should be looking for patterns or loops that can turn a series of manual steps into something that can be expressed in a simpler way.
4. Pseudo-code: take those manual steps we already came up with and write them as comments in pseudo-code. If you feel confident you can skip this step. This makes it easy to translate the manual steps into real code.
5. Real code: This should be the easiest step so far if you followed the previous steps. If you find yourself struggling with this step, it means that you didn't break down the problem into small enough steps or you don't know the programming language you're trying to use well enough.
6. Optimize the real code: See if there is any way we can improve our code so that we can make it clearer and more expressive, or perform better.

Trying to do problems like this can help you learn any language and can help you identify weak areas in your understanding of the language itself. Check out this link to apply the knowledge you just gathered: http://www.programcreek.com/2012/11/top-10-algorithms-for-coding-interview/

Typical Questions

Obviously, I'm not going to be able to cover all the questions about every single technology and language platform, but I will give you many answers to the most commonly asked questions. Questions that many developers fear that large companies apply to test your knowledge in computer science.

It's a good idea to specifically search for interview questions related to the technology that is mentioned in the job description. Memorizing the answers is a bad idea, it's important to understand why the answer is correct. Few things are worse than answering a question with a one-word answer and then being unable to explain the meaning of that word you just said.

• What are all classes in C# derived from?
• The simple answer is object, but it is best not to give a one-word answer. You should exceed the expectations of the interviewer and talk about why the answer is correct. For example explaining some of the methods that all classes have because they are derived from object like equals or toString.
• How does the same Java code run on multiple operating systems?
• You should answer this question by talking about the JVM, is important to mention here that when you compile Java code you're actually compiling the code to bytecode. Since that bytecode is interpreted by the JVM, and the JVM has implementations from many different OS.

• What is encapsulation?
• The idea of data hiding or restricting access to data. The goal is to keep classes loosely coupled and only expose data that you want to share with other classes.
• What is a design pattern?
• Often this question is answered with an example of design patterns but is better to answer directly. A design pattern is a solution to a common problem that generally occurs in different situations in software development. It is more of a template for solving a problem, rather than a specific implementation.
• Give an example of a time you had a disagreement with a coworker and how it was resolved?
• Bad answers to this questions are "I can't really think of a time I had a disagreement with someone" or "I proved him wrong". Try to recall a time when you were wrong, and you were persuaded to your opponent's way of thinking, few people have the humility to see when they are wrong, and admit it.

Getting Experience

This is often a challenge, especially for new developers who have no experience to get some experience in order to be more valuable.

Even with great problem-solving abilities and technical knowledge, it can be difficult to even get an interview if you don't have some sort of experience to show that you can apply what you know.

In this section of the blog, I'll be talking about some of the ways that you can get experience in the field even if you haven't yet been able to work before your current job  @Pernix.

• Pernix gives you a great opportunity to get involved in projects outside your daily job, maybe you can come up with an idea and lead an innovation project! More info about this is on the playbook.
• Teaching others: This is another thing that you can do at the office, help someone new and do a pairing with another apprentice. There is really no better way to learn a subject in-depth than to try to teach it to someone else. Extra points if you only communicate in English to improve your language skills.
• Get involved in an Open Source project: you also will help the community, so it's a win-win situation. Look at GitHub options and view projects that you can possibly join or commit to. An easy way to start is to find a reported bug in their bug tracking repository and go ahead and submit a fix. This will allow the project maintainers to get to know you. If you are brave enough you could implement a new feature that has been requested. Is important to follow the guidelines that are specified when contributing.
• Code camps: the majority are free to attend and they usually take place during the weekend. Hackathon, and all the activities that end with "thon" are excellent examples of these camps. In these events, you´ll find very welcoming people and a large variety of different developers with different skills levels.

Is good to have some full stack experience, what I mean by this is that you can have some technology stack that you can work on from end to end. Because many projects today involve a large mix of technologies, is good to have at least one focus area where you can work on the front end, middleware and back end. Examples: MEAN stack, LAMP, Ruby on Rails.


Summary: If you can proof that you are smart and capable enough to rely only on your soft skills to get the tasks done, and plus, you have technical skills from college, then you will definitely land your dream job. 

If you fail it doesn't matter as long as you gain some experience of that failure and apply that experience to the next interview.