Further thoughts on interviewing

I recently wrote down some thoughts on interviewing and thought they might make a good blog post. This is sort of a follow up to my previous post, which was more the job search as a whole (this is more interview specific).

I would definitely say that every interview (and interview process as well) is different. I had some interviews that were very knowledge based– questions like “What are the 4 common HTTP methods and when would you use them?”

Others were more about your thought process, critical thinking, and how you solve a problem. These types of interviews are more language agnostic– they care more about general programming and problem solving ability then if you know specific bits of information.

Of course, you still need to know enough details about some programming language to solve these more general questions. Others may even require knowledge of a particular language. A good example of this was one of my interviews, where I got asked a general programming problem but the question required me to know things like scope in Javascript (and how to use `call` and `apply` and `bind to change the “this”). I definitely think it’s important to be quite comfortable with one language at the minimum, but also flexible enough to program in a language you don’t know.

I would say there are kind of 3 general kinds of interview questions, at least for more entry level or “junior” roles:

1. the knowledge based ones (usually these are more short answer and way more common for more scoped roles like front-end positions)
2. Code Wars like problems: questions that are not too hard to understand but more about whether you can write code that works and is well written)
3. Questions that are more algorithmic in nature (data structures related a lot of them time)

Sometimes the 2nd and 3rd category overlap, where you have a question that mainly tests whether you can write good (and working code) but it may also cause you think about how to best solve the problem. I think the main difference between category 2 and 3 is that problems in the second are a bit more straightforward while the third requires more creativity and thought.

It obviously helps to know what you should expect at the interview. I found this out 3 ways: by asking the people who set up my interviews (so either the person scheduling it, or if I had a phone interview with an engineer, I would ask them about their onsite interview format), by asking other people who work with, and using Glassdoor (a super helpful resource).

I mention a few specific resources at the end of my previous post, but I mostly just did Code School problems, reviewed concepts, and sometimes did questions from Cracking the Coding Interview and other sources. I think a good general principle is dividing each day between interviews (both on sites and phone screens), practicing and preparing, emailing people you know to refer you, applying through AngelList and StackOverflow careers, and also reserving some time for non job search things.

Originally published at www.seemaullal.com on November 4, 2015.