
Software engineering interview questions - sfbushstreet
https://oj.leetcode.com/problems/
======
gortok
The site sure starts out on 'dark pattern' footing. To sign up, you can link
your LinkedIn, G+ (who has that?), github, or Facebook accounts (seemingly,
not twitter), but once you do that, they claim there _may_ be a username or
email address conflict (even though you haven't provided an email address) so
they want your email address as well.

The proof is in the pudding:

[https://twitter.com/gortok/status/547468794160238592](https://twitter.com/gortok/status/547468794160238592)

They could just say, "Hey, we want your email address." Not "Gee, we don't
know who you really are even though you linked your unique account to us; so
we want you to provide your email address".

Not a good way to start our our relationship leetcode.

~~~
cheapsteak
I just signed up via G+ (I may be mistaken, but can't everyone with a Gmail
account signin using g+ ?) Did not get any message about email address
conflicts

Edit: Just tried signing up with Facebook (which has one of my other email
addresses on file), still no message about email address conflicts, signed up
and logged me with no issue.

Tried signing up for another account with GitHub and did get a message about
email or username conflict this time, but I was using the same email address
on G+ as Github so it was a legitimate conflict.

------
MoOmer
Sites down; but, I wanted to add that at the peak of Hadoop hype, an unnamed
company asked how I'd tally up occurrences of a value in a 1gb flat file,
where the job would need to be done recurringly on multiple files, quickly.
Without wanting to overthink it, I suggested a simple script iterating over
the file, incrementing the key/values as they occur.

Apparently the correct answer was a Hadoop job.

Now, given that my experience with Hadoop was limited at the time, and even
now only includes use of small clusters, that was surprising. It's sooooooo
slow in comparison, and for single 1gb files, it still doesn't quite seem the
best tool for the task to me.

Questions/Answers will sometimes be biased based on what the interviewer
prefers.

~~~
kyllo
_iterating over the file, incrementing the key /values as they occur_

Isn't that exactly what the Hadoop job would have to do anyway? The whole
point of Hadoop is to process the data in a single pass, which is what your
method does. As long as you iterate over the file without reading the whole
thing into memory first.

~~~
justizin
Yeah, if you described an actual fucking program, and their answer was the
name of a software package that you could learn in a day and they've been
trying to hire an expert in for six months, and you would still just use that
software package to run your program, be glad you didn't get the job. ;)

~~~
MoOmer
Oh, in retrospect, I'm very happy.

------
BigChiefSmokem
Best way is to paid-intern an engineer for a week/month and try them out (if
they're willing) and see how they fit and might be able to expand on your
current culture. That's really the only _good_ way.

Asking questions in an interview, no matter how clever or insightful they may
be, has been and will forever be a crap shoot.

~~~
soperj
Honestly, as someone who would have to quit their current job to go work for
another company, why on earth would I agree to that instability?

~~~
Bahamut
For me, speaking as a software engineer, I highly agree - if a company tried
to pull that on me, that would be a quick way for me to turn down the company.
It doesn't make sense if the candidate is working for another company - why
would the candidate use up all of his/her vacation for one company if the
company isn't serious about bringing the person onboard full-time as a regular
employee off the bat?

~~~
laeus
To be honest, having experienced the tremendous damage done by poor hires (and
the amazing difficulty of getting rid of them once they're identified as
such), I might see this as a pretty substantial benefit of working at a
company that uses this method. Given that, I might be willing to participate
in this kind of interview process. It would probably have to be a company I
already know and admire for some reasons up front, but I really want to find a
place to work where everybody is pulling their weight.

~~~
Bahamut
I haven't seen a decent-sized shop where "everybody is pulling their weight".
Different developers at are different points in their careers, and have
different levels of productivity. As a junior developer, I was very slow when
I first started. As a senior developer, I have produced 50% of the work for a
project on a team of 8. There are only so many developers that want to work
for [insert company] out in the wild.

I do sympathize with the big damage done by poor hires & problems getting rid
of them - I have seen similar as well. However, a process like this will
select against a lot of quality developers and not necessarily select for the
ones you want to work with. It just selects for the developers that that
company wants to work with who are willing to jump through such an extra set
of hoops. It also tells me as a candidate that the people who are working
there don't have the courage to speak out against such a process selecting
against candidates not willing or able to go through the process or the
leadership is too weak to figure out that this sets up a bias that isn't
intended to be selected for, thus being a bad hiring mechanism.

~~~
laeus
Right, I meant "pulling their weight" in a relative sense, with the
understanding that a more experienced and talented employee will do more work
or do it more quickly. Maybe my desire is simply to increase the proportion of
coworkers who make roughly appropriate contributions to the team effort. I
once had to explain how splines worked to a graphics programmer with 20 years
of industry experience.

A trial process like this would select against lots of quality developers,
true, but that isn't the real question. Instead, I want to know whether the
developers who wind up being hired represent a more talented subset. I can't
prove that it would, but I feel that this system would be more accurate in
letting the right people through.

All that said, I like some of the gray area solutions proposed in this HN
thread, including after-hours or weekend remote work on a project already in
production. Not a perfect solution, given the inability to evaluate things
like culture fit, but it combines many upsides of the alternatives.

~~~
Denzel
>> I once had to explain how splines worked to a graphics programmer with 20
years of industry experience.

Is the knowledge of splines a major predictor of a graphics programmer's
success? I don't understand why it appears to be a point of denigration here.
The details of your story are foreign to me, of course, so maybe I'm missing
context. But it's always helpful to remember that time is finite when compared
to the seemingly infinite amount of things to learn. No one comes to work and
says, "I want to suck today!"

------
matthewmacleod
I'm not convinced that questions like these work effectively at all. They
might give you some insight into a developer's ability to research and
implement some specific algorithms (because you're not making them do it on a
whiteboard, are you?) but there's a lot more to being an effective engineer
than that.

We've had success with a two-hour pairing exercise, in which the goal is
"build a miniature version of one of the core parts of our product" with one
of our engineers. That's followed by explaining the goals, technology, general
approach etc. to another engineer, then a discussion about what would happen
next, some of the specific domain problems, that sort of thing. There's no
expectation that the project is completed in the time available, and it's more
about understanding the process.

This has been pretty effective, and is great for getting a more rounded
understanding of the skills of a particular engineer. In my experience, rather
softer skills like the ability to clearly articulate the problem, to
understand the broader impact on a bigger system, and to be able to identify
future issues and challenges are more important than the ability to solve
specific technical challenges. Lackluster technical ability is usually pretty
immediately obvious when pairing with a developer, in any case.

~~~
sfbushstreet
This is how companies like google, facebook, and linkedin interview
candidates. It's not effective, but it's the common practice

~~~
Kurtz79
It's not very effective, but I don't think it's that bad.

In the end as a developer your job is to solve problems, and getting hired is
simply another problem (solving which has self-evident benefits, so you
shouldn't lack motivation).

It's not like the hiring process for technical jobs is shrouded in mystery:
there are tons of resources on the internet about it.

You know what kind of questions will be asked, you know how you are expected
to answer, the rest is just study and practice: a successful interview should
be at least proof for the employer that you are able to grasp that process and
carry out the work necessary to see it through.

~~~
general_failure
Solving world peace and curing cancer are also problems. I don't think
engineers are best suited to solve them.

~~~
collyw
We leave world peace to politicians. I think engineers would probably do q
better job.

------
sfbushstreet
Sadly, each time I want to change job, I have to go through those questions
again. No any company (or interviewer) would admit that they decide whether or
not to extend an offer to you solely based on how well you solve those
programming puzzles. But reality is, your "performance" during the interview
session is oftentimes more important than your experience (e.g., your side
projects. Even you can demo your projects in front of interviewers, they just
don't care -- because they themselves joined the company in the same way --
solving programming puzzles)

~~~
disjointrevelry
I blame it on primate science. Some scientists got some chimps, did some
tests, and figured running tests and puzzles on the chimps to gauge their
performance must map to humans as well due to a loosely correlated metric,
such as genetic distance.

------
fragmede
I'm surprised at this list of questions. Didn't everyone get the memo that
"brainteasers are a complete waste of time?" from a year and a half ago?

[http://techcrunch.com/2013/06/22/the-technical-interview-
is-...](http://techcrunch.com/2013/06/22/the-technical-interview-is-dead/)

~~~
pixeloution
I didn't see much that qualifies as a "Brain Teaser" \- most of these are
algorithmic questions. Knowing when do implement a depth first search != brain
teaser.

~~~
peeters
Actually a crapload of efficient algorithms are applications of "clever"
tricks. They're not necessarily intuitive, and the people that can recite them
in interviews have very often already seen the solution (or the same general
pattern applied to a similar problem). In that sense, they are very much like
brain teasers.

If every programmer should be able to construct complex algorithms from first
principles in a 10 minute window under the pressure of an interview, we
wouldn't have so many algorithms named after the people who discovered them.

~~~
MaxScheiber
I don't follow your argument. Candidates for a lot of software engineering
roles are expected to know a certain selection of fundamental algorithms,
including things like DFS and Dijkstra's. The companies I have interviewed at
have been very clear about what is expected knowledge. I don't see how this is
at all relevant to being able to construct it from first principles. That's
the whole reason you're expected to know it!

If you're talking about "tricks" like the tortoise and the hare solution to
detecting if a graph has a cycle, then sure, I can get behind that. However,
there is a base of algorithmic knowledge that you are expected to know, and it
is entirely irrelevant whether or not you can construct it from scratch.

~~~
altpaddle
Ok but the question is why are some of these questions even considered the
'base' level of knowledge for interviews? At least on the front end side we
still ask about these algorithms even though binary search trees and
Djikstra's have almost no application in our work.

The reason for these questions being considered 'fundamental' seems totally
contrived, and that's that everyone studied them in their CS program, not
necessarily because that's the kind of knowledge you apply day to day.

~~~
MaxScheiber
Graph traversal is quite relevant to DOM manipulation. More generally, these
sorts of "classical" problems come up more than one would assume at first
glance.

I believe that understanding the theoretical backing is very important for
making correct software design choices, at least at the positions I have held.
Moreover, this base knowledge is a proxy for general awareness of complexity
analysis and architectural trade-offs (why do we pick this structure over
that?). I agree that we needn't consider single-source shortest paths every
day when programming, but for companies that want to be sure they are making
good hiring choices, this seems reasonable to me. Graphs, for example, come up
so often in practice, which is why I refer to them as fundamental. It's not
like we're talking about red-black trees here. Again, it's a proxy for one
part of what makes a great programmer.

~~~
general_failure
If you wrote code that requires graph traversal in DOM, you are doing it
wrong.

------
jschulenklopper
From the description: "Pick from an expanding library of more than 150
questions, code and submit your solution to see if you have solved it
correctly" the Project Euler site tops that number with a similar proposition.
Project Euler has almost 500 problems at
[https://projecteuler.net/](https://projecteuler.net/).

OK, perhaps it is more targeted to the mathematically inclined, instead
towards engineers on their route to a technical coding interview. Nevertheless
it has a very interesting set of (challenging) problems, and I see a number of
similar problems at LeetCode.

Project Euler is also a great environment for trying out new programming
languages, as the code is not part of the submission. As long as you come up
with the correct answer (which is always a number), Project Euler considers it
solved. You might solve the problem with C, Python, ACL, Ruby, pen-and-paper,
Ada, Mathematica, Wikipedia... Euler doesn't care. So, sometimes I solve some
problems multiple times, just to try different concepts or algorithms in other
languages.

(By the way, the title "Software engineering interview questions" is a little
broad. It is a set of (mainly mathematical) problems that may be solved by
writing some code, but it doesn't address other relevant software engineering
experience/aspects.)

~~~
sfbushstreet
The original title was not "Software engineering interview questions" ...
Administrator of hacker news changed it ...

~~~
sfbushstreet
The original one was like "Most engineering interview questions of hot
companies". My point was, very few companies are innovative for recruiting.
Interview questions can be practiced, which only test a small subset of skills
for software engineer position.

~~~
jschulenklopper
Well, I can see the reasons for a title change then; the page does not really
explain the claim in the original title. It is an interesting collection of
problems applicable for a coding interview -- which is not the same as "most
interview questions" \-- and it doesn't mention the companies (hot or not)
that asked them. Nevertheless, it's a good find and a relevant submission to
HN.

------
eeeemmm
I never asked any of these question, a good engineer is not a mathematician.

~~~
AYBABTME
A good engineer should have a good base in algorithms, know which one to use
for which problems, and when the algorithms matter and when they don't. And be
able to research literature for appropriate ones when the need arise. That's
not the end of what qualifies a good engineer, but it certainly is part of it.

CS and math researchers write papers (partially) so that engineers can pick
them up and use them to improve on what's possible to build.

~~~
jghn
The vast majority of programming jobs are such that the people working at them
will never need to understand these things. It's a sad state of affairs, but
it's how the world is.

Along those lines, most people feel that _their_ programming jobs don't fall
into that category.

------
aercolino
If you want to see how they code, why do you want to see their own algorithm?
In normal conditions, They would Google the problem and find its algorithm on
Wikipedia (with lots of additional information to peruse) and some interesting
implementations on stackoverflow (both to choose from and to learn about
related issues).

Programming in the wild has very little to do with knowing beforehand or being
able to invent on the spot an algorithm.

But the real reason why software engineering interviews are being done that
way is because programming is not perceived as an art anymore. Engineers'
scope inside the company was greatly reduced, while their number increased.
They are now commodity workers: Not only they must be replaceable, but also
expanded and shrunk as soon as possible, much faster and cheaper than before.

------
sfbushstreet
btw, this website is well-known among Chinese and Indian.

It's really really very hard to encounter an interview question that is not on
this list nowadays, if you are interviewing with big name companies like
linkedin, google, facebook ... It's more like preparing for final exam in
college.

~~~
lightblade
True, but I didn't expect someone post it on Hacker News. It's supposed to be
a secret weapon. Not so secret anymore.

------
vvoyer
I am not able to answer any of these easily and still get a lot of job done
and job offers every day/two days.

Interviewing for a frontend Facebook job is all about doing an
Array.map/reduce no more.

What matters is what you can do.

Few engineers really need to learn and master "Binary Tree Level Order
Traversal" every day after coffee.

~~~
barrkel
I like to give slightly more difficult versions of these questions as take-
home problems, rather than interview problems. Give them out after phone
screen, but before in-person interview.

And yes, something involving a binary tree order traversal would be the kind
of thing that I'd be interested in. Because I want to work with programmers
who can code, who at the very least know what recursion is and are able to
employ it in the solution to a problem.

Concrete example: the startup I'm at has an expression editor. Expressions are
tree structured. Typing an expression tree involves a post-order traversal. If
there's an error in the validation, I need the programmer who's working on it
to not be phased by these simple concepts. This typing currently happens in an
async background task in Java, but it could give a better experience to the
end user if it occurred in JS on the client's machine. This stuff just got
really relevant after coffee.

But more importantly, I want to see what kind of code - how convoluted or not,
how elegant or not, etc. - the person writes. I want to know what kind of code
I'm going to see in pull requests, and how much of a PITA it's going to be to
get them up to scratch.

Standard engineering stuff like unit tests can be taught. Writing tight,
readable and elegant code is much more difficult.

~~~
aercolino
For me it would be much more valuable if the programmer knew that a tree
wouldn't be needed at all if expressions were represented in reverse Polish
notation.

However, in the last 30 years, I needed to process expressions at work and by
myself exactly zero times.

~~~
barrkel
Humans have to read these expressions and understand them for auditing
purposes. RPN might be suitable to CS and mathematics geeks, but not everyone
in banking has that background.

------
wbhart
The hard questions in that list seem much easier than the Google foobar
challenge questions. Though of course you have days to solve those, rather
than having to solve them during a (presumably short) interview.

------
general_failure
These days I dont even bother with such interviews. I talk directly with
people in power and skip all this bullshit. All positions like VP, director,
manager roles have way more real influence compared to an engineer. None of
thrse positions require you to answer these questiins and yet give more pay
and influenve on the final product. Unlike an engineer who has to work from
the bottom to drive change. Unless you are a colleve noob i would really ask
you to reconsider your job position if these are the questiins you are
answering. Talking of 90% of the software companies here. I do know real
engineers do tremendous stuff.

------
atrilumen
I would love it if it supported more languages.

I'm currently obsessed with learning Haskell, so I'm tempted to attack all
these problems with it.

~~~
jschulenklopper
Try Project Euler, [https://projecteuler.net/](https://projecteuler.net/). It
doesn't care the language in which you code the solution... as long as your
answer is the right number. Since the problem set starts with some easy ones,
it is a great site to try out new languages (or new techniques like dynamic
programming) and start with a low problem number.

------
doing_engine
A good engineer is adaptive enough to grok and keep the business goals a
priority. Developing systems is just an implementation detail.

------
wehadfun
i guess you have to buy a book to use the website. Interesting monetization
policy

