Technical interviews that focus on having a bullshit paper test are useless, I would personally refuse to take part in any and would walk out if insisted as they serve no purpose and focus on something like that tells me the people I'm interviewing for are not very serious.
Any sensible person generally should answer to the idiotic trivia bs questionnaires with the words "I don't give a fuck, and if I really need to find out I'll either run the code or google".
It's good to know about the common issues of the language you're working in, but to focus on those more than just by asking the question "are you familiar with how bad the typeof operator, floating point operations etc. are in JavaScript?" or "have you heard of the good parts of JavaScript" is ridiculous..
What interviews should focus on is practical experience, trying to find out if you get along, interest and experience in RELEVANT areas around the work they'll be doing.
Basically what a technical interview should consist of is more along the lines of:
"Tell me of your favorite project in the last few years" - to find out what they like to work with
"Can you describe it's architecture to me on a drawing?" - to test communications skills a bit
"Is there any specific code you've made recently that you're very proud of and want to show to me?" - to see what kind of code you think is good code
"Describe your routine for getting around blockers, issues that you just can't seem to solve?" - to see how resourceful they are, if they know to depend on the team to support them, etc.
"How many programming languages have you programmed significant amounts in?" - if the answer is very low (like 1-2) they likely don't have a lot of experience in different ways to solve problems
... and so on.
When you ask someone e.g. "how well do you know SQL" and the answer is "quite well" you should feel secure that you can hire them without giving them a quiz about it, as you can always fire them if it turns out they lied.
Also the question of knowledge of a specific topic rarely even matters when dealing with suitable people as they can learn the things they don't know. You generally build a team so people with varying levels of experience and different kinds of backgrounds can help each other out, and not so everyone knows the details of all the tools you are using. More diversity is better in this as well.
Tinkerer, crossfiter and a music junky... Maker of: http://musicmeal.io / https://twitter.com/AudioPlayer3 & https://twitter.com/BirdOfKnowledge & https://twitter.com/JanusWorkspace
I would a few more points about asking them to show me some code samples from their project, which they believe to be good because they have found an interesting solution to an interesting problem. And briefly discuss it with them, to get a glimpse of how they think and how they approach problems.
I stayed for the test, because it is the first time somebody handed me a test for technical interview. I did it way too fast, took pictures of it and decided to write the above rant. If even on TL or someone in charge change its ways from this to something better it's worth it.
Make a function ‘sum’ that returns a sum of two values.
this function should be called as these examples:
console.log(sum(5, 3)); // returns 8
console.log(sum(5)(3)); // returns 8
Is also an immediate red flag that should tell you "NEVER WORK HERE" - no sane person would ever write a function with such obviously differing return values depending a bit on the number of arguments. Holy hell that would make life working with their codebase a pain in the ass, and JavaScript is already a big enough pain in the ass without artificially making it worse.
Tinkerer, crossfiter and a music junky... Maker of: http://musicmeal.io / https://twitter.com/AudioPlayer3 & https://twitter.com/BirdOfKnowledge & https://twitter.com/JanusWorkspace
IMO they just wanted to see if anyone knows what currying is. This being said there are two things
I haven't seen anyone use currying in my past 6 years as a developer, neither at work or at code examples of finished products. I have recently seen it as part of articles, to which there are links in my article.
If they are actually using it - WHY? being able to support handling arguments that way is weird and is a step away from also handling sum([5,3]), or sum ([5,[[3]]]) or something weirder, that I can't think of right now.
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.
Technical interviews that focus on having a bullshit paper test are useless, I would personally refuse to take part in any and would walk out if insisted as they serve no purpose and focus on something like that tells me the people I'm interviewing for are not very serious.
Any sensible person generally should answer to the idiotic trivia bs questionnaires with the words "I don't give a fuck, and if I really need to find out I'll either run the code or google".
It's good to know about the common issues of the language you're working in, but to focus on those more than just by asking the question "are you familiar with how bad the typeof operator, floating point operations etc. are in JavaScript?" or "have you heard of the good parts of JavaScript" is ridiculous..
What interviews should focus on is practical experience, trying to find out if you get along, interest and experience in RELEVANT areas around the work they'll be doing.
Basically what a technical interview should consist of is more along the lines of:
... and so on.
When you ask someone e.g. "how well do you know SQL" and the answer is "quite well" you should feel secure that you can hire them without giving them a quiz about it, as you can always fire them if it turns out they lied.
Also the question of knowledge of a specific topic rarely even matters when dealing with suitable people as they can learn the things they don't know. You generally build a team so people with varying levels of experience and different kinds of backgrounds can help each other out, and not so everyone knows the details of all the tools you are using. More diversity is better in this as well.
Yes to all of your points!
I would a few more points about asking them to show me some code samples from their project, which they believe to be good because they have found an interesting solution to an interesting problem. And briefly discuss it with them, to get a glimpse of how they think and how they approach problems.
I stayed for the test, because it is the first time somebody handed me a test for technical interview. I did it way too fast, took pictures of it and decided to write the above rant. If even on TL or someone in charge change its ways from this to something better it's worth it.
Oh btw the test:
Is also an immediate red flag that should tell you "NEVER WORK HERE" - no sane person would ever write a function with such obviously differing return values depending a bit on the number of arguments. Holy hell that would make life working with their codebase a pain in the ass, and JavaScript is already a big enough pain in the ass without artificially making it worse.
IMO they just wanted to see if anyone knows what currying is. This being said there are two things