
Python coding interview challenges - sconxu
https://github.com/donnemartin/coding-challenges
======
cauterized
I see these challenges as a great way for excellent experienced developers to
weed out incompetent companies.

I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal
with one of these sorts of problems in my day to day work; and if I did, I'd
just find an existing, tested, stable library that already handled them.

A company that needs someone to solve these sorts of problems doesn't want me
on their team in the first place, nor would I thrive there. A company that
just needs to build damn good web apps is losing out by using these sorts of
questions in their interviews.

The best interview challenge I've had (actually, it was a take-home, with
discussion in the interview proper) was about designing code for re-use and
extension. It was a great indicator of the company's practical and mature
approach to engineering, and of what they really wanted this hire to
accomplish.

~~~
hashkb
> I'm a kick-ass get-things-done full-stack web engineer.

And modest, too. If an engineer gave me your answer ("I never learned the
principle because I never had to") I would know they aren't a fit for my team.

~~~
bigtimeidiot
> _If an engineer gave me your answer ( "I never learned the principle because
> I never had to") I would know they aren't a fit for my team_

So we should learn all the things, ahead of time, just in case we get an
interview question at some point in life?

~~~
jorgemf
As an engineer you should be able to see the global picture and know other
things. Because you wont be able to use something to solve your problem if you
don't know it in advance. I mean, you don't need to know the details, but you
need to know how things works.

For example, you might not need an AVL tree in your daily job, but if one day
you need it to use it, you wont be able to notice if you don't know what is an
AVL tree and what is its advantages over other trees.

Another example, you don't need to know http1 and http2 differences for your
daily work. But if you know them you will change how you do web pages and you
will see a leap in terms of performance and scability. And that knowledge also
includes some knowledge about TCP, UDP, cache and other stuff.

~~~
kafkaesq
_... but if one day you need it to use it, you wont be able to notice if you
don 't know what is an AVL tree and what is its advantages over other trees._

No, what would happen is you'd say to yourself "Hmm, looks like I need a self-
balancing tree. Haven't thought about those in N years..." and do a few
seconds of keyword searching. The idea that people will be utterly helpless on
their jobs without instantaneous photographic recall† of AVL tress (and
A-star, and all the other crap people are bullied into memorizing these days)
just doesn't hold water.

† Which, as we know, is the only level of recall acceptable in the modern
interview process. Even momentarily _hesitating_ in your recall of certain
definitions will easily get you flushed by some interviewers.

~~~
jorgemf
The research you have to do is based on your previous knowledge. The less you
know the more you need to learn when you are facing a problem you don't know
how to solve it. But people is lazy, if they know a way to solve it they will
go that way even if it is the worst way possible.

I am not talking about implementing an AVL tree without any help or resource.
That is simple stupid, we have internet we must use it and save time. My point
is that you need to know that there are balanced trees, know some of them and
they characteristics. That knowledge will save you time when you face problems
related to trees. You are not going to know all the trees because researches
are working on new ones every day, but you should have some knowledge in the
area.

If you interviewer drop you because you hesitate in something, maybe it is the
interviewer problem and not yours. We are not perfect, we should know people
will make mistakes and hesitate. I was rejected of interviews when I hesitate
when they asked something about linked lists. I was happy it happened, because
I was in shock when I was explanning how I did something with and A* algorithm
and a octree and I couldn't believe the next question was about a linked list.
I wouldn't be happy in that company.

------
throwaway2016a
In a way I prefer this to "how many ping pong balls can fit in a school bus"
that was all the rage in the 90s and early 2000s. But... man...

I have a computer science degree, I've been coding for 20 years, and I've held
(and kept) a CTO role at two mid-sized startup companies. Currently I'm
considering looking for a job at a larger company (where I wouldn't be CTO but
I'd be hopefully paid more) and these kind of questions make me think I need
to almost go back to school before I can start interviewing.

When did it get to the point where we need to read thick books on programming
interviews and spend hundreds of hours on HackerRank practicing algorithms to
get a job where we probably won't use any of those day-to-day?

Edit:

For fun the other day I decided to code a linked-list from scratch in C and it
took me a half-hour plus... and I have known that data structure for decades.
I can't imagine doing a harder problem under the pressure of being an
interview.

~~~
dahart
Keep in mind that, because the number of programmers is increasing, the
majority of them are fresh out of school or close to it. Algorithms interviews
are largely designed for interviewing people who don't have much experience,
so they're skewed toward testing what people learned in school.

If after 2 CTO roles you interview for a job and they ask you to write a
linked list algorithm, then would you want to work there? I mean you might,
but that alone should at least beg the question. If they're not asking you how
you'd manage a team of smart but stubborn coders or structure their company's
software architecture and services to be more reliable, then they certainly
aren't paying much attention to you or what your strengths and experience are.
Or they simply don't know how to hire an experienced person, which signals
that they don't know what to do with an experienced person once hired.

Also, it would take the vast majority of great coders at least a half hour to
code a linked-list from scratch in C and get it right, depending on what
you're doing.

So don't worry.

~~~
FLUX-YOU
>Keep in mind that, because the number of programmers is increasing, the
majority of them are fresh out of school or close to it.

But the number of unfilled positions is also increasing, so we are not closing
the gap, right?

So the gap is widening, but the requirements to get a position are also going
up. That just makes no sense to continue for a long period of time.

~~~
dahart
If the number of unfilled positions is increasing, that would tend to lower
the requirements, not raise them. If the number of filled positions is growing
at the same rate as the number of unfilled positions, that would be evidence
that the requirements are staying roughly the same on average. (Except I'm
sure there some small amount of average improvement and widespread knowledge
increase every year that everyone benefits from.)

In any case, it still makes sense for companies to come up with interview
strategies for inexperienced devs, and the article at the top is once such
way. It doesn't mean companies will interview experienced devs the same way,
and in my experience, they don't.

(EDIT I had written some other junk based on me misreading your comment,
apologies if you had to spend any time on that.)

------
digitalsushi
I'm a C+/B- developer. I've been doing this stuff for touching two decades,
and these questions gave me a prickly sweat down my back. There is a part of
me that feels very lucky to have plopped onto the Earth right when I did,
before there was an organized process to weed me out. I'm entrenched enough
that interviews are generally just culture fit interviews. I think I'd need
ulcer medicine to get a job with no reputation.

~~~
JamesMcMinn
How often have you had to code up solutions to any of these challenges in the
last two decades?

These sort of challenges are great for learning some of the theory behind
computer science and getting you thinking, but they're not a useful part of
the interview process imo.

~~~
collyw
Exactly. I am pretty sure there is a (well tested) library out there to do
those things.

~~~
canttestthis
At some jobs we make the libraries you use to solve those problems. These
interview questions test very basic CS concepts and many of them are
essentially just extremely watered down versions of real life problems. I can
teach a dev how to Google for libraries, I can't teach him basic CS concepts.
I would much rather hire for the latter.

In fact this whole thread makes me uncomfortable. I wouldn't want to work with
anyone who gets nervous when told to reverse a linked list.

~~~
collyw
Sure, but those jobs are few and far between. If you are indeed writing that
sort of code, then it makes complete sense to test people on that, but the
vast majority of jobs using this style of testing are not.

~~~
canttestthis
Even for other jobs, using this style of interviews reduces your false-
positive rate, because any style of interviewing thats good enough for the
sort of software that this tests for is going to be good enough for them.

------
sparkling
Semi off-topic, but i am curious. How much of CS fundamentals do you expect a
backend (or fullstack) developer to recite in an job interview? I did all CS
theory stuff many years ago at university, but i could not pass a interview
test full with these CS basics.

Isn't it far more important to know how to design a modern, maintainable,
scalable web application? Know how an when to cache stuff. How to design a
API. How to integrate with third party APIs. How to setup logging. How to
sanitize data and other common security problems. How to setup
test/build/deploy structures. Et cetera, you get the point.

If, while building a web application, i encounter a "big data"/"data
processing" problem, i will find a appropriate solution using CS best
practices. But hell, i would struggle to implement a simple array sorting
algorithm under pressure.

~~~
numbsafari
> Isn't it far more important to know how to design a modern, maintainable,
> scalable web application? Know how an when to cache stuff. How to design a
> API.

How do you do that without some basic understanding of computer science-y
stuff?

How do you define "scalable", how do you measure it? How can you have some
intuition about a design before we spend 3 months and many sprints building it
first?

How do I know when to cache stuff? Does it matter if I have calls to a remote
cache in a tight loop? Should I be using an in-process, out-of-process, or
remote cache for a particular piece of data?

Here's one that comes up A LOT with junior and mid-level developers: floating
point numbers aren't magically precise things.

There's a balance here, somewhere. I personally would never use the trivia
questions in the OP. But the idea that you don't need to know even basic
computer science-y type things, seems crazy to me.

I can't see myself hiring a computer programmer who is offended by being
expected to have a casual acquaintance with computer science.

~~~
hack_edu
> How do you do that without some basic understanding of computer science-y
> stuff?

> How do you define "scalable", how do you measure it? How can you have some
> intuition about a design before we spend 3 months and many sprints building
> it first?

> How do I know when to cache stuff? Does it matter if I have calls to a
> remote cache in a tight loop? Should I be using an in-process, out-of-
> process, or remote cache for a particular piece of data?

You're proving the above poster's exact point. You are putting your weight in
applied questions that rest upon the developer's specific experience. This
method is the opposite of evaluating people for their ability to memorize a
half dozen algorithms and data structures.

In my experience interviewing candidates, asking people to implement a caching
algorithm is a distraction to both parties. A much better evaluation is their
ability to provide box-arrow diagram and talk it through. This is much more
effective towards understanding their thought processes and knowledge. It is
also much, much closer to the _real_ day to day of a today's engineer:
communication, advocacy, and breadth of knowledge. Code is cheap. Business
should screen employees for an interest.

CS textbook questions introduce enormous amounts of bias, especially in panel
interviews. It is a dangerous trap that companies use to further entrench
their team cliquiness and departmental monoculture. It is ripe for Simple
Sabotage. Simply put, its lazy.

------
Apocryphon
Never mind the specifics of the selection process, Silicon Valley's risk-
adverse approach to hiring is baffling. Instead of making candidates go
through an overly rigorous process, why not embrace California's at-will
status and hire and fire often? Employers and employees already view each
other with suspicion in terms of loyalty, the former willing to downsize
capriciously at any moment, and the latter willing to jump ship every year or
two. So accept the mobility and instability of startups. Instead of spending
immense resources on the interview process to find the perfect, you focus on
getting the good and terminate swiftly if they turn out to be bad.

Not to mention, even when you have these types of interviews it still doesn't
seem to filter out toxic people, such as the harassers of Susan Fowler at
Uber.

Of course, it would be easier for workers to be okay with this arrangement if
basic needs such as health insurance were decoupled from one's employer.
That's another argument for single-payer in CA.

~~~
enraged_camel
>>Never mind the specifics of the selection process, Silicon Valley's risk-
adverse approach to hiring is baffling.

I think it makes perfect sense. A bad developer hire is not just unproductive.
They also tend to be a burden on their coworkers and reduce _their_
productivity by asking trivial questions and writing buggy and/or hard to
maintain code.

With startups the risk is even greater. Think about it: the odds are already
stacked against you. Why would you take even _more_ risk by randomly hiring
developers? Sure, you can fire them, but by then it may be too late.

~~~
Apocryphon
I've read that rationale, and it makes sense, but it almost makes it sound
like the organization is humoring a bad dev without oversight for months upon
months until they suddenly realize their inability. Maybe they should spend
more time actually running their company instead of interviewing candidates
all day.

------
nickpeterson
"Before we hire you, we first need you to outwit this burmese python..."

~~~
riebschlager
I'd rather take my chances with a snake than trying to solve "Add two integers
without using + or -".

~~~
brianwawok
sum([5,6]) ?

~~~
tedmiston
The sum built-in is still using the addition operator with syntactic sugar
though (as is the other child comment). I think the intent of this question is
to solve it with bitwise operators ie, [1].

[1]: [http://stackoverflow.com/questions/17342042/why-this-code-
fo...](http://stackoverflow.com/questions/17342042/why-this-code-for-
additionusing-bitwise-operation-works-in-java)

~~~
jacquesm
If you're going to have to argue about the 'intent of the question' then
you've already lost.

Really, the question should be 'add these two integers' and any solution that
produces the result in a transparent and straightforward way should be honored
with top marks.

Trick questions, especially those where only the interviewers pet solution is
permitted are a sure sign that this employer is best avoided because they care
about form and ego more than they care about getting the bloody job done.

------
kclay
I recently tried for the second time to apply to some agency type place. I
have 10yrs of coding, worked with big data, have done micro coding( developed
protocols for vending machine transactions), done frontend and backend small
and large scale.

But this place had 3 of these type of challenges that you had 1hr 30mins to
complete all of them. I'm sorry, most of this stuff you will NOT find in any
job unless its some specialty. For an backend/angular/react developer you will
not find this at all. I feel that companies that do this are out of touch with
the correct way to find candidates. But on the second hand I also see why they
do this since programming has became so much popular now a days.

~~~
ethbro
In the same way that nobody ever got fired for suggesting IBM, I imagine
there's a lot of HR / tech hiring apeing MS/Google/FB. Even if it makes no
sense in their business development context.

------
bigmanwalter
I don't understand code challenges. Can you even program without Google and
Stack Overflow anymore? And god-forbid being experienced in a dozen frameworks
and libraries if it's not the exact combination the company uses.

~~~
problems
Yes, you're expected to be able to write basic stuff like most of these
challenges without Google or StackOverflow.

There are some however here that you really shouldn't be, like remembering
specific algorithms - if you're just memorizing 20 different sorting
algorithm's exactly implementation, clearly that's not producing much if any
value for you.

If someone however was to give you this Algorithm section
[https://nbviewer.jupyter.org/github/donnemartin/interactive-...](https://nbviewer.jupyter.org/github/donnemartin/interactive-
coding-
challenges/blob/master/sorting_searching/merge_sort/merge_sort_solution.ipynb#Algorithm)
and tell you to implement it, that would prove whether you had the skills
needed to properly use Google and StackOverflow for anything but a direct
copy+paste and could be a very good test for a programmer.

Basic data structures, knowing when to apply them and how to solve fairly
straightforward challenges like "does this string contain any duplicate
characters" when you have full use of Python's builtin data structures are
completely fair interview questions in my opinion.

Just picking 1 or 2 of these questions that seems vaguely related to your work
is enough, combined with asking some basic technical stuff like "What's the
difference between a class and an object?" can weed out a shocking number of
people, showing they don't even have conversationally useful knowledge about a
topic.

~~~
jacquesm
I've been coding for _4_ decades. There are so many different standard
libraries and function calls to remember that only the people that are one-
trick ponies (one ecosystem, deep knowledge) are going to be able to do the
majority of these without an outside reference.

And those are exactly the people you would not want for a job because they
would most likely not have the flexibility to shift away from that ecosystem
if there was a need because it would take them forever to get up to speed.

It's _much_ better to know how to use outside references efficiently and to be
able to 'swap stacks' in a couple of weeks than it is to be an expert in some
language that could very well be obsolete, and that's assuming that there are
many jobs left today where deep knowledge of only _one_ ecosystem will get the
job done.

The time when you could spend 4 years learning a specific library and language
and then make a career out of that is long long gone. What we have today is
more akin to enormous libraries sitting on fairly rickety narrow foundations
where - if you're lucky - the documentation of that library is relatively
good, and the half-life of the whole thing is measured in months, a year at
best. Today you work in Python, 3 months from now in Go and a another 6 months
after that it will be JavaScript, typescript, clojurescript, coffeescript or
<insert your flavor here>.

So, you want to have your problem programmed in Assembler, C, C++, Python,
PHP, BASIC (name your dialect), JavaScript, Erlang, Python or I don't care how
many other languages that you care to name I'll accept the challenge. But I
won't cut off my external memory bank in order to prove that that is something
I can do.

(Well, truth be told I probably _can_ do it in a couple of the above but
that's mostly because there was a time when the world moved slow enough that
you could actually invest a couple of years, but these days it is much better
to know how to leverage open source and google than it is to know the gritty
little bits of whatever language is in flavor this week.)

Of course, if you are looking for 'javascript programmers' it is fair to ask
some questions about javascript. But in my experience it is a lot more
efficient to search for programming talent and good debugging and writing
skills irrespective of what language they are currently trained in.

Languages are a means to an end, programming is the skill you want, not 'a
particular language programmer'.

~~~
pnw_hazor
Though the code challenge hazing makes it easier to screen out "old dudes" who
are not using the latest and greatest.

~~~
jacquesm
Yes, _please_ let's not hire someone with experience. That would really ruin
the party. /s

------
optimuspaul
I have always seen the interview process as a an opportunity to understand how
the other person thinks. These questions may do that to some extent but they
limit it in ways that make it almost mechanical.

I personally find "What is your favorite programming language?" or "What
systems architecture to you find more compelling?" to be far more valuable. It
gives some insight into their commitment to the trade and gives you an
opportunity to make it a conversation to dive into their reasoning process and
depth of knowledge about a topic. I think it's far easier to weed out the
fakers if they can't express why Erlang is interesting to them than for them
to tell you how to implement a linked list which is very easy to google and
memorize(but won't necessarily prove any skill).

------
TuringNYC
From what hear about some startups, the challenges are for the general
candidate pipelines the company wants to weed out w/o fearing legal
repercussions. The inside-track, friends, and frat candidates often get to
skip right through the process or have copies of the problems/answers from
insiders. (Illusion of merit.)

~~~
tedmiston
I think this view is a little bit cynical. Hiring your friends which usually
happens in the early stages is often more about having worked with them before
or having them come in based on a recommendation / knowing they're a culture
fit ahead of time etc. It's a way for small startups to spend less time on
hiring, and increase their chances of getting talent that they couldn't
necessarily attract on the broader market in the early stages.

~~~
TuringNYC
I appreciate the feedback and you raise good points. However, i'm curious what
purpose many of these exams serve...some guesses:

\- Because it is actually a good predictor of job success (does anyone think
this is the case for anything but a handful of job roles?)

\- To be adding a hurdle to target those who really want the job (downside: it
also adds a hurdle to top-notch gainfully employed people who dont have time
to study for such exams)

\- Another is they just need something to reduce an otherwise overqualified
pool of already qualified candidates (fair point, but at the risk of losing
out candidates from concern one above.)

\- Legal risk mitigation -- add a quantitative measure to show a facade of
merit and process.

TBH, I have never been on the hiring side at a small firm, so I don't know.
But I have seen several things:

1\. People recruiting me to Amazon and practically giving me the exam
questions (I declined mostly due to location) Same thing at two other firms
(perhaps to get referral bonuses?)

2\. An H1B process that is by-the-book correct yet entirely against the spirit
of the program.

3\. Tons of interviews, screenings, etc at big firms just to justify an
already-decided inside candidate. This I witnessed firsthand and makes me
really upset because of all the candidate time they waste and the false hope
they give to people who were never in the running to being with.

------
falcolas
Somewhat of a tangent, but that "Distributed design" document gives me hives -
with the lack of lines from "write" or "async write" back to the readers or
cache. The taming of stale data would be a nightmare to manage when it
suddenly starts to matter.

Also, where's the completed response caching layer? Nothing destroys
performance (and hikes costs) like having to recompute every page response
from raw data.

And that doesn't even touch my annoyance at shoehorning "federated
architecture" to mean "sharding with a different algorithm".

------
gigatexal
The advent of all of these coding challenge excercises makes not being able to
do one in an interview a real show stopper. Glad there's all this material to
learn from.

~~~
JamesMcMinn
Not really. If anything it just makes coding challenges useless for
distinguishing between people who can think, and people who can regurgitate.

It's one thing to "know" how to balance a binary tree because you've read up
on and practiced the most common challenges - it's something else entirely to
actually think through and understand a problem, then come up with a solution.

I'd much rather have someone who can describe the edge cases and the
complexity of a problem but get the final solution slightly wrong (but hey,
the know the edge cases so can write tests for it, right?), than someone who
can regurgitate code they've written before without really understanding it.

~~~
gigatexal
Sure I agree as well. That there are so many resources and tools available to
answer these coding challenges that if for whatever reason such a challenge
was presented the minimum is to be able to answer thr challenge. Going beyond
would be to know when to use such a data structure or its inherent strengths
and weaknesses etc.

~~~
bigmanwalter
Unless someone can't study these things because they're too busy writing real-
world code.

~~~
gigatexal
Which is why I think companies doing less whiteboard interviews and more real
world coding tests make more sense. I think one could understand the
limitations of a linked list and still use the built in data structures and be
really competent.

------
tekkk
To me it is reasonable to presume that a software developer candidate knows
the basics of CS: algorithms, data structures and such but for anything that
require deeper knowledge I think it should be only asked if it is mandatory
for the job.

Sure if you want to maintain a certain "prestige" you should maybe use them to
limit your applicant pool but in the end if your work is nothing but coding
front-end JavaScript it doesn’t matter do you know how to traverse B-trees or
not. And if a need somehow arises it is very easily googleable and
implementable with good enough CS education.

I think what the interviews should be about, and the best that I have been,
have involved some basics sure but also one had few “real-life” coding
exercises and in another I had a code review about one of my project’s code
(which I was surprised by). Nothing tells more about a person than having them
to explain what is their passion but if you are only interested in people that
can jump through some loops that’s the people you are going get. Maybe in that
kind of company that's just how they do things.

I’d argue most people can intuitively tell, maybe not why, when a recruitment
process feels “right” compared to one that is forced and does nothing but
dehumanize you to a walking Wikipedia and ticket-monkey. But maybe in
programmers there is also some that seem to like that idea so I’d say it is
more of a skill and culture fit than anything else.

But in any case the whole process should be based on some structure that
actually measures something real. I personally don’t like being reduced to few
facts about missing knowledge on a spreadsheet which I could learn in a week
or so. It hurts my ego and most of all makes not want to work in the said
company in the future so when I’d know those things I won’t be reapplying.

------
jorgemf
With this type of post I always read comments complaining why they should know
those things for an interview. They are not necessary. It is like some more
knowledge is going to harm them. I wish I would know more about everything.
Sometimes the connection between knowledge and how to solve a problem are not
clear when you learn that knowledge. Why is it important to know how is the
syntactic structure of a sentence if I want to be a developer? Because you
might end working with compilers or natural language processing and that
knowledge is gold. But you simple don't know in advance, and you wont be able
to discover how to solve a problem if you don't have knowledge about the
solution in advance. And there are also different ways of solving problem,
some better than other or with different trade offs which you only know if you
are aware of other possible solutions.

~~~
meheleventyone
I don't think most people are complaining about gaining knowledge but the
relevance of the test to job performance or the requirement to study whilst
working and raising a family.

"... you wont be able to discover how to solve a problem if you don't have
knowledge about the solution in advance."

Is simply false, whilst research is a skill all of its own it's most
definitely possible to go off and learn key techniques when you need too.
Relying on serendipity for knowledge to be useful is not very efficient after
all.

At best the additional knowledge gained is a helpful side-effect.

~~~
jorgemf
It is not false, for example Albert Einstein was developing his Theory and he
could do it because he was in a research ground where they were doing research
about infinitesimal calculus, which was handy for Einstein to apply to his
theory. But I think it wouldn't be clear to apply infinitesimal calculus to
his theory if he didn't know it in advance. Or at least, we aware of it and
its possibilities.

When you face a new problem, you just don't know how to find a solution, you
based your hypothesis in the knowledge you already have. You can do research,
but the more knowledge you have the less research you will do. And that time
you save is money the company saves.

Anyway, you decide what to do with your life. If you are happier raising a
family that is good. If you are happy learning stuff to apply to better jobs,
that is good too. But obviously you cannot have everything because time is
finite.

~~~
meheleventyone
A good job and a good family life are eminently achievable goals in tandem. I
personally spend my time out of work learning things outside my field just for
the fun of it.

~~~
jorgemf
If you are happy with what you have that is even better. But some people wants
to earn millions of $$ a year and be married with a Top model. If they don't
have both, then it is not good enough for them. And a lot of people just want
something better regardless what they have (forever unhappy people).

------
daenz
Thanks for this. Just a mild constructive criticism: not sure how useful the
Anki deck is. One thing to keep in mind when constructing cards is keeping the
information very short. As it stands, there's no way to really remember the
flip side of the card. Aside from that, really solid info!

------
prashnts
I've been using Python (among others) at work close to 3 years now. I get
these challenges and problems, however, I don't find the solutions here
"pythonic". I guess it depends upon the job criteria, but the code here [1],
for example, is not a great demonstration of _Python_ language skills. It is a
good demonstration that the person knows Mathematics, but if someone is
interviewing for a Python dev, it's not what they should be looking for.

[1]
[https://nbviewer.jupyter.org/github/donnemartin/interactive-...](https://nbviewer.jupyter.org/github/donnemartin/interactive-
coding-
challenges/blob/master/online_judges/license_key/format_license_key_solution.ipynb#Code)

~~~
danielvinson
That was my reaction also. If a junior engineer asked me to review that code,
I would ask them to refactor in a way that is more maintainable.

------
mattfrommars
Might be slight off topic. But I'm sort of Python enthusiast for a long time
but never been able to actually learn how to code. I'm sort of aspiring
software developer but a degree in irrelevant engineering.

My question is, by studying/doing good amount of Python [currently working on
it], going through the entire interview challenges presented here, seeking to
gain Master degree in Management Information System [MIS], can I apply for job
and be shortlisted which might require CS graduate and maybe graduate with MS
in CS?

Let's just say for the sake of the comment, I won't be able to obtain a MS in
CS because for numerous reasons.

~~~
willchen
It's possible. I got a job as a software engineer at Google despite having a
degree in Economics and only knowing Javascript. I spent a lot of time
studying data structures & algorithms on my own but it's do-able.

------
dragnot
The problem is how much do dev really need to use this in real code. why would
interviewer test someone on function he can just use existing lib for. why not
think about how he plan an application and how will he design a flow. much
more important.

------
southphillyman
I really appreciate the effort that went in to this. This is a perhaps the
most thorough hand holding through a "Cracking the Code Interview" regimen
I've seen thus far.

------
throwawayhey
Has anyone taken Outco or Interview Kickstart to pass these kind of questions?
Which class is better?

------
didip
These questions aren't that bad. There's even architecture design questions
(under System Design).

Looks like a fun bedtime reading material to me.

I'd say read this kind of stuff on regular days, not one night before
interviewing, and peeps would do just fine.

------
michaelchisari
Why do we test algorithms and not design patterns?

It seems to me, after twenty years of building software, that the need for
off-hand knowledge advanced algorithms is rare, and the need for knowledge of
design patterns is exceedingly common.

------
agentultra
This is great! Having an integrated environment with the tests included and
solutions in a separate notebook is quite valuable for training to pass
technical interviews.

I see a lot of people posting about how they dislike the technical
interviewing process. The sentiment seems to be that for a certain class of
popular developer role it's entirely unlikely that they will ever need to
remember how to implement a heap or red-black tree to be effective at their
job... so why use problems like this in an interview?

I think these sorts of questions should be used by teams that want to set the
minimum standards on the team. I'm reminded of a rule used at the Recurse
Centre: _never feign surprise when someone asks a question_ (I paraphrase).
The idea is that if someone asks you a question about something you think is
fundamental, like Bash for example, don't immediately feign surprise and say,
"You don't know bash?" It's not helpful. Instead take it as an opportunity to
teach them something awesome. However this doesn't generally work in a
professional setting where you're _required_ to know Bash in order to function
at your job.

If on my team we're responsible for the operation and maintenance of several
millions of dollars worth of infrastructure that runs our customers'
applications then there are certain minimum requirements for operating
effectively within this team. I expect you would know Bash at a minimum. I
should also expect you to know the network stack of the OS we deploy on, how
TCP works, what a hypervisor is, etc. We may write most of _our_ application
code in a high-level language that abstracts these details away but that
doesn't preclude you from understanding them. It's just a convenient tool. You
have to know how to manage complexity and avoid premature pessimization in
order to be effective and that means you will be interviewed using technical
questions to screen for that _minimum_ level of knowledge.

However I think most companies do tend to use this tool poorly. I've
interviewed with startups that build consumer web applications that ask
questions about radix sort and k-d trees. That's what I call, _overkill_. This
trap is easy to fall into if your motto is something glib and banal like, "We
only hire the best." If you don't quantify what "best" is you're just going to
negatively filter out potential candidates and hire on bias. You have to scale
the screening process to only test for that minimum competency and choose how
much risk you want to take in teaching new hires.

If I'm hiring a more junior developer to our team I expect that we're going to
mentor that person and make them a better engineer by working with us. They
can ask questions that may be outside of our minimum standard. However if I'm
hiring for a team-lead position I'm much more likely to not accept a candidate
who cannot fly through our screening process. Working with them is going to be
difficult and if it's 3 in the morning and they're causing more problems than
fixing because they don't know how the TCP re-transmission protocol works then
we're going to have a problem.

The conclusion of all this is: tweak the screening process to set the minimum
standards required for effective communication on the team. Don't set the bar
unnecessarily high: define what the bar should be and assess the risk of
mentoring junior developers. You need a good mix across the spectrum for an
effective team.

------
swalsh
This feels like hiring a new rough framer by asking him to carve a cabriole
leg.

------
iamspoilt
Thank you for this! Cheers!

------
v3gas
Thanks!

------
dec0dedab0de
looking at code that re-implements features of the language is annoying
enough, but having it be so non-pythonic is just painful.

------
RodericDay
This feels way over-engineered. I just want to click and jump into a
challenge, Project Euler stye. Every single page is overflowing with "Table of
Contents", screenshots, code snippets, etc.

