I Hate Puzzles: Am I Still a Programmer? (2011)

I've met a copy-and-paste C++ developer myself, though he ended up losing the job eventually.

Blew me away to discover this when I sat down to help him debug an algorithm that he had, in fact (correctly) copied from somewhere else, but then he'd slaughtered it trying to "make it work." Most of the fixes involved reverting his changes, and then making a couple minor modifications that WERE actually necessary.

He'd been fighting with it for a couple days. I had it streaming sound in about 15 minutes. Based on his words to me after the fact, he was really just not understanding what the code was doing. Pretty much at all.

That said, he did have some good insight into user interface design. I could see that he did have some important skill sets, but understanding how to manipulate memory in C was not one of them. Whether he was a "successful" developer is debatable, since he didn't hold the position, though.

I'm sure that "copy and paste" developers exist for most common languages. I've heard from several sources that finding a non-copy-and-paste developer who uses JavaScript is a real rarity. I've also been told that Google in particular is looking for that skill set. Sounds like you could write you own ticket. :)

Jigsaw puzzles are repetitive and inefficient. They may be the antithesis of good programming. While they might be fun as a distraction, they are hardly a marker of programming ability. I don't like the idea that people have to have "smart person hobbies" to be coders. Playing music, poker, shooting pool, or racing could be equally as relevant.

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?

Does a lack of interest in solving (mechanical) puzzles imply you're a weak programmer?

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.

This. A thousand times this. After going through the rounds of interviews at various companies as someone who's not particularly strong in the algorithm department, I've often felt frustrated. I think my strengths are in making good sensible design decisions for a given problem, and being able to manage the complexity of a system; but I've never been able to really show that in an interview. I've seen work from colleagues that solves a simple problem, but makes extensive use of obscure C++ template features. Maybe they were great at algorithms, maybe they weren't, but they certainly weren't capable of coming up with the simplest solution.

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 think the purpose of the puzzle is one of resource management.

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.