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.

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.

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.

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)

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.

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.

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.

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.

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.

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.)

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.)

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.

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'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.

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.

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.

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.

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. :)

>If you program, you are a programmer I agree.

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.

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 still often hear that a successful programmer should be 'puzzle-minded' whereas I have the feeling that a clear and systematic mind is more essential. A modern, competent programmer should not be puzzle-minded, he should not revel in tricks, he should be humble and avoid clever solutions like the plague" ( https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/E... ).

The real problem of cleverness is when people are bored of being code monkeys and start inventing things that complexify their project without any legitimate justification. Like "a cron job and a two line shell script would do but why don't I design my own multi-tier scheduling cluster"

Dijkstra's comment was made when assembly language was widespread, and I suspect that his idea of "clever" involved the various ways people can famously make assembly language unreadable.

In the introduction to "A Discipline of Programming," he asks if advanced language features belong to the solution set or the problem set, but he doesn't define "advanced," so I can't say where he put the threshold.

http://www.linusakesson.net/programming/kernighans-lever/

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.

If that alone was the reason, then your interviewer did a bad job.

The point isn't to trick you. It's to see how you work under pressure when presented with a tough problem. What is your thought process? Do you dive right in or do you take time to chew on it? What parts of your background can you draw on to help you?

It certainly helps your chances if you can solve the problem, all else being equal, but I'd rather take someone who talks through their work but doesn't quite solve it over someone who solves it yet has trouble explaining how or why.

The best interview questions are layered. There should be a relatively easy solution solvable in multiple ways by anyone with experience programming. It should almost solve itself if you walk through the specifications. (Think fizz-buzz-level.)

But underneath that should one or two harder problems with very elegant solutions. And those are much more about the process -- about weeding out the people who would dive in without really thinking it through. If you make a mess of the whiteboard, get frustrated, start desperately erasing and rewriting the same things without ever stepping back to think through alternatives... well, that might be what I'd hold against you. It's not that you didn't solve it. It's that you didn't prove to me you could've given more time.

Then most, if not all these of recruiters are bad. I like to think through things and take time solving problems. If I see myself doing something and struggling to complete it, I haven't thought it out properly or I have rushed into the problem.

Some people will call you "slow" which I find insulting. For example, When I read a book I like to read the actual sentences rather than skimming over them. I like perfecting details and that sometimes takes time.

Experienced interviewers know that this is how people solve problems. They know that time-boxing the problem is artificial, so they're not exactly evaluating you on how fast or slow you are within that time. The problems should be constructed in a way that lets them evaluate you based on your approach instead of on your solution.

Sometimes it's just a bad interview question, or not the right question for you, the interviewee. Which is why interviewing takes practice, time, and patience, from both sides of the hiring market. It's far from perfect, but more "puzzle"-like questions aren't entirely useless as long as the interviewer really knows what they're doing and how to guide the interviewee.

So in the Escher puzzle a hacker says, "Hmm the picture isn't much help, its not on most of the pieces. What else can I use? Shape!" and so first will attempt to identify every piece that has a shape suggesting it is on the edge of the puzzle. Next puzzle pieces themselves have a certain symmetry, with some 'coves' and some 'penisulas' (or convex and concave curves, or 'innies' and 'outies') so unknown pieces are often sorted into the number of those features they have. Basically the hacker is looking for any piece of information that can inform on a possible way to get to the end, generally that information is non-obvious at first, more obvious once you find it. Particularly delicious puzzles will have several layers of information.

So if you don't care to figure out ways to solve a problem that is, at first glance, either really hard or nominally impossible to solve, you can still program just fine but you need a set of rules for putting together your code. And you won't find yourself asking if they are the best set of rules for the particular problem you are coding, you just make sure the problem is solved. That is a perfectly valid programming model, it gets things done.

[1] And I'm using the puzzle solving / bounds testing skill here not the application which can be applied to good or evil.

Hmm, up until this, I thought I was a hacker. When I see a problem worth solving, I'll dig in and try different tools that I've never tried before and figure out a way to make it happen. I really resonate with what you said about not being deterred by the problem seeming extremely difficult or having no obvious solutions.

But I actively try not to work on things that are "more work than they are worth". Seeming "impossible" is not enough to me to make it worth. It has to actually provide some benefit.

This is not to say I don't still get carried away and attempt something which really ends up not being worth the time...

I completely agree with your point "When I see a problem worth solving,..." the only debate is computing the value. My original point is that as it takes less and less external motivation to engage someone on solving a puzzle/problem they exhibit more and more tendencies of what I associate with the moniker 'hacker.'

[1] Obsessive Compulsive Disorder

The only other reason could be the social aspect of intellectually interacting with is wife for long stretches of time, and it's in their couple to decide how to do that.

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).

(looking forward to a future where an image's URI is its hash and this problem evaporates)

Puzzles provide a good first-order estimation of this ability. Not solving puzzles, per se, but at least analyzing them. A good puzzle requires you to use a part of your brain as "scratch space" to hold hypotheses which are applied to other parts of the puzzle. Can I solve it this way? What if I tweak this part over here? Does this assumption simplify the path to a solution, or miss out on an important subtlety? I think the thing I tried previously was more correct; can I remember how to get back to it?

I'm actually not that great at this. Many of my peers are better. Fortunately, I can compensate in other areas (I'm glad to see writing skills called out in the comments, as I like to think I'm a good communicator). I have developed some coping mechanisms (the ability to identify which details in a problem can be succinctly written down and which subset can be stored in my head -- I refer to my notebook as swap space), but I do see the value of puzzle-type questions for evaluating a candidate's ability to do this sort of thing.

Does this mean that if you can't do it, you aren't a programmer? Of course not. I happen to be a kernel developer, so I write a lot of code that communicates with other modules, doesn't have much of a UI, and has a multi-dimensional rather than flat structure. Different types of programming need different sets of skills. Find your niche, and don't fret about how you don't fit into other niches as well as you fit into yours.

(I interviewed at Google seven years ago and was rejected for being weak at algorithm design. A few years ago I had an aha! moment where I found a simple, elegant, and easy solution to the problem I completely bombed in the interview. Apparently my subconscious had been chewing away at it for literally years. I think solving a question in four years or so is sub-optimal from Google's perspective so I'm sure they were right to reject me, and my inability to do it faster speaks to the deficiencies I mention above. But in the ensuing years I have become reasonably successful in my current line of work, which I enjoy completely. My failure at Google does not keep me up at night.)

TL;DR: Puzzles only measure a single axis, so find which axis your greatness lies on and optimize for that.

I had a number of technical interviews last month and the conclusion was that because of this, I'll never work for a company that uses this kind of interview process. I just can't take the puzzle questions seriously enough to be good at them. But the experience also made me question whether I am still a programmer. Fortunately, I have written some algorithmically complex software to convince myself that I am.

Another Human Resources blunder. I really would like to ask them, where and when am I going to use this in one of your ongoing project? If the answer is not related to the project, there is something wrong.

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-...

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?

I do enjoy questions where there the path to the goal isn't immediately obvious, but there are immediately a couple of approaches to consider, and even though the problem itself might be novel, the steps to get there are each something a competent person can reason about.

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.

I really don't think so: I think it all comes down to how you think - intuition versus logic. And I think people don't fall neatly into either category - it's a spectrum. Too much emphasis is placed in interviews on solving mechnicaly problems and less on problems that can be solved more suitably by itutition: design, feature improvements, re-factoring and some people (including me) I've found have to internalise the problem and can't just simply solve a problem as qucikly as those who are very mechanically minded.

And besides technically ability is part of being a professional(!) programmer working with others. The following should also carry significant weight: an ability to work with others, take criticism, lead others, be resourceful, get stuff done on time, write clean and readable code (not just solve the problem technically) and so on are from my(!!) experience not given enough weight!

Just me two cents.

Recruiting is not necessarily easy. But you can judge a company by how they recruit people. Their hiring process-- given that talent is so critical-- tells you a great deal about the company.

If they do a terrible job, if they are arbitrary or capricious, or if they have discrimination as a policy (e.g.: I was in the room at Startup School when Zuckerberg said "don't hire anyone over 30, they just don't get it" (paraphrased).... then you know it's not a good place to waste your time interviewing.

I'd argue that the company with the puzzle saved you a lot of hassle-- you know they are arbitrary and did not put the effort into producing a competent hiring process, and this likely tells you that they won't respect you once you're on board as an employee either.

There are a great many of these "smells".

As I've gotten more experienced, and more in a position to be picky, here's my current gauntlet:

-- If they locate themselves in a place that guarantees a 2 hour commute for most employees, but don't allow working from home 3 days a week, or remote employees, that's a bad sign. Why pay for downtown office space-- as a startup, no less! -- when there's a lot of cheap offices out in the periphery where most people live? (That's the case in this town, maybe not in others.)

-- Asking for references. First off this is a legal minefield. A reference that isn't glowing is going to open themselves up to liability. Any well run business is only going to say you worked there for some period of time. And who is going to give people they think will give a bad reference? This one shows naivety.

-- Having a preference for ivy league. Google impeaches itself with this one in my mind.

This is one of the most common things I bump into when looking for a job, and Its not just Google. Its so disappointing because I didn't go to "insert_top_ten_university" because I couldn't afford it, competition was insanely difficult, and asking grades where so high.

I always ask myself if these companies that preach meritocracy and diversity is just lip service when all the folks mostly come from ivy/redbrick/Russell group universities. So disappointing.

I recently stumbled across two research-oriented companies that demanded references as a condition of reviewing your resume. I can't believe they get very many good candidates with a borderline offensive requirement like that.

My policy, in the past, was that I'd give references after getting an offer, so that the references would only have to spend their time on a job I wanted to take.

Someone else already commented that if you program then you're a programmer. I think that's really the only definition you should use. Everything else are just proxies, mostly bad ones, for if you're a good programmer or not.

There is some evidence in psychology that many seemingly unrelated types of intelligence are correlated with each other. For example there is correlation between verbal and spatial reasoning ability. Sure, there might be people who can solve differential geometry problems in their head but have terrible language skills, but those people are outliers.

Whether this has relevance to hiring programmers is debatable, but preferring intelligent candidates isn't an unusual idea. Law, medical, and dental schools base their selection on what is essentially a verbal reasoning test (LSAT, MCAT, DAT) though it's hard to imagine that verbal reasoning is the most important part of being a dentist. They follow the same thinking.

I also like figuring out and implementing the right algorithms for a problem, but it's a pretty small part of what I do at work, and if it's complex, it's something I like to take some time to think through and sometimes read up on to make sure I really understand what I'm getting into, so I really don't like playing the logic puzzle games they use in interviews at some places. Being quick with an algorithmic answer is a nice skill, but being a good programmer is a craft that involves more than cleverness with algorithms.

So, since it is not the case that loving jigsaw puzzles implies "ability and desire to be a programmer", then the fact that you hate jigsaw puzzles implies nothing with respect to your status as a programmer.

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.

I pursued Computer Science in the hope of being recognized for the ability to create something NOT in the ability to regurgitate the most arcane algorithm in 45 minutes. Most interviewers KNOW they would NEVER like NEVER use it in production.

Yet, I'm not happy at my current job. What option do I have but to remember the 5th variant of the problem I saw in Cracking the coding interview? None.

Back to chugging. </rant>

EDIT: Thank you for writing this article! Till today I thought I was an idiot for not being able to solve 'that' problem.

They asked a puzzle-y question you couldn't solve? Either their problems are puzzle-y, or they have terrible criteria for evaluating people; either way, do you really want to work there?

They asked a hard algorithmic problem, the kind that was someone's PhD thesis 30 years ago, and which you'd only get the optimal result to if you'd seen it before? Either they really do expect you to know stuff like that off the top of your head, or they expect you to behave a certain way when confronted with stuff you don't know; either way, do you really want to work in an environment with those kinds of expectations?

They asked you to code something hard withing a short time limit, and while you can code it, you failed the time limit; do you really want to work somewhere where speed is -the- criteria to optimize, rather than quality/maintainability/whatever (or at least where they're selecting for that rather than those other attributes)?

Etc.

In general, as others have said, if you program, you're a programmer. What specific roles you're a fit for is largely orthogonal to that.

If you don't pass a company's test, view it as having dodged a bullet, not having 'failed'; either they expect you to have something from day one that you don't have, or they are terrible at testing for what they really want, and so their culture, codebase, etc, is likely miserable. In neither case do you want to work for them.

You want to work for a place whose expectations for what you have on day one fits what you actually have (whatever they may be), -and- whose interview process tests for that (even if it's a little flaky), so both you and they can expect, going into the job, that you can handle it.

Remember, too, that there are false positives and false negatives even when they're testing specifically for what they want. Failure to figure out a puzzle doesn't even mean the person isn't good at figuring out puzzles; just that in this case, in this contrived, high stress set of circumstances (an interview), they were unable to come up with an answer in the time limit.

But how would you interview a candidate? I see what not to do.

Here is what I do:

* Ask about their previous work. Dig into something they are excited or proud of.

* Try to solve a problem together. Usually a simplified version problem I am actually solving at the moment at work.

* If it is a new grad. I will ask them some simple questions about data structures, school projects.

* If there is any sample code, anywhere, I like to see it and it is a big + sometimes.

* See if and what kind of questions they ask.

Does that work? What would you add/remove?

I try not be a "dick" and take the approach of "ok, let's work on this together" approach because that is how things work here.

Another approach (which I don't like as much) is to go by the "we want to hire smart people" mantra. "smart" here is is nebulous of course. So how do you do it? IQ tests. Oh but those are illegal, so just write a tests that looks like one without calling it an "IQ test". That involves puzzles usually too. So I think that is how puzzles became popular.

Depending how many applicants you get, I'd start with a screener, a basic, customized problem that they get an hour to solve, that doesn't have a hard pass/fail, but is just a "Hey, let's see how they code when given a problem". If you have constraints you want to filter for, now is the time (you want speed, see above. You want production quality, give them more time than you think a basic implementation would take, and indicate you want the thing to be production quality; see what they do, what they ask, etc).

If they pass that, yes, what you describe sounds fine, if it's what you're looking for in a hire.

If you want to favor false positives, ask a variety of fairly trivial questions; you're trying to make sure you ask questions they may not have solved before, but which any reasonably competent dev can solve. Bonus points if the person scopes them beforehand.

If you want to favor false negatives, ask harder questions, but make sure they actually are ones you deal with. If you're writing basic business CRUD apps, and your challenges are really in deployment, reliability, gathering and responding to user needs, etc, asking them to implement something from Cracking the Coding Interview is counter to your purposes. Ask them instead what it takes to build a reliable system. Are they familiar with doing that? What are some of the considerations? If they suggest distribution, are they familiar with CAP? Etc.

Really, it all depends what you're looking for. If you want someone who is keen to learn about the domain you work in, ask them if they know about things they have no reason to know about, and indicating that "it's okay if you don't"; see if they admit it. See if they respond with enthusiasm when you start to explain it, "Oh, that's cool!" when confronted with a new idea is probably someone you want, "Huh, okay", maybe not. Etc.

I readily admit, hiring is hard, extremely hit or miss, but a lot of companies seem confused about how it's supposed to work; don't borrow the interview practices of another company in a completely different industry. Google asks those questions? Google -can- ask those questions; they're trying to filter out people. You don't get 1000 applications for every job opening, you can't afford that. You also aren't dealing with the same problems; someone who fails those questions may still be a great hire for you.

Once "art" becomes defined, it ceases to become art. The barista ceases to become important once a machine can replicate the exact results. The artist becomes useless once his or her method can be codified and repeated.

The method of choosing good engineers also becomes useless once it is defined because then that standard can be copied without regards to the traits it originally was trying to gauge. Pure arbitrary processes aren't great because of the lack of transparency that encourages nepotism, but neither is a purely mechanical approach that opens itself to becoming gamed.

A heuristic exchanges information for faster processing. When heuristics are passed around, the original information is lost. Almost everything we do is a heuristic though. 3 meals a day, brushing teeth everyday, etc... Is it better than nothing? Probably. Is it great? No. But everyone offering a "solution" isn't really offering a solution. They're just telling personal stories about what heuristic worked best for them.

The job interview process is quite similar to the friend making process. Not everyone is going to be your friend, and following scripts like saying hello every morning isn't going to do it either. It's just one of those things that are part of life.

I've dedicated lots of time learning graph algorithms in order to get better at interviews: I've only had a graph problem come up once in the last 5 years of programming, and it wasn't particularly tricky (it came up at a time I knew nothing of graph problems, and kind of figured out a graph structure by myself).

When I'm at work, I find I have a knack for keeping things simple, and get a feeling for when certain solutions are a bad idea. For me, software engineering is really about the engineering (make things that meet requirements with the given resources), and from my experience is not so much about being able to implement and provide the time/space complexity of 10 different sorting algorithms (although knowing the basics is important).

It's genuinely a relief to see many other people relating to this kind of experience, sometimes it can feel like you're the only one!

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.

For me, it is not design either, it is something different.

I hate puzzles that are created by other people, where you have to follow the "hidden variable" which is in that case the brain of the maker of the puzzle. They already know the solution! I feel utterly useless solving a puzzle that has been already solved thousands of times by others. What's the point!? After 3 sudoku games I'm done with them. The same with IQ tests on national television. Why would I feel any reward in being able to crawl into the brain of a television writer concocting questions for a general audience? I think there are many much more interesting people in the world, than these guys. Their "puzzles" suck.

I also have never enjoyed solving mathematical problems in text books. I love math, and I read a lot of text books, although university is years ago. I think for people like me there should be different ways to teach them.

What makes me going is to find new things that haven't been known before. After I get some understanding of a field, I love to make up my own problems and solve these. The boundaries of such a problem are vague, it is not even known if it can be solved, but I am happy. Even if it turns out that I solve something that has been solved in the 13th century, I can't care less.

This is just a personal story, but perhaps someone can relate.

It took Einstein about 10 years to formulate the general theory of relativity, needing no further experimental input into the work during this period. A few other scientists such as Wheeler, Schwarzschild and others, not to mention mathematicians like Riemann, put in at least as many "top scientist years" of time - about 20 TSYs in all, conservatively. The core content of this is taught in grad school these days over one semester and could be considered about 1/2 grad student years worth of intellectual effort.

So what did these people do for the remaining 19.5/20 of the time? They got hold of a problem that wouldnt let go of them, that they poorly understood, but nevertheless persevered through false starts, uglifications, and what not to arrive finally at the beautiful theory that it is.

i.e. Problem finding and perseverence through foggy days with all but a candle that seems to threaten to blow out any minute is at least 40x harder and that much more valuable than problem solving.

I believe your phd would've served you well on that front.

General relativity is an incredibly impressive theory, even more so when you take into account how few experimental observations were required to formulate it. Basically "the speed of light is the same in any frame of reference" and "being in a gravitational field is (locally) indistinguishable from being in an accelerated reference frame". (For the second one, think about being in a rocket ship accelerating at a constant rate... you feel a force pushing you into the floor, just like you would if you were standing on the Earth's surface.)

If those two things are true, then GR is the only logical conclusion... but we might have gone another 100 years without reaching that conclusion if it hadn't been for Einstein.

17 minutes, if you can stipulate that at the beginning of the problem, the 10 minute and 7 minute people are on opposite sides of the bridge, each paired with one of the other two guys.

18 minutes, if they must all start on the same side of the bridge, but there is no requirement for all of them to end up on the opposite side.

This also assumes that person who can cross the bridge in as little as one minute has no problem slowing down to accommodate someone else's slower pace; otherwise there's no real point to trying to share the torch.

It's not a hard puzzle, and I think that it's too easy to try to overthink it to sound smart, like you've done.

The reasonable assumption is that the four people are on one side of the bridge, and you want to have them all on the other side of the bridge.

The simple answer is that the person that takes 1 minute to cross goes with all of the other people, and then brings the torch back for the rest.

So 10 minutes, 1 back, 7 minutes, 1 back, 2 minutes. Total of 20 minutes.

There isn't anything technically specifying that they have to end up on the opposite side of the bridge at the end, but you wouldn't have a situation where someone really wanted to cross the bridge and end up where they started without a torch, and it indicates that the four people have one torch, which implies that they're a party of 4, not 2 groups on opposite sides of the bridge.

I think it's a good question, because it judges the state of the person being interviewed. Are they just scared away by a simple puzzle? Do they come up with some contrivance to try and show off how smart they are? Do they just come up with a practical solution?

Personally, I'd give the practical answer and say 20 minutes, give or take a bit for transferring the torch and turning around. I'd make the assumption that they were all on one side of the bridge and want to go to the other.

When you're given a request to send a request across a network and send a confirmation across the network, you're not going to go and send the some of the requests to the server, and some of the requests to the client, and some of the responses to the server, and some to the client, just because, despite the implied context, you decided that you could make it a bit faster by doing something that didn't make sense because it technically followed the rules.

You probably think your answer is still better, and that's why it's a decent question.

Sometimes these questions are explicitly asked to see if the candidate will check the assumptions when there can be more than one, even if one is fairly obvious.

21 minutes.

If the useful radius of the torch is 25% the bridge length, the bridge can be crossed in 15 minutes.

So the correct answer to the puzzle question is "how much of the bridge does the torch illuminate?"

Then the questioner gets flustered, and you can suggest, "Maybe you should have given them one set of night-vision goggles instead."

If you solve the puzzle as written, you can only be as clever as the puzzle-maker. If you can break the puzzle and then fix it, you must be cleverer.

I once aced an interview brainteaser, and the interviewer actually tried to derail my solution by interrupting and making misleading suggestions. When I finished, he told me that I was the only candidate so far to give the "correct" answer. He was clearly unhappy about it, which confused the heck out of me at the time.

I wasn't supposed to do that. I was supposed to give a half-assed, partially correct answer and let the other guy show off how smart and superior he was, by giving me the "real" answer.

So yes, beating the brainteaser might backfire. If it could, would you still want to work there?

  start: 1,2,7,10|
  1:     7,10|1,2  =  2 minutes
  2:     1,7,10|2  =  1 minute
  3:     1|2,7,10  = 10 minutes
  4:     1,2|7,10  =  2 minutes
  5:     |1,2,7,10 =  2 minutes
             total:  17 minutes

Programming itself is such a vague and general term me and my friends tend to split it in smaller, somewhat better defined aspects when discussing about it. I'd say aspects related to creating new code/design/refactoring don't have a whole lot to do with puzzles. Lowlevel debugging of nasty problems on the other hand does have quite a lot in common with puzzles. I should check some research on this, but wouldn't be surpised if one effectively uses different areas of the brain for these aspects as well.

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.

That's not to say that you can't be a perfectly competent programmer without being a hacker. On the contrary, sometimes, though rarely, hacker traits can be detrimental to programming as a profession. A programmer bitten hard by the hacker bug may become a bit too enamored with a puzzle when going about their work on a given project, and as a result come up with a solution that effectively solves a difficult problem but is a nightmare to effectively maintain, especially when others are doing the maintenance.

In restaurants you have line cooks, prep cooks, and then occasionally if you are a "fancy" enough of a place you have a sous chef and an executive chef.

The one common thread here is, they are all cooks.

Now most line cooks will have never have actually "created" a dish, just like most of us have never "created" an algorithm, (having the vision for something new, knowing which ingredients sourced from what region will work the best, knowing how the various intricacies of spices, how they interact with each other, what temperature is optimal for meats, ect), but I am sure they know how to put something new together.

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 just put up with them in the hope that I get stuff done past them.

Today I tried an online Mensa test (the quick stuff), I didn't recognize any patterns in the domino section (I tried 5 before giving up, vertically, diagonally, like text, nothing), I guess, some people are not made for that. I know people who love them and are good at it, I just hope to still get some respect from them.

Programming puzzles are very different though. Do I hate programming puzzles? Sometimes. Again it depends on the puzzle at hand.

As for is he still a programmer? Well if he codes and produces something that works how he wanted it too then sure. He might be one of those programmers that hate debugging though so ends up writing more and more code to 'fix' a problem rather than actually find the real problem instead of coding around it.

On a more serious note ..

I'd like to think that raw cognitive ability would be a nice thing to have in a programmer. In a field where things change so fast we definitely need people are who are good at figuring things out and making things work.

Ofcourse its obvious that the best way to hire someone is to have them build something substantial and or go over their previous open source work. When that is always not possible then some test of cognitive ability will have to come into the picture as a proxy.

95% of software development is not solving complex algorithmic problems, it's plumbing. If the plumbing is so complex that it creates puzzles that need to be solved, then something probably went wrong somewhere along the line.

Preventing the 95% of software development that shouldn't be a puzzle from becoming one is something I'm very passionate about.

When I program I bring order from chaos. I can do that best by using the discoveries of others, and building them up. I'm glad there are creative people who love mathematics enough to figure out original algorithms; I appreciate their work. I'm not one of them. It doesn't change the quality of what I build.

The best programmers typically choose not to reimplement a solution when an existing one works just as well. Why should we love solving the same old puzzle from scratch over and over again?

However, what does not make sense to me is the asinine requirement that a web developer needs to know or understand algorithms. A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm. In my 12 years as a developer thus far I have never needed to solve a complex math problem or write an algorithm to markup some HTML, the closest I get to math problems is simplistic operations in Javascript like calculating the scroll distance from the top of a page or mathematically moving an element around the page in a particular way and I generally use a calculator for these problems.

The problem is many startups try and replicate the likes of Google and have the attitude of, "Well, if Google require you to solve complex math puzzles on a whiteboard in 30 minutes, then that is what we will do too" - reality check: A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever. Only a developer working with data or writing an algorithm to sort it should need to know that stuff. You are not Google, so stop pretending you only hire smart developers who know how to solve unrealistic math problems that they will never encounter.

I have heard from friends and experience a couple of times myself, broken recruiting processes that ask you to solve non-realistic problems and complex math puzzles (which I always fail myself). My policy is unless I am going for a job working and sorting through data, I should not need to know how to write an algorithm on a whiteboard.

The only skill I think all developers should know regardless of whether you are a front-end developer or writing complex algorithms to sort through billions of rows of privately collected American data through a secret Government program is regular expressions. I do not know regular expressions extremely well, but I know them enough to be useful with them and I think this is one area where most developers fail. You might know the latest tools, heck, you might even know how to write an algorithm to sort through a large set of data, but if you can not write a regular expression (even for the most basic of tasks), then I think we have a problem.

The interview process for most developers should be simple like this: Can you write regular expressions? (yes) or (no) - if (yes) then write me a regular expression to get the value between two curly braces in my Node.js application and you have got the job.

There are always going to be companies out there with this unrealistic inflated image of how smart a developer should be. To be quite honest, I would not call myself an overly smart person. A lot of the problems I solve on a daily basis are merely following simplistic troubleshooting steps with a combination of Google and reading the documentation. Most of my day job is simply just common sense. Web developers in particular are over-glorified Googler's with an eye for detail and a large bottle of strong adhesive used for gluing different pieces together. And you know what? There is nothing wrong with that, it is the truth, because I am one of those people.

> A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm.

> In my 12 years as a developer thus far I have never needed to ... write an algorithm to markup some HTML

> A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever.

> Only a developer working with data or writing an algorithm to sort it should need to know that stuff.

This is either a spectacularly narrow view of what an algorithm is or it is totally wrong.

I've done both front-end and back-end/data for years. I frequently write "algorithms" on the front-end. Several of these were recent:

- Retry method for AJAX form submission

- Distribute assorted icons evenly among primary keys in a table.

- Dependency chain to check and execute asynchronously fetched scripts in the right order

- Even CSS can be somewhat algorithmic, as when I optimized by about 100X the hiding and showing of a huge amount of table rows with cascading style rules instead of JS

I don't think I need to go on, but the point is that if you think front-end developers don't need algorithms, then you are doing something wrong. I would check your assumptions about whether hiring for this is actually helpful. The companies you are talking about are leaders in both front-end and back-end technology. How do you think that came to be?

If you have little knowledge of graph theory, algorithms, and other such "esoteric nonsense", you wouldn't recognize situations where those will be helpful, which then reinforces your belief that algorithms are useless. I have seen too many times a person saying that algorithms are useless, who then gets stuck wondering why his naive O(n!) program is running so slow.

Those people complaining about Google caring so much about their engineers being able to deal with basic algorithmic, instead, should wonder why every Google service is so fast.

Perhaps some folks want to automate your job. That's not to say you're obsolete, just that some people want the machine to do absolutely everything automatically and that often means algorithmically. That's probably more effort than its worth in many cases, but sometimes it's well worth it.

A facebook feed or Google news have a fairly consistent layout, but what content goes into it is definitely chosen by an algorithm (IMHO a poor one at facebook) and the layout is probably tweaked by algorithms.

I'd only partially agree with this.

One of these things is not like the others: HTML and CSS are not programming languages; JavaScript is, and we're treating it like one now. As we move into a world of "client side applications" rather than "dynamic HTML," JS can be an order of magnitude more complex than it was just a few years ago. If you're going to use Angular or Backbone well, you're going to need to have a solid understanding of at least a few design patterns. You're probably going to need to know the difference between a queue and a stack and when you'd use one or the other (or neither), and you're going to need to be able to look at a problem and say "this is something I need recursion for." There's an awful lot of people who could make a good living as a web developer in 2004 who couldn't in 2014.

Having said all that, I think the current hiring process, particularly among Facebooks and Googles and startups that emulate them, is pretty heavily biased toward things one only learns in computer science degree programs (or when one is desperately floundering around trying to solve a "take home" interview puzzle). I don't want to claim that it's bad to know how to do directed graph cycle detection in your language of choice, but the need to do that is only going to come up in fairly specific circumstances -- and it's more important to know that someone you're hiring can find the information necessary to solve a problem and apply it than it is to know whether or not they have that information memorized.

(I'd also argue that demonstrating they can write readable, well-documented code that other people can actually work on is really important, but I almost never see that tested, oddly enough.)

Every job needs a spec. Every spec should inform the interviewer and the interviewee of the skills and competencies expected by the role, and therefore what will be brought up in the interview. Adding "everyone should be able to criteria unrelated to role" is madness

Does that mean I can't program? Ha ha ha, no. Does that mean I can't manipulate strings like a boss? Ha ha ha, no. I first reach for the language's tools, before I reach for regular expressions (the OP, I would first reach for doing a string search for {, and then one for }, from the rear if you want it greedy, and substringing what is in the middle; it's far less ambiguous, and any dev will know exactly what it does). Even when something ~technically~ takes a regex, if what I'm looking for is just a literal (as it often is; does this string contain X or not?), I don't need to 'know' regexes. So there's a LOT I can do without knowing regular expressions.

Meanwhile, I -have- needed to be able to recognize that something was running in O(n^2) time, and what I could do to optimize it to O(n). I -have- needed to implement my own search and bucket sort routines.

EDIT: Oh, wait, no, for the regex I'd need to escape the brackets, too. Etc. See? Now I have two problems.

EDIT: I don't care if you ever actually use regex in a program. You should learn regex just as a part of using a text editor.

For example, suppose I want to write a bit of repetitive code like this:

    x = x + vx * t + ax * t * t / 2;
    y = y + vy * t + ay * t * t / 2;
    z = z + vz * t + az * t * t / 2;

However, with regex search and replace, I first type

    x
    y
    z

And replace with the pattern: $1 = v$1 * t + a$1 * t * t / 2;

And now that I've been doing it for a little while, it's second nature. It's how I write lots of code.

Per your example, I code in a functional language. I'm even less likely to make a mistake if I just reuse the function, than I am to apply a regex.

The example is arbitrary. The point is, sometimes you end up writing repetitive code. Yes, even in functional languages.

And let's not forget the implementation different specifics (the need to specify multiline matching as a separate parameter into the parser, \ vs $ for string replacement, etc)

In general, if I'm writing a regex more complicated then "Hey, does this string match this literal?" I'm going to pull up a cheat sheet, because it avoids issues like that. But the number of times it makes sense to do that is really, really low.

It makes as much sense to me to say you should remember all ASCII character codes. Why? If you know how they work, and you're not using them enough to remember all of them automatically, it's not really a problem to just look them up if/when you need them.

Interestingly, my father, who is an applied mathematician, recently requested my help to understand regex and their relation to NFAs to help him with a mathematically related programming task.

But the CS background certainly doesn't hurt. Especially when it comes to stepping back and figuring out how to do the same stuff with less code (i.e. making good architectural decisions and finding the right frameworks for the job), instead of diving straight in and producing a giant mess of code, which is quite easy to do on the front-end if you're not careful. (Especially if you throw JQuery in the mix -- at that point you have a hearty soup of DOM manipulation code.)

If I were hiring a developer I'd ask them to write a simple app. Then I'd ask them to explain in as much detail as possible as to what happens when you type www.google.com in your address bar and the google homepage showing up.

I expect them to mention DNS lookups , IP Addresses , HTTP Requests , HTML parsing , HTTP methods etc

For the kind of frontend work you're used to doing: perhaps they won't.

For the kind of frontend work Google does -- you know, things like Gmail, Google Maps -- they most definitely will.

That's why Google asks those questions.

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.

I don't like puzzles either, but I think it's due to their restrictive nature and generally non-creative solution finding process. I prefer making puzzles over solving them.

I love being able to take a fuzzy idea, decompose it into discrete (and concrete parts) and then transposing that idea into programming language in such a way that not only solves the problem, but also communicates clearly what the original intent/idea/solution is.

I suspect what you're really asking is: why do so many companies thinking programming == solving puzzles?

The answer is that: (1) Based on what you're defining as a puzzle, they don't. (2) It is valuable skill (but it's also not the only skill).

-- (1) --

While there are stupid companies that ask "puzzles", this is not the norm at Google, Facebook, and similar companies. The "puzzles" listed at that Google link are basically fake. Link bait. While it's possible that each of those was asked at Google, I doubt that's where the author of that blog post got them from. They are certainly not representative of Google questions.

The "puzzle" questions you're referring to are really more like: - Design an algorithm to return a random node from a binary tree - Design an algorithm to find the nth number divisible by only 9, 13, and 15

You can define "puzzle" however you'd like, and I'm not going to engage in some debate over whose definition is "right." Doesn't matter (and there probably isn't a "right") here.

In the real questions asked at companies like Google, there's typically no sudden insight you need or trick in the wording. Rather, these questions are about working through a different problem and creating optimal solution (and recognizing tradeoffs along the way).

-- (2) --

That is an important skill for a developer. It is valuable for a developer to be good at that, and even enjoy it.

Maybe you don't care about making your solution better. Get it done. Get it out the door. Even if it's not perfect.

That probably makes you a less awesome developer, but it doesn't mean that you are necessarily a bad developer. There are lots of parts of being a "perfect" developer. - Enjoying testing. - Understanding what users want. - Architecting a system. - Understanding the lower level computer architecture. - Being a perfectionist. - Not being a perfectionist and knowing when you just need to get something done. - Knowing how to scale a large system. - and so on.

There are a TON of things here. No one has all of them.

You might be missing one of them, and it's a fairly important one. But it's not the only one.

I once worked [worked = prepping the startup for acquisition interviews] with a developer who was, honestly, quite stupid. He was exceptionally poor at developing good algorithms. His code however was correct.

He would be terrible at a company like Google. But at this company, he was very good. You see, he was very detail-oriented and thorough. If you want someone to write a correct bit of code for a very tedious and boring problem, he's your guy.

Is he a good developer? In the right role, yes.

This doesn't mean that Google is flawed for doing interviews this way - not at all. Their goal is not to hire all good developers. Their goal is to hire enough good people and to not hire bad people.

Problem solving/algorithmic skills and coding skills is a decent filter for that purpose.

However, without going into specifics. How does an interviewee handle/convince an interviewer with a preconceived solution?

For example, Interviewer A has an interview tomorrow and plans on asking this really slick problem that has one way of being solved well. A looks this way up and knows the ins and out of it. Now as an interviewee,if B were to come up with a 100 ways of handling the problem (starting from brute force) but fails to reach the "cool" solution because he has only 45 minutes of time . Do you think the interviewee would be considered a good candidate?

I'd say that the interviewer has hardly learnt anything about the candidate by asking such a problem. But then again, I could be wrong.

You could have a question that can really only be solved optimally one way but that still provides adequate room to demonstrate problem-solving skills (even without knowing the "slick trick"). Such a question could still be a reasonable question.

Of course, many questions with slick tricks aren't like that. The interviewers who ask these questions also tend to be worse, which exasperates the problem.

In the situation you described - the candidate might still be considered a good candidate. It depends what the interviewer is looking for.

I think it is rare for an interviewer to have a "cool" solution in mind and reject a better (or as good) solution. If they did I would be suspicious of the quality of the company.

I agree that Google doesn't make enough room for truly specialist skills. They should loosen up a bit.

You should also recognize that there are advantages to keeping the bar consistent. You essentially know that everyone you work with is smart and able to solve a problem well.

Hiring someone fairly unintelligent without any specialist knowledge into a company too big to allocate appropriate work wouldn't be a good idea. It works better in a smaller environment where you can ensure that he's getting appropriate work.

I would reorganize work so there is full-time tedious but necessary work to be done and put him on that. I would also use him for spec work, sort of like an in-house subcontractor. It works very well with electronic and mechanical engineers. I see no reason it would not work for software engineers.

> You should also recognize that there are advantages to keeping the bar consistent. You essentially know that everyone you work with is smart and able to solve a problem well.

Consistency can be taken too far, which I think Google does. It is one thing to only hire smart problem solvers. It is another thing to only hire people who are smart problem solvers in a specific domain and in a specific way. I feel like Google is trying to diversify their line of business but not diversify the types of problem solvers they hire.

> Hiring someone fairly unintelligent without any specialist knowledge into a company too big to allocate appropriate work wouldn't be a good idea. It works better in a smaller environment where you can ensure that he's getting appropriate work.

I would think it would be the opposite. A small company is less likely to have sufficient appropriate work to allocate.

Maybe so. But this isn't just any random small company. This is a specific 50-person company.

But it isn't actually a good interview strategy. I don't think any company should hire me over someone else due to puzzle solving. If I were to do an interview, I would probably leave out puzzles entirely.

This isn't really a strike against the company. This is just an indicator that they haven't had much experience at hiring people. They clearly are all copying from the same source, who was in turn copying from the books and magazines filled with puzzles and crosswords that I have been reading since I was old enough to do so.

I know from firsthand experience that the puzzles they are using are not the ones that I feel best correlate with coding ability. They are instead the ones that can be asked and solved quickly, with a single correct answer. They are generic filler, like "what's your greatest strength?" and "what's your worst weakness?" Those questions just show you that your interviewer does not know how to evaluate your fit for their job.

Programmers translate human problems into procedure-based solutions. They do not need to solve puzzles, except insofar as it can be puzzling to get stupid agents to perform complex tasks without step-by-step supervision from the principal.

Hacking is an essential part of the wider culture that formed around early programmers, but this culture is somewhat more inclusive than most. Certain activities draw forth the archetype. Safecracking, lockpicking, geocaching/orienteering, scavenger hunts, reverse engineering, deckbuilding strategy games, Rube Goldberg machines, drone photography, robotics, etc. That type of person is drawn to programming, not necessarily the other way around!

We don't need a cultural battle. I don't particularly care for "brogrammers" or "rockstars" or Nerf battles and foosball at the workplace, but I don't begrudge those types the right to call themselves programmers and to claim to work for technology companies.

But just as they should not be expected to solve brainteasers during their interviews, so too should I not be expected to play Ping Pong against a company founder during mine. I think monoculture is dangerous and foolhardy. Please, lets just judge our worth as programmers by how well we can write programs.

I also enjoy the competition with other compiler/language vendors to produce a better product.

Exactly. This is one of the main reasons for me as well - creating things without buying or manufacturing physical materials.

I tried again in college, with a much better design. The guy who ran the college machine shop (he built custom lab equipment for researchers) helped me a lot. It still took months. This time, it did run, but it took so much time it didn't satisfy my urge to create things - my designs ran far, far out ahead of any possibility of making them.

Not so with software!

Solving puzzles is nothing like programming to me. Programming to me means crafting your own pieces of the puzzle and being able to create something unique and beautiful.

Of course programming has some bad and boring sides. I would compare those to solving a jigsaw puzzle.

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.

"Organizational Skills Beat Algorithmic Wizardry" http://prog21.dadgum.com/177.html

I'm not really seeing the connection. Are they both just things you don't like?

Apparently in some alternate universe where design is not considered problem solving.

I am an antiprogrammer though.

What I like about programming is not problem solving — it’s design. How do I design an application in such a way that people will understand it?

Or, to put it another way, 'what I like about programming is not problem solving, it's problem solving'. The author somehow distorted the term 'problem solving' into 'puzzle solving'. Improving the usability of something is solving a problem. The author is tilting at windmills.

Do you program? Then you are a programmer. However, in some circles, where extremely complex problems need to be solved, they would say, " No ", because you can't do any of the programming required, and you'd be as useful to them as a rock, only less useful because you take air and food.

I play volleyball occasionally, but if I went to the olympic men's team, they would tell me I don't really play volleyball, I've not yet earned the right to say that I have.

It's a matter of skills and standards. In the right context I can call myself a car mechanic.. like if my car needs air the tires, but beyond that I'm not.

If you can program simple things on the web you can get away with calling yourself a programmer until you run into problems that make you realize you're not, like complex graphics algorithms.

I can cook food at home, but if I walk into a 3 michelin star restaurant and try to get a job, it's not like I'm going to write an article if they don't like my food. Boo hoo, they made me cook for them, how dare they? Whatever they're doing, it's working, so why knock the process that produces success when you can mimic it?