OT: CS education gone wrong (Was: Re: TDD is BS?)

[Jacob Carlborg]

On 2013-06-21 17:14, H. S. Teoh wrote:

> Heh, at my job, we're looking for skill in specific languages, so
> candidates are explicitly asked to write C code. And this is done not in
> an interview setting (which puts too much pressure on the candidate --
> can *you* write code in front of interviewers without panicking at least
> a bit?), but in a classroom setting. Though, granted, when *I* had to go
> through the procedure, it felt like I was taking my CS final exams all
> over again. Not exactly a pleasant experience. :-P

I had four, one hour each, interviews in one afternoon. Afterwards my 
brain was basically fried.

> That's the sign of a poorly-chosen test question. The kind of question I
> like to use doesn't focus on nitpicky details like that, but on actual
> algorithms or domain-specific knowledge, like showing that the candidate
> understands bit operations, pointer arithmetic, and stuff like that. On
> that note, it's rather shocking how few candidates know how to use
> malloc() and free() correctly...

I guess I managed to avoid what they actually wanted to test.

> That's not to say the tests my employer gives have only "good"
> questions, though; there are some that basically do what you describe:
> "please re-implement strstr(), please concatenate strings without using
> strcat()", and the like. When I was involved in hiring, I usually ignore
> these questions when evaluating the candidate, or cut them a lot of
> slack.

I can also understand that it not that easy to create meaningful tests 
like these.

> But I do have a slightly evil streak when it comes to technical tests...
> once I wrote a Javascript question that requires the candidate to
> evaluate what a piece of code does, that involves several nested
> closures and variable shadowing. We hired one of the (very) few
> candidates who actually got that question right, and she turned out to
> be an excellent coder.

Hehe.

> Well, I don't think the point of the test is to prove that you can write
> code that's *superior* to the standard library, but that you *can* write
> non-trivial functionality from ground up.

Yeah, I guess it's hard to find meaningful tests.

> Well, that's a new one. :-P  Our tests are administered as pen-and-paper
> tests. Not unlike CS final exams, unfortunately. :-/

I hate pen-and-paper tests too. I remember those from the university. I 
understand that they don't want you to have access to a computer with 
access to the internet or a compiler. But come on, can I at least get a 
simple text editor. Half of the time I spend on erasing code because I 
cannot insert new code in the middle of existing code. Then also writing 
those annoying curly braces (the actual symbols) which I never get right.

> Actually, we instruct HR to provide the standard C library manuals if
> candidates ask for it.

That's generous.

> There *are* some unfair questions that expect you
> to know, e.g., the exact order of arguments to select() and stuff like
> that, but like I said, it's not HR who evaluates the tests, but the
> hiring managers, so it's up to our discretion how much weight we put on
> questions like that. We usually disregard minor mistakes like using the
> wrong order of arguments to qsort(), if the intent is clear. We don't
> (or at least I don't) just blindly look for the highest-scoring test and
> hire those candidates; I usually take the time to look at the code and
> ask, "why did they write it that way?  what does that show about their
> coding abilities?".

I guess we have different experiences.

-- 
/Jacob Carlborg