jump to navigation

The Geek Doesn’t Wear Prada November 29, 2006

Posted by Imran Ghory in job interviews, recruitment, Software development.
44 comments

It’s a rare occurrence to find geeks debating fashion and what to wear, but that’s what happened a few days ago when thedailywtf ran a story about job interviews

Most of the participants fell into one of two camps, the “pro-suits” and the “anti-suits”. The pro-suits generally took the opinion that “a job interview is a formal event and as such not dressing formally would be inappropriate and disrespectful” . The anti-suit camp generally fell into “developers should be judged on skill alone, after all what developer wears a suit anyway ?”

Sadly both camps missed the point completely. There is no “golden bullet”. There is no definite answer about what you should wear to a job interview. Different companies have different cultures, different countries even more so.

The single most important factor to consider when deciding what to wear is what other interview candidates will wear. When you meet meet your interviewer for the first time they’ll be comparing you to every other candidate they’ve seen. And if there’s anything about you that’s significantly different from everyone else that’s what’s going to stick in their mind as their first impression of you. Not your skills, not your lovely personality, but what you’re wearing.

If you’re the only candidate who’s turned up in a suit or a t-shirt you’ll be remembered as “the suit guy” or the “the t-shirt guy”, not because the interviewer disapproves of your dress sense (although they may do), but simply because that’s how human memory works.

The key point I’m making is that you don’t want to be remembered for what you wearing, you want to be remembered for being “the Boost wizard” or “the smalltalk guy” or at least something that has some relevance to the job.

Of course if you’ve just been called for an interview you may have no-idea what other candidates have worn in the past. But it doesn’t harm to ask, HR or your contact at the firm will almost certainly be willing to tell you what the dress code is both for day-to-day work and for the interview. Or if you’re reluctant to ask them then ask around, ask your friends what they would wear for an interview at that company.

But if you’re really stuck then I’d suggest dressing over-smartly. There are far more companies that will reject you for looking “unprofessional” then there are companies that will reject you for being “too smart”. Plus it’s a lot easier to take off a tie and undo your top button to become more casual then it is to make t-shirt and jeans look professional

Advertisements

Who needs good software developers anyway ? August 7, 2006

Posted by Imran Ghory in recruitment, Software development.
83 comments

One of the interesting replies to my previous post on developer recruitment was a claim that shocked many of my other readers – the essence is captured in the following quote: “For most of the developers working in the industry, coding is about cut and paste“. Shocking maybe – but realistically it’s true.

The majority of developers working today are working on fairly straight forward systems doing fairly simplistic things like tying up a gui to a database. For the most parts that means you don’t need to be a good software developer, broadly speaking it doesn’t matter if you don’t have an in-depth understanding of your programming language or lack a formal comp sci education.

However there is another world, a much more fun world in my opinion although others may disagree. A world in which you need to have expertise in your language, where you really need to understand what exactly your code is doing and often how it’s achieving it. A world in which you need to be a good software developer to survive and get the job done.

I’d argue that this world is fundamentally composed of two types of companies:

  • Those for whom their software is their competitive advantage
  • Those which have complex mission critical systems

The second type in some ways a subset of the first; in that if those companies didn’t have good software developers not only would they lack competitive advantage, but that they wouldn’t even stand a chance in the market.

One easy way to identify who needs good software developers is to look at who’s hiring good software developers. And one way to do that is to look at their interviewing practices. If a company gives a heavy technical drilling, expecting the candidate to write code, debug on paper, discuss algorithms then chances are that they want good software developers. But because good software developers come at a premium it’s a reasonable inference that a company which has a solid technical interview process actually needs good software developers.

If you’re interviewing for a company that falls into one of the two types I’ve mentioned above and they’re not probing you technically, then I’d suggest running away very very quickly. Chances are they’re not going to be around much longer….

So who actually are these companies who need good software developers then ? – well going on the earlier assumption that generally only companies that need good software developers would try to hire them: if we could find a list of companies that had tough technical interviews that would probably be a reasonable approximation. Fortunately there are several such lists the most prominent of which is probably Gayle Laakmann’s site on tech interviews.

Going through the companies on Laakmann’s site they all nicely fit into the two fundamental types I mentioned above. A lot of them are software companies either shrink-wrap (Microsoft, Apple, etc.) or software-as-a-service (Amazon, Expedia) in which the strength of their software is their primary market advantage – the benefit to them of good developers is obvious. Some are defence firms (Boeing) or similar where robust and reliable mission critical systems doesn’t give them competitive advantage but are a simple requirement if they want to operate in the market.

And some like the financial firms (Goldman Sachs) fall into both types – high-quality, reliable and efficient software is required to maintain advantage over your competitors. When a few milliseconds delay in executing a trade can be the difference between profit and loss paying a small premium for the best developers is a no-brainer. And on the complex system side you can’t have developers building sophisticated multi-threaded trading systems. You really do need to have an in-depth understanding of issues such as synchronicity and floating point number implementations when you have literally billions of dollars at stake.

So when you next see someone commenting on developer recruitment, pause for a minute and consider which of the two worlds they come from. If their opinion shocks you it may be because they do come from another world. Metaphorically anyway.

Tech CVs: the lies ! the lies ! July 19, 2006

Posted by Imran Ghory in recruitment, Software development.
32 comments

There’s nothing more likely to get you thrown out of a job interview than it becoming obvious that you’ve lied on your CV, coming a close second is coming across as completely incompetent in your area of expertise.

So you would hope that it would be common knowledge not to put things down on your CV which you don’t know about. I can’t imagine taxi firms get applicants who think having sat in a car qualifies them at drivers, or people claiming to be French translators due to having slept through 5 years of french lessons at school.

Yet IT seems somehow different…there seems to be an obsession with having magic words on yor CV. As if having “J2EE” or “XML” will turn you from a Clark Kent candidate into a Superman candidate. Sure having those keywords may get you that interview, but once they find out you’ve lied there’s a good chance you’ll get blacklisted from that company forever.

And if you’re applying through a recruiter say good-bye to all those juicy high-paying jobs sitting on her desk. One of the most important part of a recruitment consultant’s job is maintaining a good relationship with her clients (the companies, not you, who do you think pays her?) – and if you’re pissing her clients off she’s not going to risk letting you interview with her best clients.

For some reason the worst offenders seem to be the newly graduated, i’ve had graduates claiming C experience not knowing what “printf” is, I’ve had graduates with 3 years Java experience not knowing what a JVM is. And to take the mick I’ve had a candidate who put Python on their CV who when asked about it answered “Oh I don’t know Python – but I was planning to learn it when I wrote my CV”.

I’ve come to the conclusion that one of the main problems is that candidates especially junior ones might think that they know more than they do, simply because it’s hard to tell how much you don’t know unless you’ve been in an enviroment surrounded with people who know a lot more than you.

So to help solve the problem I’ve come up with a list of common tech skills and languages people put on their CV along with the minimum level of knowledge I’d expect to associate with it:

  • Programming in general
    • Understand the different types of programming languages and their advantages and disadvantages.
    • Understand variables, function calls and recursion.
    • Understand the difference between assignment by reference and value and passing by reference and value. And how this applies to your favourite language.
  • Object-Orientation
    • Understand the key concepts of OO – especially encapsulation, inheritence, polymorphism.
    • Know the advantages/disadvantages of inheritence versus composition.
  • Design Patterns
    • Know the easier design patterns iterators, singletons, etc.
    • Have knowledge of the gang of four book.
  • C
    • Know standard I/O, know how to read parameters from the command line
    • Understand pointers
    • Understand dynamic memory allocation
    • Understand the scope of variables
    • Understand the difference between preprocessor, compiler and linker
  • C++
    • All of the C stuff
    • Understand the virtual keyword
    • Know what parts of a class a compiler will provide by default and what the default ones do.
    • Know what a constructor/destructor are and when they’re called.
  • Java
    • Know what the JVM is and what it does
    • Understand roughly how garbage collection works
  • Python
    • Understand the importance of indenting
    • Why some numbers are immutable
    • Tuples, sets, dictionaries,etc.
  • XML
    • The advantages/disadvantages of using XML (say versus a fixed-length encoding system)
    • The advantages/disadvantages of the SAX and DOM models
    • How to parse XML using your favourite languages/libraries
    • Know what XSLT is
  • Unix
    • Know how to use the console for day-to-day file handling
    • Understand piping and redirection of inputs/outputs

I think that’s enough brain-dumping for now….but I’m sure I’ll be back to add some more later on.

So if any of those had you thinking “do I really know the stuff on my CV” perhaps it’s time to brush-up your word processing skills….