• Ikke (unregistered)

    long l = Long.parseLong((String)o); will not work in java

  • Quite (unregistered)

    Ugh. Code like that gives we the millies.

  • bvs23bkv33 (unregistered)

    excuse me, you said that something non-trivial will take time? so, I assume, you wanted something non-trivial in under two hours? you got what you wish

  • Anonymous (unregistered)

    The Java oneliner you gave does not consider daylight saving.

  • (nodebb) in reply to Anonymous

    It also just calculates the distance, and is, therefore, not a sufficient answer to the question, "are these two dates 90 days or more apart?".

    More (?) accuracy would be obtained by flattening away the time part of each "date and time" object, so that both are approximately midnight (subject to loopiness if the end or beginning of summer time is in between them - using "gmtime" or similar gets around that), and computing the difference of that. (I'm sure we can imagine a situation on the border where the two dateandtimes are closer than 90*24 hours apart, but on dates that are 90 days apart. 11:30 pm on the earlier date and 12:30 am on the later date, that sort of thing.)

    Which goes back to the thing that has been said more than once. Manipulating dates is hard.

  • Hannes (unregistered)

    Dates are hard. Many programmers (or "non-programming goats"?) don't know how to handle them. All too often I have seen something like

    string s1 = DateTime.Now.ToString();
string days = s1.Substring(0,2);
string months = s2.Substring(3,2);
...

    which will fail hard if your date format doesn't happen to be DD.MM.YYYY (and most likely I have a "off by one error" in there, which will fail even harder).

  • Hannes (unregistered) in reply to Hannes

    And of course the biggest fail is the use of the undeclared variable 's2'.

  • fristy (unregistered)

    "is a true", eh?

  • William Furr (google)

    TRWTF is Dave posting interview candidates' code on The Daily WTF instead of respecting their privacy. Unqualified developer flubs coding exam, news at 11.

  • Brian (unregistered)

    My team uses an online testing service as part of our interview process for developers, although it's really just intended to weed out the bad candidates. I'm one of the people who reviews the submissions. Turns out, that's one of the more amusing parts of my job - if it wasn't a huge breach of confidentiality, those tests could result in a font of entries on this site.

  • St.Grimes (unregistered) in reply to William Furr

    Dave did not post the code of the candidate, assuming the candidate grabbed it from ideone.com/5dXeu6 . The fragment on ideone is declared public, so there is no privacy to respect.

  • kktkkr (unregistered)

    Technically, a hardcoded calendar of the past 30 years of dates counts as a two-line solution, and one that's conceivably doable in 2 hours.

  • Baboon (unregistered) in reply to Anonymous

    Yeah, I would have used Instant from java 8's time API or even LocalDate, LocalDateTime etc, it's even cleaner than the TimeUnit side of things imo. If java 8 wasn't available I would have used Joda time and if that wasn't valid well something like Remy did or even the horrible Calendar class ...

  • Brian Boorman (google) in reply to William Furr

    I'm sorry, how was someone's privacy breached? Can you identify Steve from this code? If posting someone's code is a privacy breach, then this website is in trouble, because all of the code posted here as WTFs was written by some hapless programmer.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Steve_The_Cynic

    I'd create some sort of datediff function, and put a comment in it that it really needs to normalize both dates to midnight 00:00 first. Because the purpose of interview code is to show that you know WTF you're doing, not to produce polished production code.

    And yes, Remy, that code is inredibly bad.

  • RELE (unregistered)

    Hmmm. So what we're sayin' here is: Programmers are weak at dating.

  • DrPepper (unregistered)

    Truely a bad candidate. As part of the test, the developer has access to the internet. About the 3rd line of that method, an alarm should have gone off saying "wait -- this is just too complicated for such a simple problem. Look -- I don't know java; and would certainly look on stack overflow for a bit of code to calculate the number of days between two dates; but if I found that code, the first thing I'd think is -- no, too complicated, keep looking.

    So what you're really testing in any situation like this is: does the person understand the basic concepts enough to formulate a good stack overflow search; does he know enough/have enough experience to weed out the solutions that don't really apply; can he take the provided solution and adapt it to the situation at hand. If no to any of these, then you reject him. If yes, then you have at least enough there to begin an intelligent conversation about whether you want to hire him or not.

  • Melvar (unregistered)

    “if two dates are within 90 days of each other” isn’t even an adequate specification. What sort of day? 86400 seconds? 86400 non-leap seconds? The span between two times where the local time is the same? Strictly calendar days, ignoring smaller units entirely?

  • Ex-lurker (unregistered) in reply to Melvar

    Well, duh! The candidate has the interviewer right in front of them and can ask for clarifications as much as they need. I would need to know these details if I were creating a solution, but I don't need them to appreciate the WTF on display. Do you think the submission should bore us to death with details that do not impact our understanding of the fact that the candidate was as clueless as a door?

  • Dave (unregistered) in reply to Melvar

    Come off it. That's a bit like saying you can go around referring to 'average' things and meaning the modal average. If you don't specify. average is the mean. Similarly, there's no need to specify what a day is unless you're using some abnormal specification. It's 24 hours.

    But hey, if I was interviewing you, you'd not have got the job. And you probably wouldn't have taken it anyway.

  • Mag (unregistered)

    "Interviewing developers always poses a challenge. You can’t rate their skills at writing code without seeing them write code, and most of the code they’ve written probably belongs to someone else."

    Isn't this true for most white collar professions? But I have never heard of a mechanical engineer that has to spend hours of their spare time drawing simple gear boxes for each job he/she applies for...

    I see the problem with not knowing how good the applicant is, but I don't think that a coding test is the solution. Problem solving during interview though, where the applicant gets to show how they think and tell the interviewer how they would solve the problem by using their experience and knowledge.

  • gnasher729 (unregistered)

    "Within 90 days" is tricky and most likely cannot be answered without having a calendar for your time zone. Of course you can say "is the absolute difference at most 90 x 86400 seconds", but that can be wrong when daylight savings time changes. I'd say convert to time components using the calendar of your local time zone. Then you can either ask "are the day components within 90 days of each other". If they are exactly 90 days apart, then you can take hours, minutes, seconds into account. Still interesting when DST changes and you have the same hour twice.

  • jimshatt (unregistered)

    Am I the only one who kinda appreciates the code he/she wrote?

    saw that it calculated the difference in every possible unit
    This is false, it (tries to) calculate the difference in order of time unit size, where the remaining time difference falls through to the lesser time unit. So you'd be able to say something like "The difference between T1 and T2 is 7 days, 2 hours, .., .. and 2 nanoseconds".

    I'm not sure whether EnumSet.allOf(TimeUnit.class) gives the enumset in a particular order, though it may be. He should have used TimeUnit.values() instead.

    PS: F*ck reCAPTHA! I wish I were a robot!

  • Harris M (unregistered) in reply to William Furr

    Is it really a problem? It's completely anonymous.

  • Harris M (unregistered) in reply to Ikke

    I agree, Long can't be casted to String unless it's the primitive version 'long'.

    The correct code would be:

    long l = Long.ParseLong(o.toString());

  • Harris M (unregistered) in reply to gnasher729

    That's why you use java.time to convert everything to a ZonedDateTime and then check the difference.

  • Hannes (unregistered)

    As I've said, dates are hard... if I ask a candidate to calculate if two given dates are 90 days apart and the candidate asks "what do you mean by 'day'? Is it 86400 seconds?" then I wouldn't even bother further interviewing this candidate...

  • Quite (unregistered) in reply to Hannes

    "Solar day or sidereal day?" "I don't know! AARRRGH!"

    With apologies to Monty Python.

  • (nodebb) in reply to Brian Boorman

    sometimes WTFes are hidden in Opensource SW, too so not all WTFes are hidden from public view

  • Douglas (unregistered) in reply to Steve_The_Cynic

    I'm the submitter for this one.

    By the standards we expect for a two hour timed exercise, that one-liner is perfectly acceptable, and even considered good. As for time zones, time of day, etc., in the problem specification it is clear that none of that is relevant - the dates are provided as text in yyyy-MM-dd format in the input. Code that parses that format into Date objects is also provided. I don't think I want to know what this guy would have done if he'd had to start with the raw input string.

  • TDK (unregistered)

    Okay, I've interviewed literally thousands of candidates over the nearly three decades I've been a professional software developer, and been interviewed hundreds of times, for companies that interview in the most brutal high-tech fashion out there, such as Amazon, VMware, Google, and others. When I am interviewing a candidate, I have a choice of a few standard coding questions that I always ask. My goto question has a very high correlation of prediction, which is to say, every candidate who failed to get a good solution failed the rest of their interview loop, and every candidate who aced it also aced the rest of the loop, got an offer, and when they accepted, went on to be exceptional programmers.

    So I am a firm believer in making candidates write code as part of an interview loop. I even make phone screen candidates write code. If you can't write code, at the end of the day, you're not going to succeed as a developer.

    PS My coding question is a whiteboard coding question, that can be completed in 15-20 minutes, tops, if it gets completed at all, and yet has never failed as an indicator of success. So it is possible to do this in an interview, and derive good data therefrom.

  • Alan (unregistered)

    I honestly think any dev that doesn't have at least a small amount of code on GitHub or something similar isn't really dedicated enough to be great at it. I'd say hiring based on open source contributions is fairly reasonable these days.

  • Amy (unregistered) in reply to TDK

    Would you mind giving an overview of what the coding question is?

  • I'm not a robot (unregistered) in reply to Hannes

    Dates are not timestamps. For dates there's only one sensible interpretation (and it has nothing to do with seconds). If you'd abandon the interview for candidates who understand that, then you're probably doing them a favour.

  • James (unregistered) in reply to Alan

    I honestly think any dev that doesn't have at least a small amount of code on GitHub or something similar isn't really dedicated enough to be great at it.

    I consider myself to be fairly dedicated to the art. But none of the non-trivial code I or my colleagues write can be be posted anywhere without risk of prosecution. So, not having open-source code on Git is not a sign of a lack of dedication to software development.

  • TDK (unregistered) in reply to Amy

    Well, my phone screen question is a variation on computing the Fibonacci sequence, and my whiteboard question concerns text classification. I'll not be more specific than that, as I'd still like to use my questions in actual interviews. On the other hand, if I ever finish writing my Pocket Guide to High-Tech Interviewing, I'll probably spill the beans there.

  • Amy (unregistered) in reply to TDK

    I'll be sure to buy it if you do

  • Erin (unregistered) in reply to Alan

    Other than some group open source things on github, it seems like half of the repos are people copying each other's homework in some sort of code-centipede of bad programming.

    I spend far too much time coding for work, for side projects, for school, and for teaching - not of which can go in a public repo - to create made up projects for a portfolio. We also end up having to write entirely new assignments every semester as students can't seem to accept that their homework isn't a public portfolio (and who wants to read homework? It's boring. Nobody saves their English essays for interview fodder, and most of the CS homework in repos is of that level - not semester long capstones or similar.)

Leave a comment on “Flubbed Buzz”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article