Further thoughts on interviewing

Recently wrote some thoughts on interviewing to someone, and thoguht I would share. 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). That post can be found here.

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 (and coincidentally, the majority of the offers I got were like this) 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 specific programming languages to solve these more general questions. I think 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 am not linking the specific problem here, but if you would like to see it, feel free to send me a message. I definitely think it's important for most interviews 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- the knowledge based ones (usually these are more short answer and I noticed way more common for front-end positions), Code Wars like problems (questions that were not too hard to understand but more about whether you could write code that works and was well written), and 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 blog 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.

Show Comments