• bvs23bkv33 (unregistered)

    wtf is eleventh point in Joel's Test? to see that candidate makes indents with tabs instead of spaces, and decline his application?

  • Hans (unregistered)

    What about a one-line requirement?

     Requires IE7

    And this at a time when IE10 was already (just) available. And with "requires" I mean: refuses to work in other browsers and crashes IE8+ unless it is specifically told to downgrade.

  • my name (unregistered) in reply to bvs23bkv33

    Well, apart from bizzfuzz, which is tolerable, I just don't understand why the always come up with coding questions. If it's just about employed Technologies, ok, but an interview is not the right setting for determining your coding skills

  • bvs23bkv33 (unregistered) in reply to Hans

    +-3 versions of browser does not matter at all, like in chrome and mozilla

  • RLB (unregistered) in reply to bvs23bkv33

    The entire Joel Test is broken. Individual points in it are sensible, but most of them are far from universally optimal and literally not a single one of them is universally applicable. But then, the bloke used to work for Microsoft. I don't get why he is put on such a pedestal by so many hackers who ought to know better.

  • Murray (unregistered) in reply to RLB

    literally not a single one of them is universally applicable

    Not even this one?

    > Do you use source control?

    OK, most are not universal. So what? It's still a useful set of points. The biggest problem with it is that if at an interview you ask "Do you use source control?", the people you are talking to might take that as an insult.

  • bvs23bkv33 (unregistered) in reply to Murray

    "I use SCCS" should be considered acceptable answer to this point

  • dpm (unregistered) in reply to Murray

    might take it as an insult

    so ask "Which source control do you use?" along with "how do you build?". If either of those are an insult, you can confidently get up and leave.

  • Jaloopa (unregistered) in reply to dpm

    so ask "Which source control do you use?" along with "how do you build?". If either of those are an insult, you can confidently get up and leave.

    It also gives you a chance to get up and leave if they say "Git"

  • someone (unregistered) in reply to RLB

    I must say, "10 or lower" = "serious problems" doesn't seem... quite right. Apparently if a small team doesn't do a daily build and don't get random coworkers to try their stuff, their system is seriously problematic.

  • (nodebb)

    bvs23bkv33, if you think that's the point of point 11, it would have screened out you, and thus fulfilled its purpose.

  • Developer Dude (google) in reply to Murray

    Too bad, so sad. If they have experience at more than one org, they will know why that is my first question. The second is do they have unit tests and to have them explain what they think a unit test is (believe it or not, my current gig told me they did write unit tests, but it turns out they did not have a clue what they were, so they really didn't). Third question would be do they do automatic nightly builds (we still don't - after 7 years). Fourth would be do the nightly builds run the unit tests. Then I would ask would dev process they use and ask them to explain it (most orgs I have worked at that say they do agile, don't really do agile).

    Addendum 2018-08-02 10:13: BTW - I rate us at about a 7 out of 12, and that is being generous.

  • Murray (unregistered) in reply to Developer Dude

    Let me guess. By unit tests do they mean a GUI where you can call methods interactively and play around? I used to work at such a place.

    If by unit tests they mean some other kind of automated tests, they still deserve partial credit.

  • (nodebb)

    in only 8 lines.

    I only see 7 lines of 'code' there.

  • eric bloedow (unregistered)

    i can't help but think of an old story on this site, "the record-breaking score" or something like that: someone rated a company -2 in the Joel test!

  • siciac (unregistered) in reply to someone

    Apparently if a small team doesn't do a daily build and

    Why aren't they using one of dozens of continuous integration services? I set that up as one of the first things when I start a new repo, even on personal projects.

    don't get random coworkers to try their stuff, their system is seriously problematic.

    Again, even with personal projects, I'll shoot an email to a friend to test it out. Have you used software that looks like garbage or is confusing? Lack of usability testing is why.

  • Sigh (unregistered) in reply to PJH

    8 lines counts the file's name.

  • Pedantic Programmer (unregistered) in reply to PJH

    You are not counting the implicit newline at the end on Windows......

  • Venoym (unregistered)

    Man... most of the comments here are missing the entire point of the Joel test... and the fact that you must tailor it to the level of the shop. Any small shop will be missing a couple of those... but if you only score a 2 or 3... run! Please people, you exemplify the TRWTF by not having enough imagination to be able to use a tongue-in-cheek informal test on a development house...

  • Duck of New York (unregistered) in reply to RLB

    "Dur hur micro$loth" Microsoft's internal tooling is fantastic, and nobody should be surprised since (1) it has been a dev tools company from day one (2) it has unlimited right to use its own software (3) it has cash to license whatever third party tools might be useful.

  • Worf (unregistered) in reply to RLB

    A lot of them are universally applicable. Source control for starters. As is single-command builds (it's not hard to write a script). And yes, I've had a super complex script that in order to produce the final builds did a ton of steps. And even then things got even more automated to even build the test files for running the tests.

    And the test is ancient by modern standards (August 9, 2000), which means we've learned a lot in the past 18 years (nightly builds moved on to continuous integration). At least the first 4 are univerally applicable to any project, big or small that you intend to keep going for more than a day (as in, anything that will need maintenance).

  • Duck of New York (unregistered)

    One awful feature of the Joel test is that it encourages people to obtain yes or no answers. I got bitten by that hard once, when I found out that "we have unit tests" can easily mean "each program has one test, maybe." Never leave it at yes or no. Ask "what/how?" not "do you?"

  • Mobile user (unregistered)

    Apparently the layout of the sitte has changed, and now the nav bar takes up half the screen on mobile when viewing horizontally (so as to try to see preformatted code without scrolling back and forth)!

  • ooOOooGa (unregistered) in reply to PJH

    Let me see here....

    Yeah. Line 8 is an empty line, so HTML would have eaten it in its whitespace compression.

  • someone (unregistered) in reply to siciac

    Sure, it's ''bad'', but it's not "seriously problematic."

  • (nodebb) in reply to Worf

    I agree for all of the points, more or less, but item 7: "Do you have a spec?" Specifications takes a long time to write, will invariable be interpreted in differently, doesn't convey what the customer wants and will be outdated long before the software is delivered.

    That's why we have scrum these days.

  • Jaloopa (unregistered) in reply to eric bloedow


  • Little Bobby Tables (unregistered)

    Been trying to get our guys to take on board 5 for as long as I've worked here. But whenever I've raised the issue I get what is tantamount to Argumentum Ad Baculum: "It's none of your business! If you don't like our strategy, you're welcome to apply your misbegotten ideas at a different company." Sigh.

    Meanwhile, the multipage document specifying the full details of all the workrounds we've had to implement to get round the bugs is developing a life of its own.

  • Bzzzt (unregistered) in reply to Little Bobby Tables

    Time to get the hell out of that toxic environment.

  • Zenith (unregistered)

    Every place I've ever worked has failed the Joel Test. All but one was never-ending chaos and failure.

    That said, exceptional developers can mitigate some of these points. I think that's where I have a problem with so many processes. They're (ostensibly) designed to herd lousy developers in some direction or another. Good programmers, though, are just handcuffed (at best).

    The place that I liked didn't have automated builds, or daily builds, or a schedule, or the best tools, or dedicated testers, and I didn't write a line of code in the interview. Yet, somehow, my team developed code that should've been the envy of the commonwealth. No 8-hour deployments, no public outages, no daily emergency sprints, no newspaper exposes full of user complaints, no mysterious data losses, etc. About the only time we had issues was when other systems, developed by idiots that lied about everything (what good is a spec if none of it is true?), took down everything they had their tentacles into (AD, backups, firewall, FTP, etc).

    The place I work now has automated builds but they don't share a schedule and never ever goes back to fix anything. I'm looking but I'm batting about .100 as far as jobs go at this point in my career so I've adopted a somewhat disinterested attitude towards the industry.

Leave a comment on “The Mike Test”

Log In or post as a guest

Replying to comment #:

« Return to Article