Sucky Job Applicants



  • It never fails to amaze me, the number of cowboy software developers out there!
    I'm not talking hat-wearing, man-loving, horse-riding, wild wild west types. I'm talking about people with supposedly great credentials and years of experience that once you scratch the surface you realise they are complete bullshitters that have absolutely no idea what they are doing.

    Quick background: I'm working on a large real-time order processing system. It's a very modularised design with loads of multi-threaded components talking to each other over a third party protocol.
    We are currently hiring. There are two many examples of bad applicants we've had but I think this one sums it up quite eloquently -
    Contractor, 10 years commercial experience C++. Knew all the theory - could talk very well about layered and distributed applications, gave some nice examples. Then came the technical test - the technical test starts with some embarressingly simple questions as a warm-up.
    1) Is XML case-sensitive?
    Pauses for a moment No. (ok, I think, that's not good but maybe he's a bit old-school and avoids the new buzzwords, maybe I can work with this)

    2) Describe the difference between the access modifiers Public, Private and Protected.
    Public means everyone can call it, Private is private and Protected means that it's thead-safe.

    *** Stunned silence ***

    We then built an online test with quite basic questions to weed out the complete cowboys before bringing them in. The scores, from supposed professionals, were so low that one of our guys took the test and randomly clicked on answers. He beat four of the 9 applicants.



  • @Phill said:

    one of our guys took the test and randomly clicked on answers. He beat four of the 9 applicants.


    Golden!

    The Reject:
    "I'm sorry, but we've decided not to make use of your services. Instead, we made a call to the local zoo, and they agreed to lend us three monkeys for the job."



  • I think the implementation of many XML parsers used to be case-insensitive – not an entirely unforgivable mistake. (I guess it was because they grew from HTML parsers.)

    ... Protected means that it's thead-safe. Haha! I wish :P ... to meander a little off topic, I'd love a language where threading and parallel coding was more 'designed in'. This not knowing about 'protected' is in the comments for the 'real' WTF today too; I don't get how you can think of yourself as a programmer these days without understanding OO concepts.

    [Our simulated monkey] beat four of the 9 applicants. Yikes. It's a damn good thing your company actually tests people before hiring, huh? There's a future WTF (or five) you've palmed off to someone else right there.



  • This post scared me because I just had an interview with a guy named Phil a couple of days ago.
    But the job description has nothing to do with the position I applied for.



  • @Bob Janova said:

    I'd love a language where threading and parallel coding was more 'designed in'.




    Sounds like you're asking for Java... synchronized
    is a built-in language keyword that, when used in a  method's
    signature, automatically locks the method so that only one thread may
    execute the method at a time.



  • @Phill said:

    Private is private


    Well, sounds like he knows his stuff!  Private certainly is private.



  • Not exactly, endergt. Yeah, synchronized (even if that 'z' gets me every time!) is quite nice, but I'm thinking more of parallelising loops and so on. It's quite a low level of subtlety, locking a whole method. (You can do that in C# too, by lock(something){ ... }-ing the whole method body. In fact I do really like lock for making data access threadsafe.)

    The whole structure of C family languages (well, scalar languages in general, I guess) isn't really set up for this. I.e., consider:

    for(int i = 0; i < thing.length; i++)
    doStuff(thing[i]);
    There's no way the compiler can tell that this can be run in parallel (because doStuff might have side effects). What is needed is doStuff(each thing), where each explicitly doesn't guarantee execution order. Then a multi-core computer can know it can run each doStuff() call in a separate place.


  • @Bob Janova said:

    Not exactly, endergt. Yeah, synchronized (even if that 'z' gets me every time!) is quite nice, but I'm thinking more of parallelising loops and so on. It's quite a low level of subtlety, locking a whole method. (You can do that in C# too, by lock(something){ ... }-ing the whole method body. In fact I do really like lock for making data access threadsafe.)


    You're looking for languages like Parallel C. There's quite a few of them. They're commonly only used in computationally intensive research (where it is necessary to push the envelope of computing power, and performance penalties like Java are sniggered about and then forgotten), and tend to be somewhat... complex. Mechanisms for smarter parallelism than threading are a well-established field in computer science. Language features to exploit these mechanisms are a subject of current research; nobody has come up with a really good solution yet.

    Meanwhile, languages like Java continue to offer clumsy misfeatures that don't do what people think, in order to get 'thread support' into the marketing literature. Java's synchronized keyword isn't really a huge help; getting thread-safety to work in non-trivial Java programs is about as difficult as it is using pthreads in C (that is, subtle, complicated, and you probably got it wrong) - but alas, many Java programmers do not realise this, and write code that they think is thread-safe but isn't. It's so complicated that many books have been written on the subject. About the best thing you can say about Java's thread safety is that it isn't any worse than C - the language may have its good points, but this is not one of them.



  • @Bob Janova said:

    .. Protected means that it's thead-safe.
    Haha! I wish :P ... to meander a little off topic, I'd love a language where threading and parallel coding was more 'designed in'. This not knowing about 'protected' is in the comments for the 'real' WTF today too; I don't get how you can think of yourself as a programmer these days without understanding OO concepts.


    One particularly trendy example of such a language is Erlang: http://erlang.org/

    It lets you write threaded code by using message-passing, instead of shared memory. No locks.



  • @Bob Janova said:

    I'd love a language where threading and parallel coding was more 'designed in'.

    Try functional programing.
    If you're comming from a .net background F# will sound good.



  • @asuffield said:

    Meanwhile, languages like Java continue to offer clumsy misfeatures that don't do what people think, in order to get 'thread support' into the marketing literature. Java's synchronized keyword isn't really a huge help; getting thread-safety to work in non-trivial Java programs is about as difficult as it is using pthreads in C (that is, subtle, complicated, and you probably got it wrong) - but alas, many Java programmers do not realise this, and write code that they think is thread-safe but isn't. It's so complicated that many books have been written on the subject. About the best thing you can say about Java's thread safety is that it isn't any worse than C - the language may have its good points, but this is not one of them.

    I really don't want to kick off a language war here, however, having done multi-threaded apps in C, C++, and Java (haven't worked with .NET yet), I really must disagree. The built in thread support in Java is pretty sound and reasonably easy to use, especially since the new concurrency package as of Java 5. This does not mean you don't have to understand threading issues, just like everything else you have to understand how it works to get it right. I doubt general purpose programming languages will ever be able to get the same level of multi-threading ease as languages like Parallel C, but it's far from a 'clumsy misfeature'. The synchronized keyword is a bit of a heavy hammer, but it works (in newer JVM's there were some bugs in some of the 1.4 release and earlier IIRC. The new concurrency package provides some really smooth low level locking abilities and the ability to write lock free code in some cases.

    Like I said I really don't want to start a language war, but if you have some specific criticisms I'd like to hear them.



  • @Bob Janova said:

    I think the implementation of many XML parsers used to be case-insensitive – not an entirely unforgivable mistake.

    Yes it is, I utterly loathe XML and yet I know that it's case sensitive for tags and attributes, and it's written black on white in the frigging spec too.

    @Bob Janova said:
    Haha! I wish :P ... to meander a little off topic, I'd love a language where threading and parallel coding was more 'designed in'.

    One more citation for Erlang, the language with concurrency (and highly concurrent applications) in mind, as well as very high reliability and soft real-time (it's used in telecom switches for example). The language's syntax is fairly simple, yet the language has extremely powerful features (share-nothing processes and message passing built into the language, pattern matching, tail-call optimization, dynamic implicit typing, tuples, high order functions, ...) and one of the language's unofficial mottos is "if you've got problems, then you're not using enough processes".

    May stump you a bit though, because it's a (nearly) pure functional language, which is very alien for a C++/Java/C# dev.



  • I have to agree with the sentiment of the original post. Hiring is just plain depressing. I think
    I've gradually become more able to spot BS at interview and have become
    a firm believer in getting applicants to solve small problems in a
    relevant language during the interview. Something that you know should
    take five minutes and that you have solved reasonably recently yourself
    is a good idea.



    However when I was younger and was involved in interviewing people that
    were supposedly more experienced than myself I tended towards asking a
    lot of questions that, looking back, were really just testing that the
    applicant knew the right buzzwords and could define a few key concepts.
    Been burned a few times like this... he/she seemed so good at interview
    but there ideas of design are Heath Robinson nightmares that are badly
    coded (shudders remembering a few).



Log in to reply