Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi all,
Vanilla are planning an update to the site on April 24th (next Wednesday). It is a major PHP8 update which is expected to boost performance across the site. The site will be down from 7pm and it is expected to take about an hour to complete. We appreciate your patience during the update.
Thanks all.

Disheartened

124»

Comments

  • Banned (with Prison Access) Posts: 186 ✭✭Kickstart1.3


    Pelvis wrote: »
    This sounds good! So figured I'd give it a try. Here's my effort, it seems to work well. Anyone else want to try a few more test cases to confirm?
    Try {1, 7, 5, 5, 5, 5}


  • Registered Users Posts: 107 ✭✭MFZ


    Talisman wrote: »
    Should work in all modern browsers.
    earliest([5, 4, 3, 2, 1, 0])
    "01:23:45"
    
    Google Chrome 71.0:
    earliest([0,0,0,7,8,9])
    "00:07:89"


  • Registered Users Posts: 1,621 ✭✭✭Turbulent Bill


    Not a developer, but if I was in the OP's shoes I'd interpret "6 digits" as seconds and go from there:

    1 day = 86400s
    Sort digits into lowest int, fail if greater than 86400.
    Otherwise divide int by 3600 to get hrs, remainder by 60 for mins, balance is s

    Might be a bit cheaty, but if the task was ambiguous maybe the employer was looking for lateral thinking.


  • Moderators, Education Moderators, Technology & Internet Moderators Posts: 35,042 Mod ✭✭✭✭AlmightyCushion


    Not a developer, but if I was in the OP's shoes I'd interpret "6 digits" as seconds and go from there:

    1 day = 86400s
    Sort digits into lowest int, fail if greater than 86400.
    Otherwise divide int by 3600 to get hrs, remainder by 60 for mins, balance is s

    Might be a bit cheaty, but if the task was ambiguous maybe the employer was looking for lateral thinking.

    I'd be wary about doing that in a job interview scenario. They might think you're being smart (not in a good way) or they might think you misunderstood the requirements which also isn't a good thing.


  • Closed Accounts Posts: 22,651 ✭✭✭✭beauf


    The more you look at there are other questions. The output is HH:MM:SS but do we assume the input is. I think most of would.
    But you never know with interview questions. Interviews sometimes don't accept alternative interpretations even if they are valid.
    You have to work out what they were expecting.


  • Advertisement
  • Registered Users Posts: 5,995 ✭✭✭Talisman


    beauf wrote: »
    The more you look at there are other questions. The output is HH:MM:SS but do we assume the input is. I think most of would.
    But you never know with interview questions. Interviews sometimes don't accept alternative interpretations even if they are valid.
    You have to work out what they were expecting.
    Sometimes the definition of the problem is ambiguous to see if the candidate will tease out the actual requirements or will they make assumptions and work from those. That's why the candidate should always ask questions before diving into solving the problem.

    The best analogy I can give is a student not taking the time to read through a question on an exam paper and instead of answering what was asked they provide the answer to the question they have constructed in their head. The answer provided may be perfectly valid for the question in their head but if it has nothing to do with the actual question asked, the examiner cannot award the student any marks for the answer provided.

    In an interview you can and should always ask for clarification if you aren't certain about an aspect of the problem provided or at least state your assumptions and gauge the reaction.


  • Registered Users Posts: 1,621 ✭✭✭Turbulent Bill


    I'd be wary about doing that in a job interview scenario. They might think you're being smart (not in a good way) or they might think you misunderstood the requirements which also isn't a good thing.

    Maybe, but if you're upfront about the assumptions you're making ("digit definition isn't clear, so I'm assuming X, to be verified by customer" etc.) I'd see that as a positive. You've recognised that there's at least potential ambiguity, come up with a solution based on a reasonable assumption, and shown that the assumption needs to be checked. Better than blindly assuming HH:MM:SS format, or sitting on your hands because the requirements are unclear.


Advertisement