I don't know. I like getting close to code, because I like thinking about the people that make each symbol, establish a meaning, weave that into a language, where it is either contextually derived or explicated clearly. I like watching those things change and I like figuring out why some things stay the same. I like selecting words for new concepts, which I am never really sure of whether these things are arbitrary. When I zoom out and generalize enough, everything shares the same fuzziness, these symbols are all puzzle pieces. But when I zoom in, each puzzle piece is the puzzle itself.
I grew up enjoying puzzles, logic puzzles, logic books, math books, piece puzzles, riddles, and all the supposedly clever things to that affect. The more involved I become in the world of programming though, I can't really say.
I have the time to study the complex math and computer science theory sometimes, on the weekend, for fun, and then the code I read through ranges from deeply personalized learning to clear, uniform specifications developed over time periods I have no actual experience understanding what goes on during those time periods. I know the importance behind many theories, and I understand how to apply these things. But I don't know why or how it grew.
If you want to see a puzzle pattern in code, you will see puzzles everywhere. You can see anything you want to in code, just like every other human creation. Make your own meaning and what not. Code is more art to me than 'Art' is.
Google and Facebook long ago stopped asking (or at least now they discourage their interviewers from asking) puzzle-like questions in their SWE interviews.
That's true. I think the OP is talking about puzzles in the more general sense (e.g. designing novel algorithms). It seems to me that it takes a specific type of mental state to enjoy theoretical CS and math, since much of your time there is spent banging your head against things until everything clicks into place.
...and which seem to largely be collected in the book Cracking the Coding Interview [1]. If you can answer all of their sample questions, you should do fine at a Google interview -- once your brain is used to the task of solving small algorithmic problems, it should get easier, even if the precise question they ask isn't in that book.
Easy for me to say, since I find problems like those easy; I cranked through a few dozen of them with only having to really think about a couple.
If you can't answer them all yet...well, now you have something specific to study.
Puzzles are a terrifically poor way of judging whether a candidate will be good at performing the most common form of programming there is: solving meaningful problems, often business or interface ones, in a simple and readable way. Your primary audience for this type of programming is other humans. I'll take a good writer over a puzzle-solver any day. Don't get discouraged if they aren't for you.
> I'll take a good writer over a puzzle-solver any day
Absolutely agree, but I'd extended it to good communicator. Communication touches on so much of what we do as programmers, be it talking to customers, sharing ideas amongst a team or writing code in a way that's readable by others, that it should be a primary concern.
Despite what you'll hear from people peddling various flavors of Kool-Aid, "programmer" isn't a personality type. It's a job description. If you program, you are a programmer, end of line, full stop. Don't let anyone convince you otherwise.
I think there are categories, and we haven't figured out what to call them yet or how to define them. I see archetypes emerging over the years, and patterns. I've worked with career programmers that are done at 5:00pm, and never crack a book. They work fine in their niche, and when layoff come, they're working tech support. I know others that love problems but can't seem to make their ideas become manifest, yet kludge snippets from StackOverflow to create a product. I personally live for challenge, I learn new languages and tech as a hobby, and lead growth and change in every org I've worked for. Often at the cost of health, and relationships. We're all programmers, but we're not all the same.
> We're all programmers, but we're not all the same
Which is a rebuttal to something I didn't actually say, but OK.
Look, obviously there are all different kinds of programmers. Millions and millions of people program computers today, so there's no end to the ways you can slice them apart. There are kernel programmers and GUI programmers, mainframe programmers and mobile programmers, Lisp programmers and BASIC programmers, elite programmers and n00b programmers.
But they are all programmers, was my point. They all do the work of wrestling with, as one of the people in Tracy Kidder's classic The Soul of a New Machine (http://www.amazon.com/The-Soul-A-New-Machine/dp/0316491977) called it, "La Machine."
In this respect, being a programmer is a lot like being a coal miner: you become one by doing the work. Sure, some miners are handier with a pickaxe than others, and some can stand being down in a dark hole for longer. But regardless of that, everyone who puts on a hard hat with a lamp on it and goes into the mountain is a coal miner. The only thing you have to do to earn the designation is show up and do the work.
Now for the part of my comment where I (respectfully) challenge your conclusions.
You want to divide "programmers" further, into (essentially) "programmers," who are lazy 9-to-5 stumblebums, and "REAL programmers," who code with burning fury 23.5 hours a day (the other .5 hours they spend on HN). And then tell the people outside the "REAL programmers" category that, sure, they're "programmers," but they're not programmer programmers.
But that has a value judgment embedded in it, namely that 23.5-hour-a-day Burning Fury programming is Good Programming, and 9-to-5 programming is Bad Programming. But those positions aren't good or bad, they're just embraces of different sets of tradeoffs. You note yourself that the Burning Fury programmer sacrifices her health and relationships to get to that level. The 9-to-5 person is just someone who has decided against making that sacrifice. Maybe that limits their career growth, but it lets them hold on to those things. Maybe you've decided to let those things go in order to accomplish more in your work.
And both those decisions are fine! I'm not here to tell you how to live your life. I'm just saying that your way of being a programmer is not the only way of being a programmer. There are lots of ways to be a programmer. The only thing they all require is that you do the work.
Without calling one group "REAL", it would be nice to have different words for different tiers of programmers.
And I can't comment on the poster above, but when I do think of programming skill tiers, it's not at all about number of hours put in.
Yes, if you're passionate about a problem it can mean you end up putting in extra time to solve it. But it's not about the time. It's about the passion.
Similarly, it's not calling the leave-at-5pm programmers lazy. To them it's a job, and maybe even a job they're good at. I spend a lot of time living life outside of work, and I (usually) end up quitting after only about a normal day's work.
But I also get more done in my work day than 98% of "programmers". And the reason is that I've had a consuming passion to learn about programming techniques, tools, algorithms, and even logic puzzles, ever since I can remember. So some of that free time involves reading about programming; if I enjoy it, then it certainly counts as living my life. When I don't feel like learning something about coding, I do something else in my varied set of hobbies and interests.
The reason it would be nice to have different words for different tiers of programmers is that what I do is qualitatively different than what the copy-and-paste JavaScript writer is doing. I can certainly call myself a software engineer, or a game developer, or a graphics engineer, or a low-level programmer, but none of those really encapsulate it all; I also hit high performance server development, database optimization, networking, encryption/security, video streaming, and petal-to-the-metal assembly language optimization when necessary (though that's a skill that's less and less useful these days). And on top of that I write tools that help optimize the software development process for myself and my team.
When I look at what I do vs. what a junior front-end web developer does, calling what I do the "same" as what the junior developer does is somewhat akin to calling an assistant handyman and an engineer who designs skyscrapers or rockets or nuclear reactors "both engineers, because they both help build things!". All that extra work the engineer puts in to learn and hone his trade should be worth something, and having a title for it does help.
Something that bothers me about your coal miner analogy: The best possible coal miner is likely not more than 2x-3x better than the worst. Brooks' famous 10x performance difference only captures a small part of the real difference: There are things that I can do that a JavaScript developer simply can't do, no matter how much time they put in. Brooks was only measuring people trying to accomplish similar tasks, after all. And I'm not talking about domain expertise; I also follow and keep up with JavaScript and front-end development, and it's just orders-of-magnitude simpler than what I code on a weekly basis.
And I do find that puzzle solving (though not the physical kind) does correlate pretty well with the ability to do the high-end, hard-core programming that I do. I certainly am good at both, and it would be hard to imagine how I could solve the complex algorithmic issues that I solve on a daily basis if I couldn't think clearly about logic puzzles.
I take offense at your gross misconceptions. JavaScript is by no means an "easy" language, certainly not orders of magnitude easier than whatever it is you do. The skills of a "JavaScript developer" include combining object-oriented and functional design patterns to organize a codebase, efficiently managing asynchronous communication and state, profiling and optimizing rendering and execution performance across the CPU and graphics card, designing and implementing for network security (including testing for HTTP headers, XSS, CSRF, etc.). What is it you do again?
A "copy-and-paste JavaScript" developer, as I referenced above, is someone who can create web pages that have simple actions, but who doesn't do much original development.
The language certainly doesn't define the programmer. I also use JavaScript on occasion; I wasn't trying to paint all JavaScript developers with the same brush.
It sounds like what you do is NOT what I'm talking about, so please don't take offense.
I write games, and tools to make games, and tools to stream interactive applications over the Internet. And apps. And the occasional web site.
Fair enough. I think what we do is probably pretty similar, the difference being that I do it mostly in JavaScript.
Perhaps there is something to your point -- I doubt there are nearly as many successful "copy and paste C++ developers" (although I have met at least one). It might be harder to cobble together even a barely-working piece of software from StackOverflow C++ posts.
I've met a copy-and-paste C++ developer myself, though he ended up losing the job eventually.
Blew me away to discover this when I sat down to help him debug an algorithm that he had, in fact (correctly) copied from somewhere else, but then he'd slaughtered it trying to "make it work." Most of the fixes involved reverting his changes, and then making a couple minor modifications that WERE actually necessary.
He'd been fighting with it for a couple days. I had it streaming sound in about 15 minutes. Based on his words to me after the fact, he was really just not understanding what the code was doing. Pretty much at all.
That said, he did have some good insight into user interface design. I could see that he did have some important skill sets, but understanding how to manipulate memory in C was not one of them. Whether he was a "successful" developer is debatable, since he didn't hold the position, though.
I'm sure that "copy and paste" developers exist for most common languages. I've heard from several sources that finding a non-copy-and-paste developer who uses JavaScript is a real rarity. I've also been told that Google in particular is looking for that skill set. Sounds like you could write you own ticket. :)
Hopefully I'm not contributing to the "schism" here, but:
I tend to divide programmers into "drones" and "meta-drones" (for want of better words).
First, "meta-drones" consider the "meta" level of programming, i.e. "could I program more reliably if I were using a different language?" or "how can I prevent myself from making similar mistakes in the future". Surprisingly few programmers actually fall into this category. This is obviously IME, so the usual observer/survivor biases may apply.
In contrast, a "drone" will just "get the job done" without any further thought.
As far as I've been able to ascertain, code maintainability/quality is entirely orthogonal to the "archetype", but there's a clear tendency that the "meta-drone" tends to improve by orders of magnitude over time.
The number of hours of work put in has no significant effect when you account for those orders of magnitude.
The best programmer I've ever worked with is done at 5. He has lots of other hobbies. But at work he's incredible efficient and solves really hard problems in brilliant ways. You don't have to give up your whole life to be a good programmer, contrary to what many people on HN seem to think. This mentality drives me crazy.
Agreed. I don't understand why we are so obsessed with putting in the hours.Its not just in programming, but also other sectors of the economy.I value my health, family and personal life, I'm competing with myself not against the clock. The clock will always win, no matter who you are or how great you are at programming. Work smart, not long.
I really don't like this euphemism. When I read this I know what you mean[0] but I wish this meaning wasn't tied to leaving the office at 5pm. If someone's effective in their role, why should they be judged on what time they leave? This mentality doesn't encourage people to work harder or be better employees, it only encourages them to stay later. That eats into their free time every day, giving them less opportunity to relax and recharge and probably causing them to become less productive and more prone to burnout in the long run.
If I can get my job done by 4pm every day then don't force me to sit at my desk until 6pm to keep up appearances. Either let me go home or help me fill my time by offering me more work (and if I'm highly productive, more compensation).
[0] The person is only putting in the bare minimum effort, has no interest in personal development, is more interested in the paycheck than craftsmanship and professionalism, etc.
In fact, Scott Adams proposed this in The Dilbert Future as a workplace scheme to improve productivity (he called it 'OA5'). He may be accurate in thinking it's up to the employer to destigmatise leaving 'early' (when in fact it's a symptom of an employee having a good work-life balance, providing his performance is sufficient).
However, I've been thinking about this recently - the logical extreme is that you should never expect the employee to turn up at work at all, provided he performs his tasks (say via telecommuting). Perhaps employers mandate 'desk time' because it's important to have regular physical access to the employee, for example in order to talk to him? I can think of HR/legal reasons where a private in-person interview is needed in order to inform the employee of something or to retrieve information from him. Consequently, if an employee only came in to work for these meetings, it would be obvious when the employee was engaged in some sort of 'serious' communication with the company. It would make mass layoffs especially conspicuous and difficult for the company to hide.
Of course, this affects whether you can work on certain projects or not, but not that "every programmer knows that" is a fallacy (except for something really fundamental)
Many companies have a hiring process that favors hiring very similar engineers. Hiring different types of programmers would increase their diversity, which for me is a great quality of a team. The challenge here is to identify the competent engineers when you can't use cookie cutter assessment tactics.
Suffices to see how several founders (of successful startups) were rejected or quit big companies. I believe Google is one of the worse offenders there.
Diversity is a strength, and I have learned this managing several teams of varying sizes over the years for different companies, as well as for myself.
I have heard many start up advisers tell people to 'hire people you like to hang out with'. This isn't the best advice. Personality is extremely important, and you don't want to hire people who will be incredibly difficult or toxic or adversarial. But you need different people in different roles, with different viewpoints, to make a strong team.
Yes. We need to stop thinking of programmers as artists and more as artisans. This is not a devaluation, this is exactly what it is and a very necessary job. Each shoemaker used to be proud of his shoes, even though there are not so many different ways to make them. Less so in the early modern ages.
I'm a programmer who loves 'building the brain'. I've been coding professionally for about 16 years.
I've written some code I'm really proud of. A couple of specific pieces of code are actually used in a LOT of major websites you probably use. Like almost every health care site or major retailer site. I actually find most code written by 'whiz' startups - even successful ones - to be incredibly simplistic. Not a knock on them, just stating this for reference - I have even written some encryption code that gave me headaches to understand but is still in use by a few major financial corporations years after I wrote it. I know I can write some serious code. I studied and work with AI programming in my spare time.
I don't have a GitHub page, nor do I have an interest in having one. I barely have a StackOverflow profile. I post on Hacker News now and again but that's about it.
I don't care about hackathons or solving puzzles.
I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting. I'm just smart and I like to code. I am not socially awkward. I'm introverted, but I'm not shy. I played football and basketball and I played chess. These concepts are not mutually exclusive.
>>> I don't have a GitHub page, nor do I have an interest in having one.
Glad I'm not the only one.
>>> I don't care about hackathons or solving puzzles.
Couldn't have been said any better. I never produce anything good when its tightly timed, under pressure, when people are watching over you.
>>> I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting.
Add "ninja", "guru", "rockstar" and other hipster name floating around these days to your list. I hate it too.
I've been doing programming for 3 years on and off. I program for fun, as a hobby and I can't see myself programming to meet unrealistic deadlines year in year out for someone, that's my personal opinion. I grew up in an athletic environment so I also play rugby and sprint for fun too. The most I would do is to program small projects at my own pace and share them to people or keep it to myself. I hate rushing into things which I feel hackathons encourage.I like to think, research, think and then create.
I program because I generally like making things, not just programs but also technical drawing, house designs (architectural and interior) and custom-modded computer builds , it has no correlation to solving puzzles or cramming algorithms I probably will never use.
Edit: There is this insanely think barrier filled with confusion in Human Resources, as a recent Computer Science graduate, some of the job descriptions have unimaginably high expectations for entry positions I actually think you have no place here if you don't know 4+ languages, 2+ trendy frameworks, and 1-2 years of experience from a fresh graduate.
I see this comment about "nerd", "geek", "ninja", etc. crop up a lot. These are solutions to the problem of "what term do we used to describe an excellent programmer, that both excellent programmers will identify with and other managers will emotionally relate to"? How would you solve that problem?
Why do we need to give programmers such punchy titles? I haven't heard anyone doing this in any other craft. In my view, calling someone a good, great, excellent, skilled, or top programmer as appropriate is more than adequate.
I am not arguing that programmers need to have "punchy" titles at all. However, others clearly that some sort of term beyond those you listed is necessary, and these names are evidence of that.
There is no need for those terms. They are marketing names dreamed up by people who think they can neuro-linguistically trick developers into thinking working for them (usually for less money than they are worth), then they can get over on them.
Again, what is the difference between a doctor who is one of the best in the world versus a doctor who is just 'decent'? What is the term that is necessary to describe that doctor that doesn't exist? Why would any profession be any different?
I don't think I'd even want to go to "Dr WhateverName, Ninja Orthopedic Surgeon" or want to know that he wrote "Secrets of a rotator cuff repair rockstar."
I just say they are world class programmers. Or excellent. There is no problem. How do you describe doctors who are very good at what they do? Do you call them ninjas? "Med nerds"?
You're claiming there is a problem here that doesn't exist. We have words to describe people who are good at what they do.
Other fields seem to have managed to solve this problem without resorting to sophomoric faux-titles. It just reeks of childishness and the sort of tomfoolery that tends to get our profession laughed at.
When I see these words, it screams either "bunch of young kiddies" or "a bunch of olds desperately trying to seem cool" and neither are situations that I want to get involved with.
And all of this isn't even getting into the problem that 99.9% of people want rockstars, ninjas, jedi and superheroes but only about 0.1% really need them.
I wish programming culture didn't scare away people who enjoy athletics. I love playing basketball and sometimes it's hard to find other programmers who enjoy the same.
When I see "Ninja", "rockstar", etc. I run. Can't stand that.
We need more of this. I played baseball and basketball and yes, I also played chess. I'm not an introvert (although I do love alone time). This narrow idea of what traits a good programmer has is the fault of Eric Raymond who when describing what kind of person is a good hacker was clearly just describing himself (interested in martial arts, plays a musical instrument and speaks a foreign language, all perfectly great interests but what makes them better than cooking or chess or painting?). While it's great to have hobbies that involve critical thinking, nothing about the going stereotype of a programmer is necessary to be a good programmer or good thinker.
Imagine if there was an equally narrow stereotype about what kind of person is a good doctor or lawyer. Doesn't that seem ridiculous? What about programming is different? Nothing. It seems so absurd to me that as an industry we're telling interested parties that diverse interests are a bad thing if you're a programmer and you should just stick to a short list of approved interests. No wonder there's no diversity in our field.
I work with a bunch of smart programmers who would, by the "if you aren't a 12 year old coder and you don't spend all your free time buffing your github profile" metric that pops up on HN, be unemployable. They are deeply, deeply clever people who speak assembler like a second language (or understand the bits of the JVM that most people don't think about, or what have you). They have lives outside their job.
OK, so it would be ok if an interview someone replied "algorithms are solutions to puzzles" ?
I don't think they are. They are solutions to problems in computer programming. Solving computer programming problems has nothing to do with your aptitude in solving puzzles and brain teasers.
Algorithms are independent of both puzzles and computer programming. I learned plenty of algorithms in my EE undergrad that were used with a pencil and paper.
Unfortunately in today's climate it might be realistic to say "algorithms are solutions to interview questions" Although I do believe the more tools you have in your toolbox the better. Knowing algorithms can be incredibly helpful. Same goes for design patterns, language design, etc.
It just seems like a fad to drill people with algorithm questions in interviews even if that skill will never be required for the job. I suppose it reveals to a certain degree whether that person has formal CS training or a personal interest in algorithms.
Would you disqualify a candidate based on that one data point? If so, I think you're missing good hires, and not in some false-negative preferred to false-positive way.
> Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba.
I would guess most "discovered" those because they had to interview. The % of programmers who need to Karatsuba or Bayesian inference to finish their project is very much smaller than the % of programmers who thought "oh shit, I better learn this because Google and Facebook keep asking about graph theory".
It it is perhaps an interesting secondary effect. CS concepts become useful not just because they are useful (and they are) but also because recruiters at many companies think they are. If tomorrow juggling skills somehow become popular during Google interviews. You'd see a lot of juggling programmers out there.
Actually I think graph theory is pretty important. For example many programming contexts have to deal with dependencies, and often dependencies form a directed acyclic graph. Understanding that will aid in writing better, more reliable code. Path finding is also pretty important, especially if you want to make a game.
That's great if you're a game AI programmer (an incredibly small group) or you're creating Yet Another Dependency Loader (hey, I guess <language that becomes super popular next year> will only have 100 frameworks to manage modules, you'd better create your own as well).
You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.
Which is why I love python. Have you seen some poorly written JavaScript that's poorly indented and has no comments? Until there is a universal guideline for JavaScript and that developers follow, I won't have a go at it again.
Indentation is pretty low on the list of things that make code maintainable or not. (If it bothers you, just pass the code through a pretty-printer.)
Much more important is to pay attention to system-level measures such as modularity, abstraction, (de)coupling, and documentation. 99% of maintenance nightmares are due to code that is not modular (and thus not easily replaced), is abstracted too much or too little (leading respectively to obtuse or repetitive code), highly coupled (causing brittleness when assumptions are broken), or poorly documented.
(There are probably others, but these are the first to come to my head. These measures are also not necessarily orthogonal.)
> You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.
IME, programmers that write readable, maintanable code and those that have a solid grasp of algorithms and theory as it applicable to the problem domain tend to overlap considerably. Having a clear analytical mental model of the approach to the solution leads to clearer and cleaner code -- and, where necessary, clearer and more useful comments -- than hacking your way to something that works. (And I'd say thats as true of my own code -- where I've done work on both extremes of the clear model to hacking-my-way-through axis -- as of others' code I've seen.)
Agreed. Some people say you'll only use it in games or AI or something fancier, but that's not entirely true. I work with what would be considered pretty boring enterprise software, and yet I once solved a pretty big problem using graph algorithms. That actually earned me a good reputation among my coworkers.
I don't think the primary complaint about these types of skills is that they are never useful. It's just that they are treated as disproportionately important, i.e. interviews consist of 80% CS knowledge but the real job only requires it 1% of the time on average.
I used some super simple graph theory recently to write a Java tool that spit out data from multiple tables on a database into SQL files, with statements in the right order so that foreign key relationships were preserved. And this was for a CRUD-ish web app.
I don't get why people tend to think that computer science is something different from "actual programming". In the end everything you can program can be expressed formally and vice-versa, the only thing that changes is how much you abstract from the actual implementation, which is handy in order to catch defects in the approach you are taking to certain problem.
I'd say fluid-dynamics and plumbing. Most businesses really just want us to connect this to that and not have the shit back up. If you can deliver that quickly, without much analysis, and without fuss than you're very effective for many business and product types.
It's not the subject matter per se, it's the difference in habits and typical incentives for people who identify more with one description or the other.
For many products and businesses, it's not really necessary to avoid long-term dead-ends (say 3-5 years) if you can be much more effective in the short-term (say 3-12 months). So a high up-front cost (required knowledge and planning / research experience) approach often loses out to simply banging out more code, which requires little CS knowledge.
Because everybody can do "actual progrmaming." Especially in grad school.
Computer Science is broad (even AI is different), but I'd say it's more about Turing's academic papers, and computational mathematics. Programming, and computers, aren't even needed, they're just models which either can or cannot derive solutions, or in a reasonable time. Such as the halting problem, P, NP, NP-complete.
In a way it's mathematical logic, but with more rigorous proofs.
Everybody else can learn a generic language with some external libraries and make almost anything they want. But that's not more academic than it is to do woodworking, or sewing. Comp Sci is academic, and one of the more important ones because it determines a lot of research other disciplines do. I.e physicists and mathematicians do comp sci, while the softer sciences run models without understanding why they work.
I distinguish between two types of puzzles: human-made (which I call puzzles) and everything else (which I call problems.)
In those terms, I hate puzzles and love problems. Puzzles are contrived by humans and are generally as much psychology problems as anything else. They basically require you to think like the human who created them, and they have bizarre and arbitrary constraints that are totally unlike the real world, where, as Feyrabend told us, "Anything goes."
Puzzle-style interviews are 99.9% human made, and one of the features of human-made puzzles is: the answer is known and very nearly unique. This makes them almost completely unlike the real problems programmers encounter, where there is no known answer (if there was, the programmer would find it on Stackoverflow or similar) and amongst the potential answers there is no obvious winner.
So it's really easy to be good at puzzles and terrible at problems, which require taste and good judgment to navigate through the combinatoric explosion of approaches and parameters (and no, design-of-experiments won't do more than give you a little assist on genuinely hard problems.) Problems also require one to know when to stop, when a solution is "good enough" for the given domain. Even problems that are nominally non-statistical in nature require decent statistical knowledge to evaluate potential solutions.
So as someone who designed algorithms for a living for quite a long time, and still does for fun and profit now and then, I'm as strongly against puzzles as the OP. I'm actually slightly biased against people who love puzzles because it looks to me like they are spending way too much time playing with nice, neat pebbles on the beach, when the ocean of ugly, intractable problems lays unexamined before them.
Totally agree! Puzzles are just one way of studying human (or animal) behaviour in a controlled environment. It's absurd to be used as the main tool to evaluate a person's competence.
An interesting heuristic difference between the two types of, lets call it, challenges, is how you define success.
In a puzzle, you achieve success as a well defined solution, or (in a lot of the theoretical cases) by showing no such solution exists.
In a problem, there is many goals to balance (simplicity, efficiency, cost, implementation time, etc). Often, the best solution is not needed, or the "optimal" one is too complex or takes too long to implement. Often, the perfect solution is not possible, and you have to think about how to change the definition of the problem to get something acceptable.
So true; the Google, Facebook, Microsoft, Fill in Here puzzle interviews are pretty silly. Rather than splitting people into groups of "good developers" and "bad developers" they can really be split up into these two categories.
1) People who read Cracking the Coding Interview
2) People who haven't heard of this book.
Seriously; any competent programmer can crank through the stuff in that book in a week or two and be solid for the types of silly questions they will be asked in those interviews.
Honestly the best interview I ever had was one where I interviewed with a highly technical IT director and it was just very conversational. We spent about two hours of just chatting about the different types of technologies we had been working with and kept diving deeper and deeper into knowledge areas. At the end of it he just says, "Ok, you are obviously a smart guy; I'm going to send you over to see the VP now so you two can discuss salary requirements."
As the author of said book who has coached MANY people, I can assure you that many - heck, most developers - could not pass a Google interview regardless of how much they prepared. They'll get better with preparation, but it doesn't just fix all issues.
Don't get me wrong. I made it through the Amazon interviews thanks to your book. I spent a week reading through and cranking out examples before the interview. Then I spewed out all of the desirable answers at each step of the interview process.
Now I'm a highly experienced developer with 15+ years experience across a variety of technologies. I contribute to open source, answer questions on Stack Overflow, present at technical meet ups. I solve problems that need solving even when no one else will step up.
Despite all of my experience, implementing hashes and sorting linked lists in place, as well as many of the other questions asked by these companies just don't come up on a daily basis. A good developer isn't someone who can explain those things in an interview, it is someone that can examine the problem and design a solution. They should have an idea of the tools necessary and then reach for the right book or use a healthy dose of google searching some api docs to build the solution.
The current interviewing techniques are broken. I would like to offer the solution, but quite frankly I've spent plenty of time interviewing people and we haven't gotten it down yet either.
-------
The ideas Malcolm Gladwell discusses in, "Blink: The Power of Thinking Without Thinking", applies here. Some of the most experienced developers will have an intuition for how best to implement a solution, this does not necessarily translate to them being able to well articulate the why and how.
So, you're a good developer who is smart and passed the interviews with some studying. That's exactly how it's supposed to work :).
You're right that the problems that some up in interviews typically aren't real life problems. But that's not necessarily an issue. Are the skills they test (developing good algorithms) important for real life?
An interviewer doesn't ask you to develop an algorithm to return a random node from a binary tree because they particularly care if you know THAT algorithm. They're asking as a way of evaluating your skills developing solutions to problems you haven't seen before.
I believe that is the most common argument made, but also therein lies the fallacy.
I'm not developing anything new when I implement a quicksort algorithm; Tony Hoare certainly was back in 1960 when he created it. The same goes for the hash; someone at IBM made a big leap when they first used hashes back in the early 1950s.
Since that time numerous people have made some improvements to these (and other algorithms of course), but by and large companies are just testing is the developer interviewing able to code existing algorithms and explain their Big-O notation.
I think you end up with 4 subsets that the interviewees fall into.
I = {interviewees}
A = {I | bad programmer and can't solve algorithms}
B = {I | good programmer and knows the algorithms}
C = {I | bad programmer but knows the algorithms}
D = {I | good programmer, doesn't know the algorithms}
It is subsets C and D that concern me.
In subset C we have someone that studied the algorithms really hard, but just can't write good code and solve real original problems. One approach to this is the "hire fast/fire fast" mentality, but in some organizations "fire fast" is not an option; so you would rather not hire them in the first place.
In subset D we end up missing out on good developers. In a bad job market there isn't much need to worry about this; if we miss a good developer easily enough we'll find another. Right now though developers are in such high demand I see this loss as a bigger deal.
I also think that this type of interviewing technique works better for the tech giants (MS, GOOG, FB, etc...) than it would for a lot of smaller organizations. A good set of programmers will self select out of interviewing at these companies because they don't believe they are "good enough" for MS(or alt). Additionally a good set of developers that do believe they are high caliber enough for these organizations will do some research about the interview process before hand and end up studying up on the right things before going in.
With smaller companies or businesses with non centralized hiring processes for developers interview candidates may just not know what to prepare for in the interview and while an algorithm may seem obvious in hindsight; there is a reason nobody was using it until it was "discovered". I can't reasonably expect someone to devise the answer to that type of question when I interview.
Honestly I would love to hear some ideas on this; as it has been a pretty major concern for me for the last couple of years.
By discovering puzzles you are still a programmer, and you are a better programmer for it. Make no mistake. Yes you don't need to know algorithms to be a programmer, but you are better programmer for knowing the algorithms.
As a self-professed "boring" programmer, I think a lot times I'm extra useful on a team because I don't expect my work to be a fun puzzle and I'm willing to take on things that aren't much like a puzzle, but are still important.
Nah you need to do a few coding boot camps and hackathons before you can call yourself one. Also, you need a git account full of forks of other projects that you haven't made any changes to.
>It's a job description.
Counter point: no, it's not. I coded professionally for 10 years. I'm now coding recreational for 29 years. (I'm 36, do the math) I contributed to various platforms, frameworks, libs, open source thingies. I have a shitload of code side projects. I'm the organizer of a quite popular code related meetup. I'm not a hacker, I'm a programmer. I don't code for money.
I dislike puzzles too. I guess because you're just finding the creator's predefined path, and it often feels like a pointless task. Programming is coming up with original solutions of your own, so I don't see the two as wholly related.
That is exactly how I feel about puzzles. They just feel like such a waste of time, especially jigsaw puzzles. What do you even do with them once you're done?
A puzzle is a puzzlemaster saying "try to find the exit in this maze I devised!". But I'd rather build my own mazes that I'm more interested in, and then try to find the exits for my mazes.
If people find other people's problems interesting, then good for them. Mostly I find that my curiosity creates the most interesting puzzles, perfectly suited to what I'm interested in.
In other words, implicit in liking puzzles is the assumption that you care for what the puzzlemaster cares for. I find that double coincidence to be rare (for instance, Gardner's puzzles as discussed today here are mostly uninteresting to me).
The problem isn't with him, it's with programmers who have an inflated view of how smart you have to be to be a programmer.
There are plenty of smart programmers, and there are plenty of problems that would benefit from smart programmers, but the vast majority of problems just need a spark of creativity and a lot of hard work from a person with a reasonable base of knowledge.
And then people don't know where impostor syndrome come from...
With a lot of BS being spewed on the net like "everybody needs to know how to unit test", "everybody should learn how to use Vagrant", "everybody should know Ruby", "knowing the SOLID principles is essential"
And then you ask them how to write a regular expression and they fall flat on their face. Or the basics of how to do a Fourier transform. Or how to draw something on a canvas.
Programmers SHOULD know how to write tests for their code. And how to write clean, well designed code (even if they don't call it SOLID). And they should know how to use regexps as well. These are skills that are transferrable whether you're doing frontend work for a small ad agency or crunching numbers for the NSA.
Yea I also think people mistake the tools for the trade. The fact is, two programmers can exist who know nothing of about each other's toolset, and they aren't necessarily better or worse, simply in different domains.
Vagrant is (can be) great if you need heavily spec'd out VMs, but with python I believe virtualenv would suffice. In the end, they are only tools
You realize that regexes, fft and canvas APIs can be seen as the same kind of thing - as simply tools - as unit tests, Ruby and SOLID (whatever that is)?
Some tools are usable in more contexts, but you can still lead a perfectly healthy life if you are in a domain where the ones you don't know are not needed.
SOLID is a set of (possibly questionable) religious principles often espoused by OOP programmers. It tends to boil down to "keep things modular and don't break abstractions", with specifics guidelines for dealing with objects and inheritance.
> SOLID is a set of (possibly questionable) religious principles often espoused by OOP programmers
Exactly my opinion
There's a good side to it, but it's mostly used for people to (in a cargo-cult way) abuse OO and replace simple computations with something spread over 5 levels of inheritance and lots of different types.
Whats more, I question the validity of equating smartness with puzzle solving abilities. It's a bit like equating quality work with having academic credential : no obvious link.
Being able to discriminate the worker quality is still a non solved problem - at least not with number. Good judge of character are still way better at that - and well, they're pretty exceptional.
People tend to presume that everyone thinks the way do. In this case, everyone solves problems and thinks about programming the same way, right?
I've always had a more narrative approach to coding. Until I read some of the stuff Larry Wall (Perl) has written about how he thinks, I'd assumed I was a giant freak. Not at all.
there are a number of ways to be a good programmer: being a skilled puzzle solver / algorithmist is one of them, being good at designing apis is another, deciding what even needs to be built is another.
Everyone has their own preferences. Like you, I lose interest in puzzles after a few minutes. Whatever it is that gives some people great satisfaction out of finding that one missing piece, I didn't get it.
I can't speak to your experience, but for me, I like architecture. Finding the right way to glue pieces together is actually very interesting to me. I basically implemented reflection in C++ before I even knew that's what it's called because I thought it would be fun. I enjoy debugging and assembly optimizations.
What I found is that this speaks to the difference between a prototypical Software Engineer and Computer Scientist.
Engineers are interested in getting stuff done efficiently, and not just in CPU cycles--time for coding, training new coders, maintenance, extensibility, and how often the code will ever be run all must be taken into account. In my experience, grabbing someone else's solution via a package manager or using a 10-minute brute-force solution to a very hard problem can be the most "efficient". Just throw comments on it and avoid the puzzle so you can get something working. Of course, be sure to isolate the code so that if it ends up being a hotspot it's easy to fix later.
Computer Scientists, on the other hand, seek that efficient solution. Many of the PhD candidates I encountered were optimizing very specific cases of very hard problems (largely related to distributed computing). They enjoy spending time picking apart algorithms and understanding the problem so thoroughly that they can prove, confidently, that they have the most efficient solution to any given problem.
In the end, each broad category relies on its partner, and all programmers have to have some of both. Some of us just lean harder to one side than the other.
I don't think you can determine what kind of SE/CS you have by whether or not they enjoy (tabletop) puzzles.
I have always enjoyed puzzles (although I rarely do them)--I think it's a part of something greater. I like to complete all the achievements in games. I like checking off tasks in task lists. I like cleaning my plate at dinner.
They all feel the same to me, and have little to do with how I operate as a computer programmer (speaking as a web application developer).
When you are young and have nothing to show, puzzle solving, like a school degree, is a way for other people to judge you. When you have experience and track record, puzzle is like meh. People still using puzzle to judge an experienced developer are not very good in evaluating others.
I'd like to point out that the Google quote is not from Google's webpage and is in fact likely a banned interview question. The facebook quote on the other hand is from their webpage on a tool that is used for recruiting.
Ok, but a jigsaw puzzle is sooo not the kind of puzzle that programming is at all about, even the explicit "puzzle" questions that companies like Facebook dish out.
I can't even think of one similarity between the two activities.
As far as jigsaw puzzles go, it would be interesting to see if there are unique ways to optimize your piece search.
There's the edge pieces and sorting by color. I've found that sub-sorting by pegs/holes can dramatically help - I had a "picture made up of pictures" puzzle which allowed me to correctly orient the pieces. Knowing even just two of the required slots, combined with the color, reduced the search to a reasonable brute-force search. Plus, by sorting the pieces you could actually do a brute-force without feeling like you might have missed a piece.
A programmer is one who programs. You are a programmer.
There are many reasons people program. For me personally, it's to make stuff and put it out there. Companies have to have methods of weeding people out, and some of them pick those puzzles.
I feel the same way about games that he feels about jigsaws. They're fun enough but they're inherently contrived and produce no real value. I read books and watch movies for narrative experiences. While there's a growing minority of games that have real emotional, sophisticated and even literature-level narratives, at the end of the day, most games require you to solve contrived puzzles to advance the narrative.
On the other end, there are games like that one where you build pieces from blocks and it's a little world, people have expressed their artistic side with whole castles with automations and calculators. These are more like LEGO, Meccano or other tool; they're a substrate, like a programming language, something you build on. I wouldn't call them games.
Although I will grant that games that pit you against or collaborate with other human beings is worth it to some degree, because you're spending time with people (which is why Chess is bloody boring and pointless to play against the computer), it's all noughts-and-crosses with bells and whistles.
Coming back to his point about jigsaws, while it is satisfying to complete one, personally, any time spent putting in active effort (as opposed to passive effort, like in the case of a novel or movie or theatre), I'd prefer to be doing something actually constructive; to produce something real, either artistically (I paint canvases), or technologically (I'm a programmer). Rather than maintaining these “farms” and cyberpet-style games, or the games where you're digging for gold and collecting resources, I'd rather maintain my bike, go grab some materials from the store and do some DIY in my apartment, plant some things in my garden, etc. Whenever one of my gamer friends explains a game to me, I'm thinking more about how I'd make that than how I'd play it. I'm not saying people who like to spend time doing these things are wasting their time, just that I don't share that desire at all.
Puzzles in a job interview are a poor idea. People don't solve puzzles on their job, with their manager watching them do it. They don't get sacked for failing to solve the puzzle (which failing a job interview is tantamount to; your career depends on it). And if they can't solve a puzzle in 15 minutes, they spend all day on it. Or all week. They ask their colleagues for help. If it's too hard, the product manager considers breaking the problem down. Asking contrived puzzles is such a silly idea that I'm biased against companies that try to ask them for job interviews.
I like making things. If I want to make something and I don't know how, I'll figure it out. Call that "solving a puzzle," but it's a very different activity than solving a literal jigsaw puzzle or answering some arbitrary question about rickety bridges.
If you enjoy making things with software, you'll be a decent programmer. If you enjoy puzzles for their own sake, go check out some Martin Gardner books. Those two enjoyments can overlap, but they're not necessarily dependent upon one another.
Love this. I like puzzles (and scifi) and definitely fit the more traditional model of a programmer, though I'm entirely self-taught and didn't take CS in school. I really don't like algorithms that much. What I do enjoy is API design, writing elegant code that is maintainable, and solving the macro, human-scale problems.
This discussion is going to be mostly meaningless because everyone has a different idea of what a puzzle is. Whether or not something is a puzzle depends on what you know. To a beginner, writing fizzbuzz is a puzzle. To someone with ordinary programming skill, it's not.
The question I usually ask in a job interview is an adapted version of something I actually had to solve, and if you don't know how to either use pointers or how to build and print a tree then you might think it's a puzzle. If you do then it's just applying your skills to the task at hand.
Maybe there are other questions I could ask, but it's a job interview; how else are you going to find actual programmers?
267 comments
[ 2.2 ms ] story [ 265 ms ] thread(looking forward to a future where an image's URI is its hash and this problem evaporates)
I grew up enjoying puzzles, logic puzzles, logic books, math books, piece puzzles, riddles, and all the supposedly clever things to that affect. The more involved I become in the world of programming though, I can't really say.
I have the time to study the complex math and computer science theory sometimes, on the weekend, for fun, and then the code I read through ranges from deeply personalized learning to clear, uniform specifications developed over time periods I have no actual experience understanding what goes on during those time periods. I know the importance behind many theories, and I understand how to apply these things. But I don't know why or how it grew.
If you want to see a puzzle pattern in code, you will see puzzles everywhere. You can see anything you want to in code, just like every other human creation. Make your own meaning and what not. Code is more art to me than 'Art' is.
Easy for me to say, since I find problems like those easy; I cranked through a few dozen of them with only having to really think about a couple.
If you can't answer them all yet...well, now you have something specific to study.
[1] http://www.amazon.com/Cracking-Coding-Interview-Programming-...
Absolutely agree, but I'd extended it to good communicator. Communication touches on so much of what we do as programmers, be it talking to customers, sharing ideas amongst a team or writing code in a way that's readable by others, that it should be a primary concern.
Then congratulations, you are a programmer!
Despite what you'll hear from people peddling various flavors of Kool-Aid, "programmer" isn't a personality type. It's a job description. If you program, you are a programmer, end of line, full stop. Don't let anyone convince you otherwise.
Which is a rebuttal to something I didn't actually say, but OK.
Look, obviously there are all different kinds of programmers. Millions and millions of people program computers today, so there's no end to the ways you can slice them apart. There are kernel programmers and GUI programmers, mainframe programmers and mobile programmers, Lisp programmers and BASIC programmers, elite programmers and n00b programmers.
But they are all programmers, was my point. They all do the work of wrestling with, as one of the people in Tracy Kidder's classic The Soul of a New Machine (http://www.amazon.com/The-Soul-A-New-Machine/dp/0316491977) called it, "La Machine."
In this respect, being a programmer is a lot like being a coal miner: you become one by doing the work. Sure, some miners are handier with a pickaxe than others, and some can stand being down in a dark hole for longer. But regardless of that, everyone who puts on a hard hat with a lamp on it and goes into the mountain is a coal miner. The only thing you have to do to earn the designation is show up and do the work.
Now for the part of my comment where I (respectfully) challenge your conclusions.
You want to divide "programmers" further, into (essentially) "programmers," who are lazy 9-to-5 stumblebums, and "REAL programmers," who code with burning fury 23.5 hours a day (the other .5 hours they spend on HN). And then tell the people outside the "REAL programmers" category that, sure, they're "programmers," but they're not programmer programmers.
But that has a value judgment embedded in it, namely that 23.5-hour-a-day Burning Fury programming is Good Programming, and 9-to-5 programming is Bad Programming. But those positions aren't good or bad, they're just embraces of different sets of tradeoffs. You note yourself that the Burning Fury programmer sacrifices her health and relationships to get to that level. The 9-to-5 person is just someone who has decided against making that sacrifice. Maybe that limits their career growth, but it lets them hold on to those things. Maybe you've decided to let those things go in order to accomplish more in your work.
And both those decisions are fine! I'm not here to tell you how to live your life. I'm just saying that your way of being a programmer is not the only way of being a programmer. There are lots of ways to be a programmer. The only thing they all require is that you do the work.
And I can't comment on the poster above, but when I do think of programming skill tiers, it's not at all about number of hours put in.
Yes, if you're passionate about a problem it can mean you end up putting in extra time to solve it. But it's not about the time. It's about the passion.
Similarly, it's not calling the leave-at-5pm programmers lazy. To them it's a job, and maybe even a job they're good at. I spend a lot of time living life outside of work, and I (usually) end up quitting after only about a normal day's work.
But I also get more done in my work day than 98% of "programmers". And the reason is that I've had a consuming passion to learn about programming techniques, tools, algorithms, and even logic puzzles, ever since I can remember. So some of that free time involves reading about programming; if I enjoy it, then it certainly counts as living my life. When I don't feel like learning something about coding, I do something else in my varied set of hobbies and interests.
The reason it would be nice to have different words for different tiers of programmers is that what I do is qualitatively different than what the copy-and-paste JavaScript writer is doing. I can certainly call myself a software engineer, or a game developer, or a graphics engineer, or a low-level programmer, but none of those really encapsulate it all; I also hit high performance server development, database optimization, networking, encryption/security, video streaming, and petal-to-the-metal assembly language optimization when necessary (though that's a skill that's less and less useful these days). And on top of that I write tools that help optimize the software development process for myself and my team.
When I look at what I do vs. what a junior front-end web developer does, calling what I do the "same" as what the junior developer does is somewhat akin to calling an assistant handyman and an engineer who designs skyscrapers or rockets or nuclear reactors "both engineers, because they both help build things!". All that extra work the engineer puts in to learn and hone his trade should be worth something, and having a title for it does help.
Something that bothers me about your coal miner analogy: The best possible coal miner is likely not more than 2x-3x better than the worst. Brooks' famous 10x performance difference only captures a small part of the real difference: There are things that I can do that a JavaScript developer simply can't do, no matter how much time they put in. Brooks was only measuring people trying to accomplish similar tasks, after all. And I'm not talking about domain expertise; I also follow and keep up with JavaScript and front-end development, and it's just orders-of-magnitude simpler than what I code on a weekly basis.
And I do find that puzzle solving (though not the physical kind) does correlate pretty well with the ability to do the high-end, hard-core programming that I do. I certainly am good at both, and it would be hard to imagine how I could solve the complex algorithmic issues that I solve on a daily basis if I couldn't think clearly about logic puzzles.
A "copy-and-paste JavaScript" developer, as I referenced above, is someone who can create web pages that have simple actions, but who doesn't do much original development.
The language certainly doesn't define the programmer. I also use JavaScript on occasion; I wasn't trying to paint all JavaScript developers with the same brush.
It sounds like what you do is NOT what I'm talking about, so please don't take offense.
I write games, and tools to make games, and tools to stream interactive applications over the Internet. And apps. And the occasional web site.
Perhaps there is something to your point -- I doubt there are nearly as many successful "copy and paste C++ developers" (although I have met at least one). It might be harder to cobble together even a barely-working piece of software from StackOverflow C++ posts.
Blew me away to discover this when I sat down to help him debug an algorithm that he had, in fact (correctly) copied from somewhere else, but then he'd slaughtered it trying to "make it work." Most of the fixes involved reverting his changes, and then making a couple minor modifications that WERE actually necessary.
He'd been fighting with it for a couple days. I had it streaming sound in about 15 minutes. Based on his words to me after the fact, he was really just not understanding what the code was doing. Pretty much at all.
That said, he did have some good insight into user interface design. I could see that he did have some important skill sets, but understanding how to manipulate memory in C was not one of them. Whether he was a "successful" developer is debatable, since he didn't hold the position, though.
I'm sure that "copy and paste" developers exist for most common languages. I've heard from several sources that finding a non-copy-and-paste developer who uses JavaScript is a real rarity. I've also been told that Google in particular is looking for that skill set. Sounds like you could write you own ticket. :)
I tend to divide programmers into "drones" and "meta-drones" (for want of better words).
First, "meta-drones" consider the "meta" level of programming, i.e. "could I program more reliably if I were using a different language?" or "how can I prevent myself from making similar mistakes in the future". Surprisingly few programmers actually fall into this category. This is obviously IME, so the usual observer/survivor biases may apply.
In contrast, a "drone" will just "get the job done" without any further thought.
As far as I've been able to ascertain, code maintainability/quality is entirely orthogonal to the "archetype", but there's a clear tendency that the "meta-drone" tends to improve by orders of magnitude over time.
The number of hours of work put in has no significant effect when you account for those orders of magnitude.
I really don't like this euphemism. When I read this I know what you mean[0] but I wish this meaning wasn't tied to leaving the office at 5pm. If someone's effective in their role, why should they be judged on what time they leave? This mentality doesn't encourage people to work harder or be better employees, it only encourages them to stay later. That eats into their free time every day, giving them less opportunity to relax and recharge and probably causing them to become less productive and more prone to burnout in the long run.
If I can get my job done by 4pm every day then don't force me to sit at my desk until 6pm to keep up appearances. Either let me go home or help me fill my time by offering me more work (and if I'm highly productive, more compensation).
[0] The person is only putting in the bare minimum effort, has no interest in personal development, is more interested in the paycheck than craftsmanship and professionalism, etc.
However, I've been thinking about this recently - the logical extreme is that you should never expect the employee to turn up at work at all, provided he performs his tasks (say via telecommuting). Perhaps employers mandate 'desk time' because it's important to have regular physical access to the employee, for example in order to talk to him? I can think of HR/legal reasons where a private in-person interview is needed in order to inform the employee of something or to retrieve information from him. Consequently, if an employee only came in to work for these meetings, it would be obvious when the employee was engaged in some sort of 'serious' communication with the company. It would make mass layoffs especially conspicuous and difficult for the company to hide.
This also applies to:
- Having a Github page
- Contributing to Open Source Projects
- Knowing (or not) a certain language
- Knowing (or not) a certain technology
- Knowing one of the latest fads
Of course, this affects whether you can work on certain projects or not, but not that "every programmer knows that" is a fallacy (except for something really fundamental)
Suffices to see how several founders (of successful startups) were rejected or quit big companies. I believe Google is one of the worse offenders there.
I have heard many start up advisers tell people to 'hire people you like to hang out with'. This isn't the best advice. Personality is extremely important, and you don't want to hire people who will be incredibly difficult or toxic or adversarial. But you need different people in different roles, with different viewpoints, to make a strong team.
I'm a programmer who loves 'building the brain'. I've been coding professionally for about 16 years.
I've written some code I'm really proud of. A couple of specific pieces of code are actually used in a LOT of major websites you probably use. Like almost every health care site or major retailer site. I actually find most code written by 'whiz' startups - even successful ones - to be incredibly simplistic. Not a knock on them, just stating this for reference - I have even written some encryption code that gave me headaches to understand but is still in use by a few major financial corporations years after I wrote it. I know I can write some serious code. I studied and work with AI programming in my spare time.
I don't have a GitHub page, nor do I have an interest in having one. I barely have a StackOverflow profile. I post on Hacker News now and again but that's about it.
I don't care about hackathons or solving puzzles.
I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting. I'm just smart and I like to code. I am not socially awkward. I'm introverted, but I'm not shy. I played football and basketball and I played chess. These concepts are not mutually exclusive.
>>> I don't have a GitHub page, nor do I have an interest in having one.
Glad I'm not the only one.
>>> I don't care about hackathons or solving puzzles.
Couldn't have been said any better. I never produce anything good when its tightly timed, under pressure, when people are watching over you.
>>> I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting.
Add "ninja", "guru", "rockstar" and other hipster name floating around these days to your list. I hate it too.
I've been doing programming for 3 years on and off. I program for fun, as a hobby and I can't see myself programming to meet unrealistic deadlines year in year out for someone, that's my personal opinion. I grew up in an athletic environment so I also play rugby and sprint for fun too. The most I would do is to program small projects at my own pace and share them to people or keep it to myself. I hate rushing into things which I feel hackathons encourage.I like to think, research, think and then create.
I program because I generally like making things, not just programs but also technical drawing, house designs (architectural and interior) and custom-modded computer builds , it has no correlation to solving puzzles or cramming algorithms I probably will never use.
Edit: There is this insanely think barrier filled with confusion in Human Resources, as a recent Computer Science graduate, some of the job descriptions have unimaginably high expectations for entry positions I actually think you have no place here if you don't know 4+ languages, 2+ trendy frameworks, and 1-2 years of experience from a fresh graduate.
Again, what is the difference between a doctor who is one of the best in the world versus a doctor who is just 'decent'? What is the term that is necessary to describe that doctor that doesn't exist? Why would any profession be any different?
You're claiming there is a problem here that doesn't exist. We have words to describe people who are good at what they do.
Other fields seem to have managed to solve this problem without resorting to sophomoric faux-titles. It just reeks of childishness and the sort of tomfoolery that tends to get our profession laughed at.
When I see these words, it screams either "bunch of young kiddies" or "a bunch of olds desperately trying to seem cool" and neither are situations that I want to get involved with.
And all of this isn't even getting into the problem that 99.9% of people want rockstars, ninjas, jedi and superheroes but only about 0.1% really need them.
When I see "Ninja", "rockstar", etc. I run. Can't stand that.
Imagine if there was an equally narrow stereotype about what kind of person is a good doctor or lawyer. Doesn't that seem ridiculous? What about programming is different? Nothing. It seems so absurd to me that as an industry we're telling interested parties that diverse interests are a bad thing if you're a programmer and you should just stick to a short list of approved interests. No wonder there's no diversity in our field.
I work with a bunch of smart programmers who would, by the "if you aren't a 12 year old coder and you don't spend all your free time buffing your github profile" metric that pops up on HN, be unemployable. They are deeply, deeply clever people who speak assembler like a second language (or understand the bits of the JVM that most people don't think about, or what have you). They have lives outside their job.
Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba.
I'm still a programmer, but now I love puzzles, too.
If I asked someone what is an algorithm and they replied 'it's a puzzle where you solve...", I would laugh my ass off.
I don't think they are. They are solutions to problems in computer programming. Solving computer programming problems has nothing to do with your aptitude in solving puzzles and brain teasers.
It just seems like a fad to drill people with algorithm questions in interviews even if that skill will never be required for the job. I suppose it reveals to a certain degree whether that person has formal CS training or a personal interest in algorithms.
I would guess most "discovered" those because they had to interview. The % of programmers who need to Karatsuba or Bayesian inference to finish their project is very much smaller than the % of programmers who thought "oh shit, I better learn this because Google and Facebook keep asking about graph theory".
It it is perhaps an interesting secondary effect. CS concepts become useful not just because they are useful (and they are) but also because recruiters at many companies think they are. If tomorrow juggling skills somehow become popular during Google interviews. You'd see a lot of juggling programmers out there.
You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.
Which is why I love python. Have you seen some poorly written JavaScript that's poorly indented and has no comments? Until there is a universal guideline for JavaScript and that developers follow, I won't have a go at it again.
Much more important is to pay attention to system-level measures such as modularity, abstraction, (de)coupling, and documentation. 99% of maintenance nightmares are due to code that is not modular (and thus not easily replaced), is abstracted too much or too little (leading respectively to obtuse or repetitive code), highly coupled (causing brittleness when assumptions are broken), or poorly documented.
(There are probably others, but these are the first to come to my head. These measures are also not necessarily orthogonal.)
IME, programmers that write readable, maintanable code and those that have a solid grasp of algorithms and theory as it applicable to the problem domain tend to overlap considerably. Having a clear analytical mental model of the approach to the solution leads to clearer and cleaner code -- and, where necessary, clearer and more useful comments -- than hacking your way to something that works. (And I'd say thats as true of my own code -- where I've done work on both extremes of the clear model to hacking-my-way-through axis -- as of others' code I've seen.)
For many products and businesses, it's not really necessary to avoid long-term dead-ends (say 3-5 years) if you can be much more effective in the short-term (say 3-12 months). So a high up-front cost (required knowledge and planning / research experience) approach often loses out to simply banging out more code, which requires little CS knowledge.
Computer Science is broad (even AI is different), but I'd say it's more about Turing's academic papers, and computational mathematics. Programming, and computers, aren't even needed, they're just models which either can or cannot derive solutions, or in a reasonable time. Such as the halting problem, P, NP, NP-complete.
In a way it's mathematical logic, but with more rigorous proofs.
Everybody else can learn a generic language with some external libraries and make almost anything they want. But that's not more academic than it is to do woodworking, or sewing. Comp Sci is academic, and one of the more important ones because it determines a lot of research other disciplines do. I.e physicists and mathematicians do comp sci, while the softer sciences run models without understanding why they work.
In those terms, I hate puzzles and love problems. Puzzles are contrived by humans and are generally as much psychology problems as anything else. They basically require you to think like the human who created them, and they have bizarre and arbitrary constraints that are totally unlike the real world, where, as Feyrabend told us, "Anything goes."
Puzzle-style interviews are 99.9% human made, and one of the features of human-made puzzles is: the answer is known and very nearly unique. This makes them almost completely unlike the real problems programmers encounter, where there is no known answer (if there was, the programmer would find it on Stackoverflow or similar) and amongst the potential answers there is no obvious winner.
So it's really easy to be good at puzzles and terrible at problems, which require taste and good judgment to navigate through the combinatoric explosion of approaches and parameters (and no, design-of-experiments won't do more than give you a little assist on genuinely hard problems.) Problems also require one to know when to stop, when a solution is "good enough" for the given domain. Even problems that are nominally non-statistical in nature require decent statistical knowledge to evaluate potential solutions.
So as someone who designed algorithms for a living for quite a long time, and still does for fun and profit now and then, I'm as strongly against puzzles as the OP. I'm actually slightly biased against people who love puzzles because it looks to me like they are spending way too much time playing with nice, neat pebbles on the beach, when the ocean of ugly, intractable problems lays unexamined before them.
In a puzzle, you achieve success as a well defined solution, or (in a lot of the theoretical cases) by showing no such solution exists.
In a problem, there is many goals to balance (simplicity, efficiency, cost, implementation time, etc). Often, the best solution is not needed, or the "optimal" one is too complex or takes too long to implement. Often, the perfect solution is not possible, and you have to think about how to change the definition of the problem to get something acceptable.
1) People who read Cracking the Coding Interview 2) People who haven't heard of this book.
http://www.amazon.com/Cracking-Coding-Interview-Programming-...
Seriously; any competent programmer can crank through the stuff in that book in a week or two and be solid for the types of silly questions they will be asked in those interviews.
Honestly the best interview I ever had was one where I interviewed with a highly technical IT director and it was just very conversational. We spent about two hours of just chatting about the different types of technologies we had been working with and kept diving deeper and deeper into knowledge areas. At the end of it he just says, "Ok, you are obviously a smart guy; I'm going to send you over to see the VP now so you two can discuss salary requirements."
Don't get me wrong. I made it through the Amazon interviews thanks to your book. I spent a week reading through and cranking out examples before the interview. Then I spewed out all of the desirable answers at each step of the interview process.
Now I'm a highly experienced developer with 15+ years experience across a variety of technologies. I contribute to open source, answer questions on Stack Overflow, present at technical meet ups. I solve problems that need solving even when no one else will step up.
Despite all of my experience, implementing hashes and sorting linked lists in place, as well as many of the other questions asked by these companies just don't come up on a daily basis. A good developer isn't someone who can explain those things in an interview, it is someone that can examine the problem and design a solution. They should have an idea of the tools necessary and then reach for the right book or use a healthy dose of google searching some api docs to build the solution.
The current interviewing techniques are broken. I would like to offer the solution, but quite frankly I've spent plenty of time interviewing people and we haven't gotten it down yet either.
-------
The ideas Malcolm Gladwell discusses in, "Blink: The Power of Thinking Without Thinking", applies here. Some of the most experienced developers will have an intuition for how best to implement a solution, this does not necessarily translate to them being able to well articulate the why and how.
You're right that the problems that some up in interviews typically aren't real life problems. But that's not necessarily an issue. Are the skills they test (developing good algorithms) important for real life?
An interviewer doesn't ask you to develop an algorithm to return a random node from a binary tree because they particularly care if you know THAT algorithm. They're asking as a way of evaluating your skills developing solutions to problems you haven't seen before.
I'm not developing anything new when I implement a quicksort algorithm; Tony Hoare certainly was back in 1960 when he created it. The same goes for the hash; someone at IBM made a big leap when they first used hashes back in the early 1950s.
Since that time numerous people have made some improvements to these (and other algorithms of course), but by and large companies are just testing is the developer interviewing able to code existing algorithms and explain their Big-O notation.
I think you end up with 4 subsets that the interviewees fall into.
I = {interviewees}
A = {I | bad programmer and can't solve algorithms}
B = {I | good programmer and knows the algorithms}
C = {I | bad programmer but knows the algorithms}
D = {I | good programmer, doesn't know the algorithms}
It is subsets C and D that concern me.
In subset C we have someone that studied the algorithms really hard, but just can't write good code and solve real original problems. One approach to this is the "hire fast/fire fast" mentality, but in some organizations "fire fast" is not an option; so you would rather not hire them in the first place.
In subset D we end up missing out on good developers. In a bad job market there isn't much need to worry about this; if we miss a good developer easily enough we'll find another. Right now though developers are in such high demand I see this loss as a bigger deal.
I also think that this type of interviewing technique works better for the tech giants (MS, GOOG, FB, etc...) than it would for a lot of smaller organizations. A good set of programmers will self select out of interviewing at these companies because they don't believe they are "good enough" for MS(or alt). Additionally a good set of developers that do believe they are high caliber enough for these organizations will do some research about the interview process before hand and end up studying up on the right things before going in.
With smaller companies or businesses with non centralized hiring processes for developers interview candidates may just not know what to prepare for in the interview and while an algorithm may seem obvious in hindsight; there is a reason nobody was using it until it was "discovered". I can't reasonably expect someone to devise the answer to that type of question when I interview.
Honestly I would love to hear some ideas on this; as it has been a pretty major concern for me for the last couple of years.
>>I'm still a programmer, but now I love puzzles, too.
Its perfectly alright. But this generally becomes.
I'm still a programmer, but now every one should love puzzles, too.
>If you program, you are a programmer I agree.
A puzzle is a puzzlemaster saying "try to find the exit in this maze I devised!". But I'd rather build my own mazes that I'm more interested in, and then try to find the exits for my mazes.
If people find other people's problems interesting, then good for them. Mostly I find that my curiosity creates the most interesting puzzles, perfectly suited to what I'm interested in.
In other words, implicit in liking puzzles is the assumption that you care for what the puzzlemaster cares for. I find that double coincidence to be rare (for instance, Gardner's puzzles as discussed today here are mostly uninteresting to me).
There are plenty of smart programmers, and there are plenty of problems that would benefit from smart programmers, but the vast majority of problems just need a spark of creativity and a lot of hard work from a person with a reasonable base of knowledge.
With a lot of BS being spewed on the net like "everybody needs to know how to unit test", "everybody should learn how to use Vagrant", "everybody should know Ruby", "knowing the SOLID principles is essential"
And then you ask them how to write a regular expression and they fall flat on their face. Or the basics of how to do a Fourier transform. Or how to draw something on a canvas.
Vagrant is (can be) great if you need heavily spec'd out VMs, but with python I believe virtualenv would suffice. In the end, they are only tools
Some tools are usable in more contexts, but you can still lead a perfectly healthy life if you are in a domain where the ones you don't know are not needed.
My issue is the developers that say "true developers should know tool X" when for a large group of developers X is irrelevant.
Exactly my opinion
There's a good side to it, but it's mostly used for people to (in a cargo-cult way) abuse OO and replace simple computations with something spread over 5 levels of inheritance and lots of different types.
I've always had a more narrative approach to coding. Until I read some of the stuff Larry Wall (Perl) has written about how he thinks, I'd assumed I was a giant freak. Not at all.
I know this is a "me too" post, but that's kind of what you're looking for.
The definition of a "programmer" is very subjective.
Everyone has their own preferences. Like you, I lose interest in puzzles after a few minutes. Whatever it is that gives some people great satisfaction out of finding that one missing piece, I didn't get it.
I can't speak to your experience, but for me, I like architecture. Finding the right way to glue pieces together is actually very interesting to me. I basically implemented reflection in C++ before I even knew that's what it's called because I thought it would be fun. I enjoy debugging and assembly optimizations.
What I found is that this speaks to the difference between a prototypical Software Engineer and Computer Scientist.
Engineers are interested in getting stuff done efficiently, and not just in CPU cycles--time for coding, training new coders, maintenance, extensibility, and how often the code will ever be run all must be taken into account. In my experience, grabbing someone else's solution via a package manager or using a 10-minute brute-force solution to a very hard problem can be the most "efficient". Just throw comments on it and avoid the puzzle so you can get something working. Of course, be sure to isolate the code so that if it ends up being a hotspot it's easy to fix later.
Computer Scientists, on the other hand, seek that efficient solution. Many of the PhD candidates I encountered were optimizing very specific cases of very hard problems (largely related to distributed computing). They enjoy spending time picking apart algorithms and understanding the problem so thoroughly that they can prove, confidently, that they have the most efficient solution to any given problem.
In the end, each broad category relies on its partner, and all programmers have to have some of both. Some of us just lean harder to one side than the other.
I have always enjoyed puzzles (although I rarely do them)--I think it's a part of something greater. I like to complete all the achievements in games. I like checking off tasks in task lists. I like cleaning my plate at dinner.
They all feel the same to me, and have little to do with how I operate as a computer programmer (speaking as a web application developer).
I can't even think of one similarity between the two activities.
There's the edge pieces and sorting by color. I've found that sub-sorting by pegs/holes can dramatically help - I had a "picture made up of pictures" puzzle which allowed me to correctly orient the pieces. Knowing even just two of the required slots, combined with the color, reduced the search to a reasonable brute-force search. Plus, by sorting the pieces you could actually do a brute-force without feeling like you might have missed a piece.
There are many reasons people program. For me personally, it's to make stuff and put it out there. Companies have to have methods of weeding people out, and some of them pick those puzzles.
On the other end, there are games like that one where you build pieces from blocks and it's a little world, people have expressed their artistic side with whole castles with automations and calculators. These are more like LEGO, Meccano or other tool; they're a substrate, like a programming language, something you build on. I wouldn't call them games.
Although I will grant that games that pit you against or collaborate with other human beings is worth it to some degree, because you're spending time with people (which is why Chess is bloody boring and pointless to play against the computer), it's all noughts-and-crosses with bells and whistles.
Coming back to his point about jigsaws, while it is satisfying to complete one, personally, any time spent putting in active effort (as opposed to passive effort, like in the case of a novel or movie or theatre), I'd prefer to be doing something actually constructive; to produce something real, either artistically (I paint canvases), or technologically (I'm a programmer). Rather than maintaining these “farms” and cyberpet-style games, or the games where you're digging for gold and collecting resources, I'd rather maintain my bike, go grab some materials from the store and do some DIY in my apartment, plant some things in my garden, etc. Whenever one of my gamer friends explains a game to me, I'm thinking more about how I'd make that than how I'd play it. I'm not saying people who like to spend time doing these things are wasting their time, just that I don't share that desire at all.
Puzzles in a job interview are a poor idea. People don't solve puzzles on their job, with their manager watching them do it. They don't get sacked for failing to solve the puzzle (which failing a job interview is tantamount to; your career depends on it). And if they can't solve a puzzle in 15 minutes, they spend all day on it. Or all week. They ask their colleagues for help. If it's too hard, the product manager considers breaking the problem down. Asking contrived puzzles is such a silly idea that I'm biased against companies that try to ask them for job interviews.
If you enjoy making things with software, you'll be a decent programmer. If you enjoy puzzles for their own sake, go check out some Martin Gardner books. Those two enjoyments can overlap, but they're not necessarily dependent upon one another.
The question I usually ask in a job interview is an adapted version of something I actually had to solve, and if you don't know how to either use pointers or how to build and print a tree then you might think it's a puzzle. If you do then it's just applying your skills to the task at hand.
Maybe there are other questions I could ask, but it's a job interview; how else are you going to find actual programmers?