Having fun on a technical test

I guess it’s not a secret: I’m looking for a job, either short-term or long-term, so I put my CV on a few websites. I got called by head-hunters twice this week: once for a contract to start on Monday (I’m busy until the end of September/the beginning of October so I told ’em I couldn’t start full-time until then) and one to start a bit later.

The second (first one to call, actually) is for a position that looks a lot like the one I have at Optel, but they wanted two references and wanted me to take a tech test on C++. That was fun.

I had 90 minutes to do the tech test they sent me by E-mail. The test was only ten pages, 12 questions, one of which was improving a piece of some of the ugliest code I’ve ever seen – uglier even than the code I put on the tech test I wrote for Optel (and that’s hard to beat) but with less diversity in its errors (so actually easier than the code I put on my tech test): the code simply had one fundamental flaw from which most others followed – and a few minor style errors that could be dangerous if overlooked.

There was another question on the test that was more fun, though: a description of a function muck like strtok, but not allowed to change the input string and, unlike strtok, it had to be re-entrant. Of course, there’s a whole slew of ways to implement that, so I picked two – one using boost::tokenizer and one not using it – and implemented them both.

Tech tests, IMO, are an excellent forum to show off. In fact, they’re one of the few forums where you should show off – the others being, um…, I’ll let you think of that. According to the description, I had ten minutes to write the code for the function. I wrote the version using Boost in two minutes, the version without Boost in four – so I wrote both within the ten minutes. If I had taken the four remaining minutes, I could easily have spit out another two versions – but there’s a limit to showing off.

Thinking back, I think I may have over-done it a bit: I was pretty pedantic on the first few questions of the test, sometimes going into the details of the language a bit more than was asked, and I made a point of using both english and french to respond to different questions – being an immigrant, people expect me to speak english but not french, so I showed off on that too.

Now, I’ll just have to go back to being my “humble” self again 🙂

About rlc

Software Analyst in embedded systems and C++, C and VHDL developer, I specialize in security, communications protocols and time synchronization, and am interested in concurrency, generic meta-programming and functional programming and their practical applications. I take a pragmatic approach to project management, focusing on the management of risk and scope. I have over two decades of experience as a software professional and a background in science.
This entry was posted in Business, Opinions, Software. Bookmark the permalink.

One Response to Having fun on a technical test

  1. I should perhaps clarify something:

    (…) improving a piece of some of the ugliest code I’ve ever seen – uglier even than the code I put on the tech test I wrote for Optel (…)

    One of the goals of a technical test is to put ugly code in it and have the candidate correct it, so it is to be expected for code on a tech test – at least the code to be corrected – to be ugly: to manage memory badly, to not handle exceptions properly, to not implement copy constructors and assignment operators properly, etc. etc. For the tech test I wrote for Optel, I took the existing test, which contained some pretty dismal code to begin with, and made it quite a bit worse, introducing all kinds of errors some of which were very hard to find.

    Now, unless I missed a few errors – which is, of course, possible – the code I had on the tech test I spoke about in this article didn’t contain as many different errors as the code I put in my tech test, but it did contain a lot more of them. IMO, this basically means it’s a good test (especially if I missed a few errors: the more errors I miss, the better the test). There is no intent here to “dis” the authors of the test 🙂

Comments are closed.