Comment by ten_fingers | Hacker News Reader

Comment by ten_fingers | Hacker News Reader

Right at first I would have two remarks. The first remark has to do with how to describe such a problem. The second remark points to what appears to be a serious error in the problem description.

My first remark would be that the problem statement is not in any natural language.

E.g., what is the role of the many instances of the character '#'? Those instances are not in a natural language.

E.g., what is the token

'add1'?

That token is not in my Webster's dictionary, and I have been given no way to parse it.

E.g.,

"increments items in an array matching specified value"

is not a sentence.

E.g., "param:" is not English.

Continuing, it is not clear what meant by an 'array'. So, we do not know the value of the smallest subscript or the largest or how to determine these.

Next the terms

"from left-to-right (forward)"

and

"right-to-left (backward)"

are undefined and require a reader to guess. A careful guess would want to know if the computer was big endian or little endian.

Finally, one might object to "most optimal" since, really, something is 'optimal' or it is not so that 'most' is superfluous.

Here is another way to start to write the problem statement:

Suppose you are given positive integer n, and suppose for i = 1, 2, ..., n, you are given an integer x(i).

Etc.

Lesson: In computing, clear communications are important. Those communications should be in a natural language, e.g., English.

My second remark would be to consider the part of the problem statement:

n < 0 means increment up to n occurrences of val from right-to-left (backward)

So, with this statement, if n < 0, then there is nothing to do since we cannot do something a negative number of times.

So it appears that what was intended was:

n < 0 means increment up to -n occurrences of val from right-to-left (backward)

You are being overly pedantic here.

One of the great things about two people from any reasonably mature field communicating with each other is that they can take advantage of widely-agreed-upon shorthand. Nearly everyone coming in for a programming interview in 2012 will understand that the '#' character is often used for non-executable program meta-data, that functions are often named with tokens such as 'add1', that 'param:' typically means a function parameter with a description of its value following the colon, what an 'array' is, how subscripts work with them, and what is meant by the terms left-to-right, forward, right-to-left, and backward (regardless of endian-ness, the inclusion of which is sort of humorous since our hypothetical interviewee has, up to this point, been assumed to be completely ignorant of programming-related terms). You go on to suggest defining the problem in terms of short-hand from a more mature, but less specifically relevant field, which I would argue would actually be well understood by fewer potential interviewees.

I do agree with you that it should probably be pointed out that the number of occurrences should be stated as the absolute value of 'n', rather than just 'n', but this would become obvious very quickly when the candidate starts asking clarification questions.

I was trying to be simple, elementary, and easy to read! But my comment was not at all "pedantic"!

Even with all the context you suggested, the problem statement is just not very clear, and, in computing, computer science, and software, that lack of clarity is not a small point.

Put more bluntly, there is no excuse, and in serious software, especially for embedded systems, there is no role, for abbreviations that are on or over the line into gibberish. You are correct that such gibberish is common in software; my point is that we should not do that and should object.

Yes, in my suggested problem statement, I used notation common in mathematics. Still, the math community still says that such writing is English. GOOD.

Here is a big point: Computer science, computing, and software have no good substitute for such use of how mathematics is written. There is a partial substitute in practice if assume a particular programming language.

The error of n instead of -n or the absolute value of n is small but is an example of a huge point: A subroutine needs a description. A subroutine is precisely something and should have a precise description. The problem here is so simple we can get by with being imprecise as you suggest, but computing is not limited to such simple routines, and the complicated ones also need precise descriptions. Net, we need to write precise descriptions. Knuth did this in TACP (yes, I abbreviate!); it really is possible.

For assuming that 'add1' means an argument 1 passed to a function add is asking a lot even just in the context of software.

In passing a constant to a function there will be the issue, that should be addressed, of passing 'by value' or 'by reference'. In Fortran a constant is passed by reference with all the problems, side effects, and surprises there unto appertaining! We can't yet assume that Fortran is buried!

If my work does well and I start to hire, I will give a lot of weight to people who are good at reading and writing technical material and will prefer that they know how to read and write abstract math. For learning Visual Basic .NET, a book of code samples and a one week class should be able to do a lot. Net, I'm questioning if I should require new hires for programming to know any 'computing' at all.

Reply on news.ycombinator.com