5 ms·
"A list containing the most frequent character." There's only one (not counting ties), so you want a single-item list? Or if 's' is the most frequent, because
by listenallyall 6y ago
"A list containing the most frequent character."
There's only one (not counting ties), so you want a single-item list? Or if 's' is the most frequent, because there are 5 of them, do you want [s, s, s, s, s]? Or since the list just needs to contain the most frequent character, seems like [r, s, t] would be correct as well. Now that I think about it, just returning the original string would have to contain the most frequent character. Also, do capital and lowercase of the same letter count as different characters?
Just seems like a rather unclear directive.
- ALittleLight 6y agoYes, it's supposed to be unclear because I expect the candidate to clarify the requirements. Jumping in to implementing something would be a bad move. Asking questions like these would be a good first step. I think of it as the FizzBuzz version of getting requirements for the thing you're supposed to be doing.
- listenallyall 6y agoAlright so give me the damn job! Covid has screwed me over, I'll start Monday
- dakiol 6y agoOh, I hate this. I get your point but as a potential new hire of your company I'm also interviewing you. This means that if you state a problem in a very ambiguous way (like you did in your first message) that's already a red flag for me. Sure, I don't expect 100% accuracy in your problem statement, but I don't expect either lazynnes for the sake of "let's see if the interviewer asks good questions before implementing anything". Expect professionalism from both parts.
- ip26 6y agoBoth sides have a point. Perhaps your parent runs a shop where ambiguous requirements are one of the biggest problems they face, whereas you prefer to work in roles where the requirements are already established and you focus on working within them.
- ALittleLight 6y agoThat's fine. I don't think every job is a fit for every person or vice versa. Your reaction is a positive one for my question - if you don't want to work where you have to clarify ambiguous requirements then you wouldn't want to work for the company I'm at, and it's best we figure that out as early as possible, like in the phone screen.
- lambdatronics 6y ago>Jumping in to implementing something would be a bad move. I would expect a skilled programmer to be be able to make intelligent inferences about the intended behavior in the face of ambiguous problem statements. FWIW, I would probably explain my reasoning as I went -- would you interrupt a candidate to say you'd rather see a different behavior (ex: my prototype would return a list with an empty string, but maybe you'd rather an empty list), or just silently judge them? Also, it look me about 2 minutes to produce a reasonable prototype -- maybe if the challenge were harder I'd expect someone to ask more questions up front, but in this case it's trivial to iterate. If the only thing you are testing for is the instinct to clarify unclear requirements, you'll surprise people who are used to the leetcode-style, thereby getting false negatives. It's just as much a trick question then, just in a different dimension.