If I were the interviewer and you provided your solution you would get points off for your solution for using a for loop instead of an ES5 Array method. Could it be the one-liner annoys you more than the hypothetical interviewer?
Asking somebody to implement Array.prototype.reduce would be absurd IMO after the interviewee had used it to successfully answer your question. And to handcuff somebody by making them use for loops is also absurd. Neither of these are real-world scenarios, and it would seem to me you are just either trying raise the bar impossibly high, or wanting to show off your seemingly superior abilities or such. In which case I'd make the decision then and there I wouldn't want to work for you. Actually a much better real world scenario would be to ask somebody how to re-implement something that relied on excessive chaining. Oftentimes the answer is reduce, but I could also live with a for loop, as long as the original data set is looped over only once.
That also depends on the company. For some array.reduce might be too simple, but for others might be a good example.
For example if, say you applied for Google and asked about to implement array.reduce you would be really lucky to have that. And if you posted your experience in Leetcode for example, everyone would ask if you are real.
You would not know what the actual bar is until you done some research or took the test.
However I think that's not the point. The main point is how you react to new change of requirements and what is your attitude towards this.
Because we don't want to test how to implement a Promise but their usage.
That would not stop anyone from asking you how Promises could be implemented, but that would fall out of the scope of the warmup. It would be a more challenging test for a more advanced scenario.
Again, "moving the goalposts" -- "we don't want to test how to implement a Promise but their usage". Just substitute "Array.prototype.reverse" or "Array.prototype.reduce" and then re-consider your prior arguments and whether what you had suggested "would fall out of the scope" of the warmup.
So far I think you've been very unreasonable/illogical. These are not good traits in a developer/developer-interviewer and I now know beyond a doubt there is no way I'd take a position with you, and I might even just terminate the interview abruptly. With 20 years experience I consider myself to be interviewing the company just as much as vice versa.
Feel free to have the last word but I won't be reading/responding.
There is no hidden agenda. Again if you are condescending or arrogant with someone asking a simple question trying to understand how you think and communicate then you are responsible for yourself and your actions. Good luck with that attitude.
BTW. It only took a few answers on my part in a popular platform like dev.to to understand that from your reactions and I'm a total stranger trying to share my opinion. I'm not even a real interviewer or hiring anyone. How good is that for you?
You stated this was an exercise to warm up specifically for a JS interview.
There are many ways to solve the problem - each demonstrating different areas of knowledge. A good interviewer would appreciate the knowledge and use of modern JS techniques (arrow function, spread operator) - since, after all, it is a JS specific interview.
Why would you ask someone to re-implement array.reverse in a test that is about Javascript? Any implementation you could make is likely to be slower than the built in one. That question would belong in a test about algorithms
I would say that any live coding interview questions tend to test you about algorithmic thinking. It's not only about the language. Also, If you can manage to code a dynamic programming task but not a simpler one like array reverse then the interviewer might think something is fishy here.
If that is what they want to test, they should ask for such. As this is framed as a JS interview it would be in the candidate's best interests to highlight their skill in Javascript over general programming ability unless asked otherwise.
If I were interviewing for a JS position, and the candidate's solution proceeded to reinvent the wheel, I would question why they had done it that way. On the basis of that answer I would decide whether or not they're a good fit for a specifically JS position
It is framed as a Javascript interview but it's not all about Javascript. Javascript may be hot now, but not tomorrow. Algorithms stay longer. That is the mindset.
Unfortunately, not all interviewers are kind to tell you what kinds of tests they will ask you. They could ask you anything. The idea is to be prepared as much as possible.
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.
To reverse a string why not just...
FYI I've moved the focus here:
dev.to/theodesp/a-word-on-technica...
Try not to aggregate the interviewer. They need to see more than one liners. If you wrote that for example I would ask you to implement
array.reverseIf I were the interviewer and you provided your solution you would get points off for your solution for using a for loop instead of an ES5 Array method. Could it be the one-liner annoys you more than the hypothetical interviewer?
In that case I would ask you to implement
array.reduce.Or to spice things up I would ask you not to use any of:
array.reduceorarray.reverse.So the intention here is that interviewer would like to see how you write plain old for/while loops and how you explain the code as you write it.
Asking somebody to implement Array.prototype.reduce would be absurd IMO after the interviewee had used it to successfully answer your question. And to handcuff somebody by making them use for loops is also absurd. Neither of these are real-world scenarios, and it would seem to me you are just either trying raise the bar impossibly high, or wanting to show off your seemingly superior abilities or such. In which case I'd make the decision then and there I wouldn't want to work for you. Actually a much better real world scenario would be to ask somebody how to re-implement something that relied on excessive chaining. Oftentimes the answer is reduce, but I could also live with a for loop, as long as the original data set is looped over only once.
That also depends on the company. For some
array.reducemight be too simple, but for others might be a good example.For example if, say you applied for Google and asked about to implement
array.reduceyou would be really lucky to have that. And if you posted your experience in Leetcode for example, everyone would ask if you are real.You would not know what the actual bar is until you done some research or took the test.
However I think that's not the point. The main point is how you react to new change of requirements and what is your attitude towards this.
That is the most difficult test.
You keep "moving the goalposts" IMO. Have a nice day.
By the same logic, why are you returning a built in Promise in example number 5 rather than your own implementation of a Promise?
Because we don't want to test how to implement a Promise but their usage.
That would not stop anyone from asking you how Promises could be implemented, but that would fall out of the scope of the warmup. It would be a more challenging test for a more advanced scenario.
See for example:
promisejs.org/implementing/
Again, "moving the goalposts" -- "we don't want to test how to implement a Promise but their usage". Just substitute "Array.prototype.reverse" or "Array.prototype.reduce" and then re-consider your prior arguments and whether what you had suggested "would fall out of the scope" of the warmup.
So far I think you've been very unreasonable/illogical. These are not good traits in a developer/developer-interviewer and I now know beyond a doubt there is no way I'd take a position with you, and I might even just terminate the interview abruptly. With 20 years experience I consider myself to be interviewing the company just as much as vice versa.
Feel free to have the last word but I won't be reading/responding.
So you've decided not to move the goalposts on this one?
There is no hidden agenda. Again if you are condescending or arrogant with someone asking a simple question trying to understand how you think and communicate then you are responsible for yourself and your actions. Good luck with that attitude.
BTW. It only took a few answers on my part in a popular platform like dev.to to understand that from your reactions and I'm a total stranger trying to share my opinion. I'm not even a real interviewer or hiring anyone. How good is that for you?
You stated this was an exercise to warm up specifically for a JS interview.
There are many ways to solve the problem - each demonstrating different areas of knowledge. A good interviewer would appreciate the knowledge and use of modern JS techniques (arrow function, spread operator) - since, after all, it is a JS specific interview.
Why would you ask someone to re-implement
array.reversein a test that is about Javascript? Any implementation you could make is likely to be slower than the built in one. That question would belong in a test about algorithmsI would say that any live coding interview questions tend to test you about algorithmic thinking. It's not only about the language. Also, If you can manage to code a dynamic programming task but not a simpler one like array reverse then the interviewer might think something is fishy here.
If that is what they want to test, they should ask for such. As this is framed as a JS interview it would be in the candidate's best interests to highlight their skill in Javascript over general programming ability unless asked otherwise.
If I were interviewing for a JS position, and the candidate's solution proceeded to reinvent the wheel, I would question why they had done it that way. On the basis of that answer I would decide whether or not they're a good fit for a specifically JS position
It is framed as a Javascript interview but it's not all about Javascript. Javascript may be hot now, but not tomorrow. Algorithms stay longer. That is the mindset.
Unfortunately, not all interviewers are kind to tell you what kinds of tests they will ask you. They could ask you anything. The idea is to be prepared as much as possible.