In 1994 Eirik C. Eng and Haavard Nord established an elite company for the top one percent of the worlds coders. Its purpose was to create the greatest toolkit ever built. To ensure that the handful of coders recruited were the best the world had to offer - they initiated a hard and strenuous recruiting process. The process, if successful, would only allow the keepers of the lost art of software development to slip through the gates. It succeeded. Today, the World knows the company as Trolltech. The coders just call it: TOP CODE!
Actually, thats all just bulls#¤t. Except the thing about “1994″, and “greatest toolkit”, oh and “best the world had to offer” - yeah and the “lost art of software development” is kinda correct as well. Come to think of it - everything is true except the “TOP CODE” name.
As one of the guys doing a fair amount of recruiting for the development department in Trolltech I’ve come to see the typical pitfalls that our candidates fall into. And I was thinking, as a service to all of you thinking of applying, to give you some pointers of where you may go wrong too. BTW if I sound like an arrogant prick who thinks he is hot coder-shit, it’s because I work together with a bunch of people I KNOW are hot coder-shits, and therefore their hotness rubs off on me.
Candidate pitfall #1
The first typical mistake is that the candidate is not comfortable enough with his programming language. For the sake of argument let’s say we’re talking C++ here. It doesn’t take us long to figure out this point. We’ll ask some innocent questions about const member functions or some simple pointer juggling and the candidate will typically start to have problems. Why is this? Well - programming is a craft, and only through actually programming will you improve this craft. Normally if you’re right out of university (Norwegian ones anyways) you will not have had enough practice actually programming. Note: It’s perfectly OK if you don’t know C++ - what we’re looking for is someone with a thorough understanding of at least one programming language.
Candidate pitfall #2
The other typical mistake, is that the candidate is not comfortable around data types and algorithms. We’ll ask the candidate to compare a list and a vector, the pros and cons. We’ll ask whats the depth of a balanced binary tree, whats the run-time of bubble-sort. Then watch him fall to pieces
This is something you actually do learn at the university though - so no excuses here
Candidate pitfall #3
The last typical mistake is that the candidate lacks experience doing software design. The way we typically design classes and modules in Qt is using two people and a white board. Simple as that. During our recruitment process we let the candidates do the same - and observe them. A lot of the time a candidate might avoid pitfall #1 and #2, but then #3 comes along and they dive into it. Why so? I think it’s a bit of the same here as #1. Even with a university degree in computer science you might still never have done any object oriented design, and even less object oriented design in a team.
When I look at myself and how I avoided #1 and #3 I see that I got these skills outside my university courses:
- I had part-time and full-time software jobs.
- I had friends doing coding outside of class.
So, to summarize:
- Don’t be afraid to apply!
- Know your programming language.
- Know your data types and algorithms.
- Know how to design in a team.
BTW for any recent candidates: This is NOT about you. I just woke and felt inspired to write about recruitment.
So - if you think you’ve got it, or just want a free trip to Oslo (we pay for it), don’t hesitate: apply here!
12 Responses to “Top Code - “Ma’am the data in that MOC file is inaccurate.””
I don’t think that someone will get the top one percent of the world coders if he seeks only in the english-speaking subset…
Nice question list. and indeed reserved for a limited number of people. It makes me remind of the “The Guerrilla Guide to Interviewing” http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
Albinus: Good point - and of course, the opening should be read with a twist of irony ![]()
Th. Albinus: Assuming almost 1 billion people speak english, you probably won’t find everyone of the top 1% among these people, but you’ll find most. Computer Science is international; the world needs more extraordinary people that can communicate on all channels. That’s why we require excellent English skills.
Oh oh, I know English, I know English! Didn’t understand a word of what you said about that programming stuf, but I’d sure like a free trip to Oslo! Does it mean I can apply? ![]()
/me goes off to look up const member functions.. Somehow I’ve never felt the need to use them.
Oh, well that’s easy.
Albinus: You are partially right - english-speaking people are not everywhere, though people who do know software design and development know english good enough, at least they can read and write in english.
wow, these case-sensitive captchas are hard enough even for a human ![]()
Leo S: Const correctness is an essential part of writing good code. At the very least you’ll piss off developers who try to integrate their code with yours and have to add loads of const_cast’s.
That’s one thing I don’t get with Java. It is supposedly ’safer’ because you can’t have buffer overflows/segfaults, but it’s surely only safer in the sense that a crash isn’t usually a security vulnerability. It seems like crashes and bugs themselves would be even more common and hard to detect due to the weak typing, lack of const stuff etc. Consider:
class MoneyAmount
{
public MoneyAmount(int po, int pe)
{
pounds = po;
pence = pe;
}
public int pounds;
public int pence;
}
class Banknote
{
private MoneyAmount value;
public Banknote(int pounds, int pence)
{
if (pounds == 0 && pence == 0)
return; // value uninitialised.
value = new MoneyAmount(pounds, pence);
}
public void setPounds(int p)
{
val.pounds = p;
}
public int getPounds() // Should be const.
{
// Ok I can’t think of a plausible mistake in this context, but it happens!
++pounds;
return val.pounds;
}
}
Or am I just behind the times and Java has constness, static typing and statically allocated variables? The main criticisms of C++ (easy to mess up strings, arrays, and pointers) have been non-issues ever since the STL.
End of Java rant.
thanks for the tips
(although right now I feel like I’m gonna be in school forever!)
the one and only time I had a real job interview, I quickly discovered just how much I rely on google. I know I learnt all sorts of fascinating things about pointer math and const whatsits, but unless I actually *use* things on a regular basis they just drop from my mind. heck, not having a computer open cripples me even more. I know how to *find* information, so the only time I bother keeping it in my head is when exams are looming.
…of course, there are benefits to having knowledge readily available in your mind. when I was writing addons for a certain game, I read the full documentation for the scripting language from top to bottom several times, and knew the language inside-out. it made it really easy to answer people’s code questions, write stuff quickly and get it mostly-right the first time, etc
I think I might have grokked the language better than some of the actual developers.
and somehow I had completely forgotten this until your blog post jogged my memory. maybe I should start reading the qt docs from a-z now ![]()
@Tim Yeah I need to use that more often. Of course your claim that Java is weakly typed makes me highly doubt your opinion as a good developer.