

Ask HN: I cannot do competitive programming or solve puzzles, would you hire me? - MrDHat

I have decent experience working on open source projects[1] (Firefox OS, bower, yeoman etc). I was a Google Summer of Code student this year with Mozilla.Apart from this, I can program in 3-4 languages with ability to learn anything that is required for the job.Also, worked on some projects at my leisure.
However, I cannot solve competitive programming or puzzle problems. Is it possible to pull off a good software engineering job?
[1] http:&#x2F;&#x2F;github.com&#x2F;MrDHat
======
ColinWright
Speaking hypothetically, you claim you can learn anything that is required for
the job. What if the ability to solve problems under time pressure is part of
what the job requires?

Flipping that over, why do you say you can't solve puzzle problems? How many
have you tried?

And why are you asking? I'm sure that if the answer is "yes" then you'll puff
out your cheeks, heave a sigh of relief, and not bother to work on that aspect
of your abilities.

But if the answer is "no", how will it change your behavior? What will you do
differently?

And why not do that anyway?

~~~
shubhamjain
Well my observation is that programming puzzles that are top in the difficulty
tree often typically involve trees, graphs, queues, or bit manipulation and in
my experience, they aren't usually encountered in programmer's average life.
As it is not easy to get them right the first time for an intense
visualization exercise they involve, preople often find them lost and give up
their hands.

~~~
mcintyre1994
I'm a student so please don't think I'm trying to be above you here, but could
you clarify this a bit? Maybe I'm getting suckered into the academia way, but
I find it hard to believe most programmers will never need trees, graphs or
queues?

~~~
SamReidHughes
Most people aren't equipped to use trees, graphs, or queues so they don't use
them. (Well, that's not so true of queues...) Meanwhile it is true that a ton
of the interesting things done involves trees and graphs of some sort or
another.

~~~
eshvk
The problem is that abstractions are leaky. E.g. when I first started learning
C++ in high school, I didn't know a tree if it bit me. But, the STL has a set
implementation. If you take a closer look at the docs, you will find out that
it is implemented as a red-black tree. I am not sure the assertion that you
will never come across a tree or a graph in your life will be true always.

~~~
SamReidHughes
There's nothing that says std::map has to be implemented as a red-black tree.
And using an abstract data type that's implemented with a tree is not the same
thing as making your own tree for your own purposes.

~~~
eshvk
> There's nothing that says std::map has to be implemented as a red-black
> tree.

Of course not, but understanding what that means is key to using it. If you
think a red black tree is some arcane bullshit that you never are going to
use, you will probably skip over it when you read the docs and get bitten.

~~~
SamReidHughes
> Of course not, but understanding what that means is key to using it.

Not at all. A user could think it's a hash table and they'd still be likely to
maximize the potential utility of the type in their application. They could
understand that it's implemented with a balanced search tree without knowing
about the details of the balancing algorithm and that's pretty much the
maximum utility right there. (In fact it's a good mnemonic for understanding
almost all the performance and iterator guarantees of a std::map's functions.)

And you're not going to find that it's implemented as a red black tree in "the
docs". You generally don't know that. All you know and all you'll see
documented is the performance requirements and iterator invalidation behavior
of various functions. I mean look at the docs. That's what's there.

The real benefit of being comfortable with trees and graphs is so that you're
comfortable with actually using trees and graphs yourself, directly, when
they'd be useful to manipulate. If you want to look at a commit log, well,
that's a graph, and I guess you can't work with that if you claim that graphs
are weird obscure stuff and cringe at the word "acyclic". Want to use a
filesystem? Apparently that's a hard thing for some people, sadly enough
because it's a tree (or graph, depending on your attitude about soft and hard
links). That's where you're writing code that manipulates the actual data
structure, instead of just using some lookup-table interface.

~~~
eshvk
> The real benefit of being comfortable with trees and graphs is so that
> you're comfortable with actually using trees and graphs yourself, directly,
> when they'd be useful to manipulate. If you want to look at a commit log,
> well, that's a graph, and I guess you can't work with that if you claim that
> graphs are weird obscure stuff and cringe at the word "acyclic". Want to use
> a filesystem? Apparently that's a hard thing for some people, sadly enough
> because it's a tree (or graph, depending on your attitude about soft and
> hard links). That's where you're writing code that manipulates the actual
> data structure, instead of just using some lookup-table interface.

I am not clear how you are disagreeing with me here. :) Surely manipulating
commit logs, understanding say how Git works, squashing commits, rebasing,
manipulating access to the file system, surely, these are things that are not
out of the realm of being asked to do. Hell, if you are dealing with a
freaking linked list at some point or not in your career, you are dealing with
a DAG.

------
kstenerud
I've never programmed competitively, nor have I ever solved a programming
puzzle. Quite honestly, I don't see the point of it.

Programming is not a competitive process; it is cooperative. Some of your
greatest resources are the people around you. Even after 15 years in the
industry, I'll still ask questions of my coworkers at least once every couple
of days.

A puzzle is something designed by another person, with the specific intention
of tricking you. That's not quite the same thing as a real-world stumper
problem, although there can be some similarities. And once again, the times
when you're stumped are precisely the times when you want to talk to your
coworkers about it. Often the very act of explaining the problem to someone
else is enough to give you the solution! Sitting there on your own, banging
your head on the keyboard is the stupid way to do it.

The most important thing when it comes to debugging is to understand how
things work at least one level below where you're working at (such as
understanding how the library calls in the language you use translate to
system calls, or being able to dissect HTTP requests/responses, or even TCP/IP
frames, or if you're programming in C for example, understanding how the
compiler works, how it optimizes, where the edge cases are, or even knowing
some assembly language so that you can look at a stack dump and figure out
what the computer actually did vs what you thought you told it to do). I
dislike puzzles for the same reason I dislike trick questions on exams.
They're not designed to test your knowledge or ability; they're designed to
see if you can find the needle they've oh-so-cleverly hidden in a haystack.
That sort of thing is fine if it's for your own amusement (people do, after
all, enjoy crossword puzzles), but as hiring criteria I find them misguided at
best.

Learn new things from time to time, but focus on what you're passionate about.
You'll gain deep knowledge and you'll have the motivation to solve whatever
problems crop up.

~~~
SamReidHughes
Programming "puzzles" in interviews are not made with the intention of
tricking you. They aren't designed to make you find some metaphorical needle
in a haystack, either. They're designed to be easy problems with clear avenues
or multiple avenues of attack to solve. And people asking them are well aware
that applicants sometimes get stuck, which is why they ask multiple questions
(unless applicants get stuck on the easy warm-up question).

------
Bahamut
I think it's more than possible to get a good software engineering job - I
have not had to do any competitive programming or puzzle problems to get a
job, although I have a history of being competitive in mathematics in high
school (which I generally keep secret, along with many of my accomplishments).
Actually, I don't even have a computer science background or even took a
programming class (excepting in high school almost 15 years ago, where the
teacher was a consultant who didn't even know programming).

I don't even think those who have experience doing those things are even a
good barometer of whether they would be good coders, or do well in software
engineering. They may certainly do well, but I think that companies that look
to hire those who can do those are looking for people of a certain mental
makeup - some of these companies may arguably be using the wrong criteria for
hiring.

Your GitHub would make me curious if my company was looking to hire & probably
would be enough to get an interview, but knowing how to talk about tech would
be important. Since this is all hypotheticals, I wouldn't be able to make a
positive determination without an interview, which would be the clincher.

Also I see that your GH page lists that you're from India? Many companies may
find it difficult bringing on a candidate from overseas (HN's audience is
predominantly US), although with the right company, remote work would be
possible - however, remote work is probably difficult to pull off unless the
company is absolutely confident in you as it is.

~~~
MrDHat
> Also I see that your GH page lists that you're from India? Many companies
> may find it difficult bringing on a candidate from overseas (HN's audience
> is predominantly US), although with the right company, remote work would be
> possible - however, remote work is probably difficult to pull off unless the
> company is absolutely confident in you as it is.

I am not a fan of remote work either. However, I am willing (in fact want to)
to relocate if I am satisfied with the profile offered!

P.S. This post was supposed to be a reality check for me(and others like me)
and not a shameless plug for getting a job :-)

------
rttlesnke
Absolutely!

Competitive programming is highly focused on algorithms, data structures,
optimization and your ability to come up with a solution fast. To excel in it,
it may take months, or even years of practice. I've actually never met anyone
yet who does really well in these contests, and they still do have good jobs.

Competitive programming can really help you gain expertise in these areas -
far more than a typical programmer. But these areas are just a subset of
software engineering - there's a _lot_ more to it. Of course it's great
knowing it all, but for many programmers this kind of thorough knowledge isn't
required.

But if you wanna build new, awesome stuff from scratch (something like Redis,
Git or Nginx) or you're working on a system which needs to be efficient, those
skills really come in handy.

Lastly, I see you're a GSoC student who has worked with Mozilla - you're
probably good enough, if not great!

Read this:
[https://news.ycombinator.com/item?id=6823682](https://news.ycombinator.com/item?id=6823682)

------
Sindrome
It depends on what you mean by a "good" job. Can you get a job @
Google/FB/Twitter/etc. Probably not. But to be honest, as an entry lvl
engineer without an Ivy League degree you'll have trouble getting an
interview.

If you just want a job where you can build cool things and make 80k+ just out
of school. That's definitely possible. There are a lot more companies out
there that just want to get shit done and shipped versus ones that wan't to
nitpick over 100ms of performance.

As you advance your career, you can spend time learning to do obscure data
structure manipulation in C. So you can go for that job @ Google. Who knows,
maybe you will discover being an engineer gets boring by working for a smaller
company where you get to interface with clients, stakeholders, etc.

------
MrDHat
While researching on this topic, I stumbled upon this post:
[http://hueniverse.com/2013/02/hiring-engineers-a-
process/](http://hueniverse.com/2013/02/hiring-engineers-a-process/)

The point of 'Homework' really intrigues me. It actually ensures that a
candidate has the skills to contribute to your product. IMO, it is a far
better way to judge than programming puzzles.

------
dreamdu5t
Don't worry. Just don't play the puzzle geeks' stupid game and work for
someone else. You can find a job without solving code puzzles.

