I find that some of these kinds of things I tend to do infrequently enough that I will just look up how to do it for a given language, even if I work in that language quite a bit. It takes very little time to look up the best practice on stackoverflow these days.
If I were at an interview, and I didn't know how to do something, I would just define my own function for it and use that as part of my demonstration. Then if necessary, I could implement any such utility function from first principles if I really had to. Though I figure that most of the time, in an interview the goal would be to use such functions as part of solving some broader problem, and the details of implementation wouldn't need to be in scope...
Writing a utility function signature and moving on is a solid interview tip. It's one of the tips I give during an interview if the candidate isn't sure how to do something. I tell them to think at a higher level, create a function signature, and leave the body blank.
There's a difference between what you do infrequently at work, and what comes up during an interview. It's all about time during an interview. I would never punish somebody for not knowing the advanced stuff, or even forgetting the basics, it happens. However, every slip costs valuable time. I find that knowing this type of info is what is helping candidates make it through interviews -- since they spend all of their time thinking at a high-level on the important parts of the problem.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I find that some of these kinds of things I tend to do infrequently enough that I will just look up how to do it for a given language, even if I work in that language quite a bit. It takes very little time to look up the best practice on stackoverflow these days.
If I were at an interview, and I didn't know how to do something, I would just define my own function for it and use that as part of my demonstration. Then if necessary, I could implement any such utility function from first principles if I really had to. Though I figure that most of the time, in an interview the goal would be to use such functions as part of solving some broader problem, and the details of implementation wouldn't need to be in scope...
Writing a utility function signature and moving on is a solid interview tip. It's one of the tips I give during an interview if the candidate isn't sure how to do something. I tell them to think at a higher level, create a function signature, and leave the body blank.
There's a difference between what you do infrequently at work, and what comes up during an interview. It's all about time during an interview. I would never punish somebody for not knowing the advanced stuff, or even forgetting the basics, it happens. However, every slip costs valuable time. I find that knowing this type of info is what is helping candidates make it through interviews -- since they spend all of their time thinking at a high-level on the important parts of the problem.