[Stormbringer]

Getting them to write code is actually pretty good.

As for binary search, I wouldn't necessarily be able to bang it out in two hours in C, but I'd easily be able to bang it out in that time for any language I use regularly. And with sufficient testing I'd take a good stab at converting to C.

Though I agree sometimes it can be a coin toss. Once I was asked to write some code that would take dates as inputs and do something with them, it was supposed to take two hours and run on a bunch of test cases they gave you. I spent much more than two hours on it, nailed all the edge cases and boundary conditions that I could think of (basically nuked it from orbit) and turned in something which ran on their test cases and also a much longer list of much more challenging test cases. I got that job.

I missed one where they wanted something written by TDD. Unfortunately, I only know how to design something that works, I don't know how to fake a bad design that organically grows into a workable design. As above I nuked all the boundary conditions I could think of, but didn't get that job.

(Probably wouldn't have been happy there, my experience is that people who do TDD or automated unit testing have way too much faith in those forms of testing, and they neglect other forms of testing, so their actual net amount of testing is well below my standards. Things like: every single programmer I've ever worked with who claims that automated testing is sufficient has always produced code that when they claim they've finished the task it fails the eyeball test. E.g. you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it.)

[saranagati]

"Unfortunately, I only know how to design something that works, I don't know how to fake a bad design"

I was once given an interview project where they wanted to see how I did with their current code structure. They gave me this really horrible template of data that could never be used in the real world or for anything other than this project. I decided to restructure the template so I could make a useable application for it. After turning it in they were astonished that I reformatted it to look exactly like their production data and code.

The problem was that they didn't like that I didn't use certain basic function like require_once, autoloading or something else which i forget (this was in php). Instead I used c style programming in php which ends up being faster. They chastised me for not using the builtin php functions because they assumed they must be better and didn't hire me. The company (well whoever the recruiter worked for) sayed in the email that I just wasn't the right fit because I wasn't up to the skill level of the guy giving me the test and they needed someone "that good" because they were way behind on their deadline. I sent them an email back basically saying that they're retarded (in a MUCH nicer way of course) and showed them some benchmark results I made comparing the different ways of doing it (which showed my methods as being much more efficient).

[ceejayoz]

> Instead I used c style programming in php which ends up being faster.

Faster in performance, or faster to develop and maintain?

Most PHP apps I've come across have little need for CPU optimization. Not using built-in functions in those situations is likely to have no practical benefit except making it harder for other PHP devs to work with the code.

[saranagati]

actually easier to maintain and faster in performance. For example, instead of doing require_once() doing a

if ( ! defined('SOMEINCLUDE')) require('file.php');

then defining SOMEINCLUDE in file.php.

Only saves 3% if i remember correctly but when you're including a hundred includes it adds up and when your site is spread across 30+ load balanced web servers every bit counts. As far as it being easier to maintain, it's easier to debug this way if something goes wrong.

However for things where you've gotta build some huge function (or any function really that's more than a line or 2) to replace a built in for such a small gain in performance I would agree with you.

[zerd]

PHP leads to premature optimization. The root of the root of all evil.

[baddox]

I enjoyed your quip about TDD. I always thought the same thing about mandatory "rough drafts" in high school.

[mnutt]

By "other forms of testing" do you mean something like integration testing or do you mean manually checking things?

If you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it, then besides being poor coders, they're also poor testers. Since presumably the result that you're looking for is what they should be testing.

A while back I worked on a web app with developers who used TDD exclusively. In the entire time they worked there they never viewed the web app locally, but they had complete confidence in their changes and almost never broke anything. It was a bit extreme, but it worked for them and they were very effective.

[Stormbringer]

By other forms of testing I mean ALL other forms of testing. People sometimes fall into traps of thinking that their favourite form of testing is better than all the others, and so they neglect the others. I'm not talking about throwing out automated tests (for instance), they are great for doing regression testing amongst other things. But to only have your automated tests and nothing else seems like folly to me.

I take the point about them being poor coders and testers, though one of them was very highly regarded as a programmer (he presented well). The thing with testing is that you cannot predict everything in advance. Even with full code coverage you cannot cover every path through the code, and as soon as your code escapes into userland all sorts of whacky interactions can take place. The last, and best defence is to actually run the code and see what it does. your eye will pick up problems you never would have otherwise predicted.

With respect to the excellence of your TDD colleagues, perhaps they would have never broken it if they had less overwhelming confidence and more "well, it doesn't hurt to check"? That minor nitpick aside, I congratulate them. I think as programmers we should aspire/strive to be better than average, to be good at our art, and it sounds like they found a way that worked for them and fulfilled that goal.