Disheartened

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}

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"

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.

AlmightyCushion

Turbulent Bill wrote: »

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.

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.

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.

Turbulent Bill

AlmightyCushion wrote: »

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.