[SamReidHughes]

As far as I can tell, you are far away from @tptacek's post on hiring. He's saying to ignore the resume, have objectively evaluated work-sample tests. You're saying you want people to look at your resume, and that you're really good at talking about stuff. The problem with coding exercise portions of tech interviews (if I'm repeating him correctly) is that they're not as close a representation of actual work as possible, and that they're subjectively evaluated. The standard "tech interview" sits in between your camp and his.

[devplusplus]

I think we're both on the same page that the standard "tech interview" model is broken. I don't have a problem with doing work sample tests. I have a problem with contrived samples that aren't representative of my coding abilities.

My justification is that I have oodles of experience. I'm happy to prove it -- I just don't think generating an ASCII spiral is a good test of whether I am qualified or not.

[joeld42]

It's a screening question. If you make an ASCII spiral that doesn't mean you're qualified, but if you can't do that then you're certainly not.

[tptacek]

I cannot off the top of my head tell you how I'd draw an ASCII spiral. But I could tell you how to write a two-phase commit distributed lock, or a C compiler, or an ARM disassembler, or a link-state SPF routing protocol, or, obviously, most typical Rails apps. Am I certainly not qualified, or is that really just a super dumb question?

I don't know where you stand on it, by the way; attribute my hostility to the question, not yourself.

[patio11]

It seems to be a) of no obvious relevance to anything anyone has likely ever done before but b) shouldn't be too hard to sketch out on a piece of paper then turn into functioning code.

First question: can my spiral use only right angles? If so, this gets pretty radically easier.

I also think that if you just draw a grid on the paper in front of you, start at the center of it, and start trying to spiral one cell at a time using ASCII characters you know, you'll quickly find a pattern that can be conveniently coerced into code.

I'd actually code this to demonstrate but I feel like Thomas will be happier if I do code that matters for Starfighter instead.

[Jemaclus]

Indeed, I'd agree with both of you in that I can do a large number of other tasks off the top of my head, but not Tic-Tac-Toe, even though given a fair bit of time to do that "coercing", it's not extremely difficult. However, I'd also agree with kasey_junk's position that this type of problem doesn't quite measure what they think it does, and the "ease" of the problem is really irrelevant. What we should be looking at is the efficacy of the test: does it measure what we think it measures? Does it successfully differentiate between good and bad candidates?

Gonna kinda ramble off here for a second...

I have an intern at my day job now, and we're working through a task I've done a million times. I know how I'd do it, and I could finish the whole thing in about an hour, but I want him to go through all the steps on his own. He's been working on it for over a week, and today he came up with a bunch of possible solutions to a particular obstacle, and he said, "Which one is the right one to do?" And honestly, the answer is that there isn't one right way to go. All of those solutions will work, and at various times in the past, I've tried them all.

What I'm getting at is that I think OP is correct that getting the "right" answer isn't super important.

To take another rather poor analogy, look at Google Maps. If I type in "642 Harrison St, San Francisco, CA", then it drops me at a particular point on the map that just so happens to be an office building. There is no 644 Harrison St, but if I type it into Google, they drop a pin right next to the building, anyway. The interesting thing about this is that Google doesn't care exactly where the building is. Instead, they want to get me close enough to my destination that I can eyeball it and figure out the rest myself.

To put that another way, the "right" answer would be "there's no building here," but Google correctly identifies the problem as "how do I get to this physical spot?" and not "is this a real place?"

Likewise, in a lot of areas of life, not just programming and maps, getting the "right" answer isn't necessarily the only answer. For most things, if you get within a certain range, with a certain margin of error, then that's good enough. If you ask for a medium-rare steak and it comes out medium, it's still gonna taste good, just not perfect. If you run a marathon but wind up walking for 2 minutes in the middle of it, you still covered the distance, even though you technically only ran 98%. If you have a meeting at 3:00 and you arrive at 3:02 or 2:58, it's gonna be fine.

For most things, there's a certain amount of "close enough" that is acceptable.

Does it really matter if 644 Harrison St exists or not? Of course not. Google gets me to that location, and I am able to do the rest from there. Does it really matter if your ASCII spiral is perfect? No, but as long as you demonstrate your mastery of arrays and for-loops and basic algebra, you should pass the test.

At least, that's my two cents.

[emmett]

(Caveat: I think the existing interview process is fundamentally broken, but because asking people to code on a whiteboard is suboptimal not because the specific questions are wrong)

I've asked this specific question in interviews before, many times.

It's like a slightly harder version of FizzBuzz. It appears to have near perfect discrimination between "knows enough programming to use nested for loops with if-statements" and "does not". Programmers (good or bad), once the given the formal problem statement, solve it in under 20 minutes. People who don't actually really know how to program will never finish.

You might be imagining a slightly more difficult question, but it really is easy. It's an arbitrary coding challenge, sure, but one designed to not be tricky on purpose. The naive implementation works great.

[kasey_junk]

I'm willing to guess that question doesn't judge what you think it does.

First, I'd write down the specific things you are trying to determine with this question, and the metrics where by you could judge your employees after you've hired them on those things.

Second, I'd start collecting scores on that question (and all the others you do) and correlating them to "good" employees vs "bad" ones. That won't help you with the false negatives, but its usually enough to point out specifically terrible questions, of which the ASCII circle one is a doozy.

Drop it now, it's hurting your reputation with everyone who you ask it of.

(And if you aren't the originator/user of that question I apologize, substitute "they should" where appropriate)