[nieksand]

I would classify atoi() as a mediocre question at best.

I would look for the following in a "fine" question:

1. It demonstrates knowledge of fundamental concepts or techniques.

2. It lets you distinguish the quality of answer/implementation rather than just works or doesn't.

3. It leads to natural follow-up questions that can demonstrate the candidate's knowledge or expertise.

4. It does not require fiddly code. (e.g. linked list pointer twiddling questions: they aren't hard but are easy to muck up with a stranger staring at you.)

5. If its unrelated to what candidates normally work on, the question should not hinge on knowing a specialized "trick" to change difficulty from hard to easy.

Atoi under that criteria:

1. Does not show much interesting besides a basic understanding of decimal numbers and writing loops.

2. It's hard to imagine much variability in the quality of responses. A "real" atoi implementation is not interview material: https://github.com/golang/go/blob/master/src/strconv/atoi.go...

3. I guess you could follow it up with questions on testing and error handling. Nothing super interesting comes to mind, but that could be lack of imagination on my part.

4. It meets this criteria.

5. It meets this criteria.

Perhaps you have some particularly good way of posing an atoi() question.

[actually_a_dog]

I like your criteria, so I'm going to put a question I used to ask in interviews up against it: let's write (and test) the world's worst JSON encoder, in TDD style. The ultimate goal of this question was to end up with a function (in Python, when I was asking it) that could JSON encode primitive types, along with lists and dicts. No fancy stuff about trying to figure out what to do with general objects or anything. No worrying about circular references. No tricks. Just take a Python data structure as input and output a string representing a valid JSON encoding of that data structure.

1. You need to know how to write a half decent test case, and, for full credit, how to write a recursive function. Check.

2. As alluded to in the previous point, we can judge the quality of the test cases. So, I think this is at least a provisional pass.

3. A really good candidate can talk about issues like Unicode, how to handle or avoid stack overflow, dealing with circular references, maybe think a bit about optimizations.

4. Unless you consider recursion to be "fiddly code," then we meet this criterion as well. I allowed people to use str() or repr() to convert things to strings, so there was no incidental difficulty there, either.

5. Nope, no tricks. Just use recursion.

So, it looks to me like I had a pretty okay question.

Anybody take issue with any of what I wrote, or have any suggestions for making it a better question?

[nieksand]

It sounds like a pretty good question to me.

As a follow up you could scope out how familiar the candidate is with alternate encoding options and what the trade-offs and use cases are. (BSON/MessagePack, Protobuf/Avro/Thift, FlatBuffers/Cap'nProto).

[google234123]

You are right it’s not the best, but I think it’s a fine starting/warm up question for a C or C++ interview. Atoi can make for a fun discussion just because error handling is so bad in the standard c version. The most common output value is also the same as the return value for an error: 0. I think some versions set the Errno global on failure, can’t recall.

There is definitely room for 2x to 3x performance improvements on the implementation you linked by changing the main loop to not have each iteration depend upon the result of the previous iteration.