Skip to main content

What Are The Types of Questions Asked In Tech Interviews?

Many interview prep books focus on the bread and butter coding interviewing questions, but in real interviews your interviewer may pose other types of questions. It is important to be comfortable and come prepared for these other types of questions which depart dramatically for coding questions yet still may bear considerable weight in your interview evaluation.

  1. Behavioral & experience

    These are the standard non-technical interview questions where the interviewer asks about what you did in particular scenarios and how you performed in the roles listed on your resume.

  2. Language specific knowledge questions

    There is a manageable set of questions for each common programming language. There are questions for uncommon languages too should to encounter a company that emphasizes their use of some of the lesser known languages. Usually these questions attempt to probe for your knowledge of some differentiator and key feature of the programming language. For example, virtual functions often come up as a question in C++ interviews. As a means for dynamic dispatch in C++, it is central to C++'s notion of polymorphism. For the purpose of the interview, however, the interviewer would most likely want to see if you know how virtual functions are implemented and what are they like underneath the hood besides what they are and how to use them. For Java, an interviewer may ask about the how the synchronized keyword works.

  3. Coding on a whiteboard, takehome, pair programming, in front of computer

    This is your standard type of programming problem solving. There is some variation from interview to interview in this category. Coding on a whiteboard is a base case, but adventurous companies are now testing candidates by inviting them to code on a computer furnished by them, with a choice of IDE, text editor, and compiler/interpreter. Though coding on a computer may be more natural, you are still under artificial time pressure. Moreover, with all the tools available to you, I would say that you are sometimes held to a higher standard than whiteboard interviews because in a whiteboard interview an occasional syntax error won't be blatantly obvious whereas on a computer, it is a deal breaker.

  4. Find the bugs & code review

    These questions can be very tricky. It is also more challenging to get prepared for these since the material out there is limited. To do well, you need a good amount of language-specific knowledge, since many of these questions are grounded in implementations in a specific language sometimes with an emphasis on the correct usage of language features. You need to be able to identify bugs, efficiency issues, and style issues. The best way to get prepared for these is to give and get code reviews, but short of that, read up some coding style and pitfalls in languages. Books such as Effective C++ and Effective Java should give you a good head start on what exactly to watch out for.

  5. System/API design

    These can seem daunting to those new to the interview process. Although it may seem that the interviewer expects you to have experience designing and implementing some huge system used by millions or billions of people, actually they just want to check that you know the language, framework, and trivia of scalable computing. In particular, they want to know if you can explain what are the common components in large scale systems and what tradeoffs are involved in using them. Common elements are load balancers, databases, and sharding of data stores. For API questions, you can prepare by getting familiar with some of the exemplary APIs out there such as Amazon AWS's S3 or the Flickr API. Get to know the lingo: what is REST and what makes one API more RESTful than another?

  6. Other knowledge

    These will cover the gamut: networking, HTTP, distributed systems, OS, compilers/runtimes, machine learning, architecture.

Stay tuned. I'll go over each of these in the practice sessions and in blog posts.

Comments

Popular posts from this blog

Complexity Analysis for Interviews, Part 1

This is part 1 of a two part series. Skip over to part 2 you'd like . For coding interviews, we are interested in gauging the asymptotic efficiency of algorithms both in terms of running time and space. The formal study of analysis of algorithms is called complexity theory, a rich field with fascinating and complicated math. For interviews, we only need a few basic concepts. Asymptotic efficiency is concerned with how the running time or memory requirements of an algorithm grows with the input size, so it is intimately concerned with how well algorithms scale to larger inputs. This is important in Computer Science and in practice because whereas some algorithms work well enough for small inputs of say < 10 inputs, the running time and space grows far faster than the input size and thus large inputs of say 10s to millions of inputs becomes impractical (usually meaning taking hours or even years of execution time). Consider sorting. Say for the sake of argument that sorting

Top 5 Books for Language-Specific Interview Questions

Shrunk and White of Programming When you put down that you know a certain programming language or languages on your resume, you are setting certain expectations for the interviewer. I would strongly caution against putting down "expert" in a language unless you invented or are one of the language's maintainers. You are giving your interviewer the license to quiz you on programming language lore. There are a handful of concepts that are considered "standard" knowledge for each language which go broadly beyond syntax and general semantics. These concepts commonly involve major pitfalls in a given language and the idiomatic technique for negotiating these pitfalls and writing efficient and maintainable code. Note, although the concepts are considered idiomatic, you can seldom infer them from knowledge of syntax and semantics alone. The tricky part here is that most courses that teach a particular programming language do not cover these idiomatic techniques and e