Ask HN: I cannot do competitive programming or solve puzzles, would you hire me?
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://github.com/MrDHat
23 comments
[ 2.8 ms ] story [ 62.2 ms ] threadFlipping 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?
Some people believe that how web development is a cakewalk, in comparison. While it might be true to a certain extent since developers are cut off from challenges at lower level but there are difficulties that can take toll on you, trying to work with huge interactive JS application is no piece of cake, for instance.
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.
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.
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.
Frankly speaking, they do not interest me.I would rather collaborate with friends and work on a project than solve competitive problems or puzzles.
1. How is a small team of programmers to know that you will be able to collaborate with them effectively within the space of an interview ?
2. What exactly do you mean by "competitive problems" or "puzzles"? What is off-limits?
I am asking 2. to identify what you mean by a puzzle. For example, let me take the substring matching problem. There are a ton of ways of doing those which for me traverse the realm of being both puzzles and also in some ways important computer science questions [1]. You could do brute force. You could have a moving hash window and use that to check if the substring is present. (Sort of Rabin Karp). You could build a trie called a suffix tree. Now the way intuition works (at least for me) is that you either know how to solve it, and then you sort of recollect the details in a few minutes. Or you have no idea of how to do it and probably don't know how to create a solution like that unless it was super critical that you go figure this out. And the problem is that the real world never throws things straightforward at you. Curveballs at least in the engineering world require transforming previous solutions into something new. So unless you grok trees, how will I know if you really will be able to spot that a random problem is just a tree problem with some modifications and then go ahead and implement it, instead of say spending a few weeks refreshing graphs.
[1] http://cstheory.stackexchange.com/questions/19759/core-algor...
Isn't my github profile enough proof to show that I can collaborate with people? Also, as I pointed out in my recent comment: Eran Hammer, (creator of OAuth and Hawk) presents a new way to hire engineers. He suggests the concept of a 'Homework' wherein prospective employees are presented with a problem/bug that they are actually facing in their product. One of my acquaintance from Mozilla also pointed out that he was hired in a similar way.
> 2. What exactly do you mean by "competitive problems" or "puzzles"? What is off-limits?
For me, competitive problems are the kind problems for which interviewstreet/codechef etc are known for. At times, they involve the kind of problems which a developer is not likely to face during his time at the company. For example, being a web developer, I don't think that there will be a time when I need to write a string matching program from scratch. Wouldn't questions related to scalability/databases/some selected data structures make more sense for such a profile?
Don't take me wrong, I am not against questions involving string matching/sorting/kernel concepts, all I am saying is that they should be asked from those who are really going to face such problems while working.
[1] https://news.ycombinator.com/item?id=6828411
It doesn't show if you can collaborate with these people. Which is one of the things that I look for when I interview folks or interview at companies.
> For me, ... while working.
So I have this opinion that most jobs don't require even a C.S. degree or even knowing more about programming than cobbling together a few libraries and getting something out. Now, most companies don't agree. You said you learn fast right? This is a lesson you should start learning then. Most companies look for some mythical beast called a "10x" developer. They have no idea how they can solve it. Sure, they can test you on the problems they are working on right now. However, they have no idea what problems they may face in the future. So they test you on a bunch of random "hard shit". You jump enough hoops, you get hired.
/cynic
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.
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.
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 :-)
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
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.
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.