6 ms·
If they are over-complicating it, then you are not communicating the problem well. Maybe change the problem to an array of ints. It's the same solution but you
by Gunax 4y ago
If they are over-complicating it, then you are not communicating the problem well.
Maybe change the problem to an array of ints. It's the same solution but you will not have anyone asking about UTF and text direction.
- justinlloyd 4y ago> “Please program a .contains(), without using .indexOf(), and no need to optimize anything, I’m not looking for anything fancy.” If that is the statement that was given to me, I would clarify the interviewer is not looking for optimal run-time or anything fancy like handling UTF-8 or right-to-left -- because an interviewer often says "nothing fancy" and then will nitpick the fact the code you wrote on the whiteboard doesn't follow precise PEP-8 standards or use idiomatic Ruby or doesn't adhere to the latest C++-23 syntax -- and then I would write a total of six or seven lines of code C code (variable declarations, return statement, etc), which would be two for-loops and an if-statement. I could probably get that down to just the for-loops if I want to be "fancy" and bury the conditional in the for-loop test itself. I think the real problem is, we tend, in an interview situation, to overthink what the interviewer is asking for at times. I see this in a lot of take home tests people do when applying to companies, then ask me if they have done enough before submitting to the company they are interviewing with. That said, I've dealt with interviewers that give the take home test, or the white board test, and then complain that the candidate didn't go far enough by adding on un-asked for stuff. "Going the extra mile" as they say. The crux of the problem is the vagaries of interviewing style.
- weaksauce 4y agoI think a lot could be mitigated if interviewers supplied a take home test and a different example take home test with an answer that showed the format of what they were actually looking for with depth/complexity/testing/etc.