
A list of lists of interview questions - melenaos
https://github.com/MaximAbramchuck/awesome-interview-questions
======
BuildTheRobots
Impossible to mention a list of interview questions without acknowledging
David Thorne's 10 interview questions on 27bslash6.

They're almost entirely ridiculous though I've used a couple when interviewing
people.

"How is this an issue?" and "Are you pro-active or reactive" can both lead to
exceptionally telling answers. Or just confusion, despair and upset... but
certainly have the possibility to almost....

[http://www.27bslash6.com/interviews.html](http://www.27bslash6.com/interviews.html)

~~~
soij09
Surprised to have never heard of him. That was really funny!

~~~
mercer
If you're new to him, you're in for some fun. The spider article is great:
[http://www.27bslash6.com/overdue.html](http://www.27bslash6.com/overdue.html)

------
johnnylambada
I looked at the first few Android question lists and the questions were
terrible. "What are the four API classes used for sensors?" Are you kidding
me?!? I have over 10 years of experience building Android apps and I have no
idea of the answer -- and I've probably used them! Along with the thousand
other apps and classes in the framework. If someone asked me that question I'd
kindly explain that I'm no trivia master, that's what documentation is for and
walk away.

~~~
JumpCrisscross
When interviewing for senior (read: C-suite) positions, I sometimes try to
gauge how someone reacts to dumb questions. Ignoring it is bad. Walking out is
bad. Explaining why it’s wrong is good. Trying to get at the intended question
is best.

Probably not what’s going on here. But human systems require debugging as much
as technical ones.

~~~
muse900
Well if thats what you practice on your interviews then you might miss out at
some people that might react the way you want them to react and be a good fit.

I would personally walk away as well, its not like am some kind of superstar,
I just feel that I won't be a good match to a company that asks questions that
I feel are not needed. The way I see it an interview is always two ways. The
company is interviewing me to see if am a good fit and I am interviewing the
company to see if they are a good fit for me since I'll be spending at least 8
hours a day 5 days a week of my time working for that company.

Personally so far what I've seen working ok for us in human systems is to just
have a talk with the person we are interviewing, see what his/her hobbies are
and generally feel if he/she is a good fit.

~~~
JumpCrisscross
> _I would personally walk away as well, its not like am [_ sic _] some kind
> of superstar_

You’re a perfectly-reasonable person. I also think you’d find the work those
positions do frustrating.

You can’t tell a multibillion-dollar client they’re asking stupid questions.
You also can’t ignore the potential problems their asking them hints at.
Walking away, usually, isn’t an option. Similarly, a CEO and CFO must be able
to productively field “dumb” questions from potential investors, acquirers,
distributors and yes, employees. “Dumb question” shouldn’t frankly exist as a
category in certain relationships. Only opportunities to improve mutual
understanding.

Not every role is for everyone. And not everyone is for each role. Part of
interviewing, in my opinion, is not only qualifying for fit with the company
but also fit with the role. (For solely internally-facing roles, I prefer a
let’s get a walk/beer/take a hike together chat.)

~~~
whatshisface
Purposely saying something wrong seems a little dishonest, like you are
setting a trap. It really sets things off of the wrong foot if your first
interaction proves that not only can you conceal your true thoughts and
express something that you aren't thinking, and not only are you willing to do
it, but on top of it all it doesn't take much motivation before you start. It
would be a lot better to wade in to something you honestly didn't know about,
so that your expression of not knowing enough to ask good questions was not
only completely realistic but also truthful. If you can't think of anything
that you don't know enough about to ask good questions, then you either need
to evaluate yourself better or get out more. ;)

To see it from another perspective, imagine what your response would be if you
found out that someone you were interviewing was pretending to know something
they didn't, just because they preferred to work with people smart enough to
notice they were faking.

~~~
JumpCrisscross
> _Purposely saying something wrong seems a little dishonest_

I agree. I never proposed that. I said I purposely ask questions the person at
hand might consider dumb.

Note that many classic “dumb” questions are actually interesting, if not in
their specifics then in _why_ so many people ask them.

> _imagine what your response would be if you found out that someone you were
> interviewing was pretending to know something they didn 't_

Again, asking dumb questions doesn’t require lying. Everyone goes through a
dumb-question asking phase when learning. (I do.) The worst effect of this
might be the interviewee walking away thinking me uninformed. Which, if I’m
interviewing them, I probably am (relative to them). That’s why they’re being
sought! In any case, people thinking I’m dumb is a fair price to pay for a
well-tempered executive.

[1]
[https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect](https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect)

------
PJDK
In the last set of interviews I've conducted (for junior/midlevel C#/vue.js
devs - still hiring if anyone wants to experience this for themselves and is
in London - link at the bottom) I've settled on a list that more or less all
start with "can you tell me about a time when...", or some other variation on
asking about experience. One's I've had a some success with...

\- A bug that was particularly difficult to track down? (What did you learn?
What would you do differently?)

\- A time you disagreed with your manager/lead? (And a time when in retrospect
you think you were right/wrong/got your way/didn't get your way?)

\- a piece of work took much longer than you anticipated? (what did you/would
you do to prevent it happening again?)

\- you had to quickly learn a new thing?

For more specific technical stuff I like to try and find questions that allows
someone to show off, rather than tests if they know just one thing. We're
using Typescript, C# and TDD...

\- what new or upcoming features in C# do you most like using/would like to
get the chance to use/really wish were out already?

\- what parts of Typescript do you find most useful vs Javascript?

\- what makes a good test?

\- what makes a bad test?

I don't see why anyone wants to ask anything of the what does using `ref int
foo` mean, especially when there's lots of competition in the job market at
the moment!

[https://www.linkedin.com/jobs/view/full-stack-c%23-vuejs-
typ...](https://www.linkedin.com/jobs/view/full-stack-c%23-vuejs-
typescript-2-years-experience-at-appraisd-965026309/)

~~~
inertiatic
That style of question is perhaps the most horrible one to subject someone to.

Instead of focusing on the task of talking to someone, you end up trying to
recollect instances of each kind of event, evaluate them on whether you can
talk about them openly, whether they can sound impressive even if they
actually are, whether they will sound plausible, whether you can recall enough
details to avoid being called out as a bullshitter etc.

The people who can appear to answer these questions best are either a)
prepared for them specifically or b) psychopaths who can comfortably lie and
twist stories with a smile on their face on the spot.

~~~
PJDK
Well I'm very happy if people have prepared for these questions beforehand,
and I try and give people hints and nudges to help get good answers out of
people (I want people to do the best they can!).

Do you think there are any style of questions that do work well?

~~~
supernintendo
I think a healthy mix of open-ended questions (such as those in your post) and
closed-ended questions is key. Open-ended questions are useful for getting at
how an engineer goes about solving a problem. Closed-ended questions reveal
whether that engineer has the tools to solve the problem to begin with.

~~~
PJDK
Interesting thoughts. What would you think of as a good closed ended question?
I always worry that if I'm to specific I'll get false negatives (do they
really not know what protected means or have they had a brain fade under
pressure?)

------
halfastack
I looked over the Linux questions, and they were pretty bad:

Q.1: What is the core of Linux Operating System? Shell

Kernel

Command

Script

Terminal

I mean... If they asked me about that at an interview, that'd be a huge red
flag. I wouldn't consider this list when studying for interviews... It is sad
for me how many stars and forks this list has. Hopefully, it's much better for
other languages/topics.

~~~
kraftman
Is it supposed to be a list of good questions you should ask, or crap
questions you should prepare to get asked?

~~~
jcranmer
The repository name is "awesome-interview-questions". So far, of the 3 lists
I've looked at, [1] was a page where someone apparently deleted random swathes
of text in the middle of the content and utterly unusable as a result, and [2]
and [3] were both full of grammatically poor questions that ask about minutiae
of C++, get it wrong, and don't realize that C++11 exists.

I think it's supposed to be a list of good questions to ask, but it's actually
a compilation of lists that people sent the author with very little to no
curation actually done.

[1] [http://placement.freshersworld.com/power-
preparation/technic...](http://placement.freshersworld.com/power-
preparation/technical-interview-questions/C-programming-answers-21419)

[2] [https://pangara.com/blog/cplusplus-interview-
questions](https://pangara.com/blog/cplusplus-interview-questions)

[3] [http://a4academics.com/interview-questions/57-c-plus-
plus/41...](http://a4academics.com/interview-questions/57-c-plus-plus/419-cpp-
interview-questions-answers)

Edit: Just opened up a Java list for #4... and it said that LinkedList was
usually better performance over ArrayList. That is not correct; ArrayList is
usually better (because of cache locality). So I'm now 4 for 4 on bad lists
out of this site.

~~~
technion
This really seems to be the trend with "Awesome" lists. It's not often they
appear to have much curation at all, it's frustrating to see them end up with
thousands of stars. Often an order of magnitude more than many open source
projects.

I quite enjoyed the Erlang questions. Apparently "what is Erlang" is a common
Erlang interview question.

~~~
rwnspace
Generally speaking, I consider them a noobtrap for two reasons.

First off, many of the resources are written and submitted by people who have
no place teaching others - and are writing almost purely to self-promote and
have something to show to employers.

Second, even if some of the resources in there are of decently high quality,
the probable best schema for how to use and integrate that resource is going
to be bound up in a textbook written by Someone Very Important. Along with all
the stuff you really need to know anyway.

Scrap that, three reasons. Finding and aggregating these kind of links for
your personal use is of value: it develops your taste and sense of what
resources to veto, and what to collect, and is a meta-skill applicable
everywhere you have a search engine and some curiosity.

In '17 and early '18 I wasted hundreds and hundreds of hours collecting "the
perfect" set of bookmarks for various things I want to learn, and my
collection method has basically been to scrape these kinds of lists and apply
a surface-level "ooh sounds cool" filter to what I pick up. Obviously, I
learned very little doing this, and almost never open such links except as
part of a half-hour flight of fancy.

Perhaps if you're of intermediate/expert-level, these factors aren't that
important to you - if a couple of links are handy they've served their
purpose. But you're probably not going to star the repo. It's mostly thousands
of perma-beginners who should be opening textbooks and playing with
fundamentals in a REPL who are starring this stuff.

------
mdeeks
A lot of the Python ones seem like fairly poor phone screen questions to me. I
like to ask my candidates to solve a realistic problem just like they would if
they were working at a desk with me. Q&A where they either know the answer or
do not are awful. "Me: Do you know this random fact about python? Them: No...
Crickets: <awkward cricket noises>". <\-- All I've learned from this is that
they don't know that fact and I have zero idea of their coding and problem
solving ability.

Instead we ask them to pair program on a live IDE and tell them that using
Google is okay (copy/pasting code is not). I don't care if you have the
standard library memorized, I care if you can solve problems and have the
experience to understand how your code can fail and how to make it robust. I
care if you can write clean code and then later easily refactor it when I add
some complications to the problem. I care if you know how to make it perform
well, etc.

Testing for Linux skills? Give them a broken VM/Vagrant image and ask them to
troubleshoot it, fix it, and install and configure some things. Testing for
Ansible/Puppet/Chef knowledge? Ask them to do all of the above and send you
the playbook to recreate the fixed image from your broken image.

Interviewing is hard and if you haven't spent many hours thinking on it,
setting it up, testing it against your current employees, and figuring out
some kind of score sheet so it isn't 100% subjective, then everyone is going
to have a bad time.

------
dorianm
Looking at Rails, first list, first question: "What does ruby name refer to?"

I interpreted the question as: "What does ruby's name refer to?" so I guess
the precious stone... but no
[https://www.careerride.com/view.aspx?id=2439](https://www.careerride.com/view.aspx?id=2439)

Anyway, this seems exactly what a typical clueless recruiter would ask and try
to pattern match the answers to

------
Waterluvian
Awesome lists shouldn't just be "huge lists". The first item for Python is
pretty awful. Spelling and grammar aside, there's no code formatting so some
of the examples don't even make sense.

------
sotojuan
Rule of thumb - outside the original lists by Sindre Sorhus, most "awesome"
GitHub lists are of very poor quality and curation. They're made with good
intentions but rarely checked or updated.

------
n4r9
I haven't yet reached the stage of giving interviews but I've given some
thought to it. Based on the experiences I've read, it seems that technical
proficiency should be addressed in a basic way prior to any in-person
interview; the latter can then be devoted to gauging fit and personality.

My idea for the technical side is this: procure a fairly subtle, simple, real-
life bug that you yourself have had to fix. Ideally it should involve a single
class or function and require about an hour for a competent person to fix.
Email the code to the candidates along with the parameters that fail, and ask
them to resolve the bug and return the code.

This tests a lot of skills that should immediately filter out unsuitable
candidates - such as code comprehension, bug-finding, and problem-solving -
all in a real-world scenario. You can also change up the scenario every couple
of months, and very quickly test whether a candidates' code passes. Has anyone
come across something similar to this?

------
magicalhippo
[https://github.com/MaximAbramchuck/awesome-interview-
questio...](https://github.com/MaximAbramchuck/awesome-interview-
questions/issues/126)

Suitable question given the apparent level of the list...

As for my current job, I think I only got one directly programming related
question. They asked if I had done any work with public key crypto, ie
generating and verifying signatures etc. I hadn't, though I knew about the
theory and math involved.

Maybe they checked out some of the OSS contributions I referenced though...
I'll have to ask now.

------
FabHK
From looking over some examples, there doesn't seem to be much curation: many
linked articles are pretty bad (typos, and questions that ask for
regurgitation, not understanding).

------
usaphp
> 15\. What is the best multilingual plugin for WordPress?

What???

------
ilikehurdles
Anyone have good resources for the whiteboard side of things? Preferably
example questions I can go out an practice? I passed a couple of screens with
flying colors with the company I'm interviewing at, but now I'm about to go
onsite again and do the final whiteboard+general interview. I tend to blank on
basic concepts in front of an audience on a whiteboard and then suddenly I'll
figure out the answer in seconds after walking out of the interview.

~~~
technion
The resource I'm surprised never gets recommended is _buy a whiteboard_.

I found it incredible how much code you can write and feel competent in before
finding out crunch time you literally can't write legibly on a board.

------
daniel_iversen
More is not better - definitely not in interviews.

I only skimmed a couple of bits but there ought always to be more “thinking”
questions rather than “remembering/knowledge” questions.

And of course if you wanted to use some sort of list of interview questions
the cultural non technical questions (which isn’t the scope of that curation I
think) are the most important questions of all I believe.

------
ubersoldat2k7
Jeez... Why don't we cut the crap and convert this to every single CS school
curricula.

~~~
saagarjha
As many comments here have mentioned, they're not very good questions.

------
meggar
The very first Swift question has a partially incorrect answer. It says that
"var array2 = array1" creates a copy of array1. But it's incorrect because a
copy isn't actually created until one of them is mutated.

------
myegorov
Also from the authors: Jerry and David's Guide to the World Wide Web[1]

[1]
[https://en.wikipedia.org/wiki/Yahoo!_Directory](https://en.wikipedia.org/wiki/Yahoo!_Directory)

------
jccalhoun
So do job interviews for computing-related jobs only ask about your skills and
not your personality, goals, or motivation? Or is this list of "interview
questions" just focusing on the computing?

~~~
sgerenser
In my experience with technical interviews, the majority of time is spent on
algorithm questions. This was especially bad at a recent interview I had at
Google... all 5 interview rounds were almost entirely focused on one or two
algorithm questions without any regard to any of the usual open-ended
questions about past challenges, motivation, etc. I even had one interviewer
start out asking about an interesting technical challenge I had, and basically
cut me off after a minute or two with kind of a "ok thats great lets get on
with the whiteboard now."

~~~
throw0u1t
What algorithm questions did they ask?

~~~
sgerenser
Technically I'm not supposed to reveal the exact questions they ask because
they have candidates sign an NDA that covers the questions they ask during an
interview. But it really shouldn't be too surprising the type of questions
they ask, basically similar to stuff you see on sites like Leetcode or books
like Cracking the Coding interview. Although very heavy on trees and graphs as
opposed to the easier linked list/string/array type problems. Since it was an
embedded position, there was on interview round where they asked some stuff
about device drivers and Linux Kernel internals. Overall I thought it was a
pretty bad interview for how "smart" Google is supposed to be. I thought
Amazon actually did a much better job with interview questions, although they
were still very algorithm-heavy.

------
jcranmer
"Curated" seems rather strong. One of the C++ lists has some let's-trip-you-
up-on-trivia questions, with bad answers to boot:

> 1\. Explain mutable and volatile keywords.

> Volatile keywords are designed to prevent the writer from applying
> optimisations on objects over which he or she has no control. Any objects
> that are declared as volatile are just omitted from optimisation to prevent
> values being changed by coding outside the scope of the original code.

Volatile is a keyword which tells the compiler to not optimize away loads or
stores to the relevant memory location (note that volatile is actually a
property of memory accesses, not variables, so there's lots of fun corner
cases such as volatile bitfields). Actually, strictly speaking, it was
originally meant to tell the compiler that the variable was being used to
access memory-mapped I/O registers, but it has been shoe-horned to serve other
deoptimization uses as well.

> 5\. When would you use virtual inheritance?

When you want to find bugs in your compiler. :-) Well, the "correct" answer
given in the guide is to not use it, but let's explain what it does anyways.
The question really should have been to explain the difference between virtual
and regular inheritance, although this does venture into obscure trivia
territory because I'm not sure I've ever seen someone use it or want to use it
in over a decade of C++ programming...

> 9\. What does the acronym OOPS stand for?

This is a worse-than-useless interview question. For starters, I've only heard
it as OOP (object-oriented programming), so I have to guess at the S. It has
nothing really to do with C++ in particular, especially as C++ has been
growing in non-OOP ways in the past decade. Finally, the question doesn't ask
to explain or contrast OOP with other paradigms, it just asks you to say that
you know its abbreviation. You can know an abbreviation without understanding
anything else--I know that SU(3) means Special Unity group of degree 3 but I
literally know nothing else about it.

> 13\. Define an inline function.

> This is when a function is prefixed and the keyword ‘inline’ is placed
> before the function definition. They often work faster than normal functions
> as the compiler replaces the definition of inline functions at compile-time
> instead of the referring function definition at run-time.

... That's not correct. In C and C++, a function can only have one definition
in general. An inline function--which can be specified either by adding the
inline keyword or by giving the function body within the class definition--
circumvents this rule, instead supplanting it with a rule that the linker must
discard all but one copy of the function.

Note that compilers do not generally treat inline as a hint as to whether or
not to inline a function, they use their own heuristics instead (incidentally,
the register keyword falls in the same boat). Obviously, the function cannot
be inlined if its body is not present, but equivalently replacing inline with
static would generally have the same impact on inlining.

~~~
n4r9
It's "special unitary" but I fully agree with the sentiment =]

------
clircle
I would like to see something like this for statisticians and data scientists.

