Thanks for this. As an individual contributor software developer I've been tasked to initially interview candidates for our software developer roles.
I have no prior experience in interviewing people, so my current strategy is to just ask about everything on the résumé, ask to see any source code written by the candidate, and ask technical trivia questions like "explain the http life cycle" and "explain the difference between filter, map, reduce (javascript)".
Ask about team processes. Talk to them about how they approach code review and testing their code.
If their resume includes overlap with your tech stack, ask if they understand why you would choose the tech you use, like "We use Y as a caching layer. What advantages does that give us over using Z instead". If they can't answer that's fine, but it helps you get an idea of their abilities.
In the JavaScript world I like to ask if candidates can explain what benefits there are to using TypeScript. Yes it adds strong typing, but what does that get you.
I definitely have a bias towards devs who can demonstrate that they have thought about the tools they use and why they use them. I also think it demonstrates that people have actually used the tools, without making them implement stuff from memory.
These are pretty good questions. I'd put more value on say understanding HTTP or async/promises and how they work vs knowing the differences between methods. You can always look those up. One interesting thing with reduce would be "What is a situation where reduce is the best choice?" What I look for is a bridge from the coding question earlier where most people will implement a nested loop situation and could bring down the total iterations over the data set.
> "explain the http life cycle" and "explain the difference between filter, map, reduce (javascript)".
Those seem like pretty reasonable questions, though - they're at least things that would have come up at some point if somebody had actually been doing professional (web) development.
What actually matters is being able to effectively solve problems related to these questions when they arise. Doing the investigation. Who cares if you know these trivialities off the top of your head?
Are all these questions related to Javascript? In some instances number vs object I guess I could talk about it wrt to Java or C but in terms of what Javascript’s notion of anything is unknown to me.
Front-end developer interviews are pretty hard, because you have to master the same algo puzzles back-enders do, but you're also expected to answer pop trivia for random JavaScript/browser quirks.
I have never encountered these but if I did I think I’d do poorly and not sweat it. It’s definitely an easy conversation point with the hiring manager and will tell me a lot about their culture.
The interviews I hate are when they are so optimized I can’t get any information out of the process. Leakiness of data is something I desire greatly as the other participant and I think as an org I also strive to leak as much about our culture as possible in our interview process.
I would classify atoi() as a mediocre question at best.
I would look for the following in a "fine" question:
1. It demonstrates knowledge of fundamental concepts or techniques.
2. It lets you distinguish the quality of answer/implementation rather than just works or doesn't.
3. It leads to natural follow-up questions that can demonstrate the candidate's knowledge or expertise.
4. It does not require fiddly code. (e.g. linked list pointer twiddling questions: they aren't hard but are easy to muck up with a stranger staring at you.)
5. If its unrelated to what candidates normally work on, the question should not hinge on knowing a specialized "trick" to change difficulty from hard to easy.
Atoi under that criteria:
1. Does not show much interesting besides a basic understanding of decimal numbers and writing loops.
3. I guess you could follow it up with questions on testing and error handling. Nothing super interesting comes to mind, but that could be lack of imagination on my part.
4. It meets this criteria.
5. It meets this criteria.
Perhaps you have some particularly good way of posing an atoi() question.
> What’s the fastest way to convert a string to number? And other unspecified behavior.
This really says nothing about the contents of the string. Is it decimal, then maybe they want atoi. They could be looking for a hash of the string as well. Or the levenshtein distance to the word "walrus". Or really, any number of functions that convert a string to a number.
[+] [-] b0afc375b5|4 years ago|reply
I have no prior experience in interviewing people, so my current strategy is to just ask about everything on the résumé, ask to see any source code written by the candidate, and ask technical trivia questions like "explain the http life cycle" and "explain the difference between filter, map, reduce (javascript)".
[+] [-] bluefirebrand|4 years ago|reply
If their resume includes overlap with your tech stack, ask if they understand why you would choose the tech you use, like "We use Y as a caching layer. What advantages does that give us over using Z instead". If they can't answer that's fine, but it helps you get an idea of their abilities.
In the JavaScript world I like to ask if candidates can explain what benefits there are to using TypeScript. Yes it adds strong typing, but what does that get you.
I definitely have a bias towards devs who can demonstrate that they have thought about the tools they use and why they use them. I also think it demonstrates that people have actually used the tools, without making them implement stuff from memory.
[+] [-] dandigangi|4 years ago|reply
[+] [-] commandlinefan|4 years ago|reply
Those seem like pretty reasonable questions, though - they're at least things that would have come up at some point if somebody had actually been doing professional (web) development.
[+] [-] JonChesterfield|4 years ago|reply
[+] [-] neon_me|4 years ago|reply
[+] [-] seanw444|4 years ago|reply
[+] [-] cpt1138|4 years ago|reply
[+] [-] authorityofnil|4 years ago|reply
[+] [-] mcntsh|4 years ago|reply
[+] [-] renewiltord|4 years ago|reply
The interviews I hate are when they are so optimized I can’t get any information out of the process. Leakiness of data is something I desire greatly as the other participant and I think as an org I also strive to leak as much about our culture as possible in our interview process.
[+] [-] google234123|4 years ago|reply
[+] [-] nieksand|4 years ago|reply
I would look for the following in a "fine" question:
1. It demonstrates knowledge of fundamental concepts or techniques.
2. It lets you distinguish the quality of answer/implementation rather than just works or doesn't.
3. It leads to natural follow-up questions that can demonstrate the candidate's knowledge or expertise.
4. It does not require fiddly code. (e.g. linked list pointer twiddling questions: they aren't hard but are easy to muck up with a stranger staring at you.)
5. If its unrelated to what candidates normally work on, the question should not hinge on knowing a specialized "trick" to change difficulty from hard to easy.
Atoi under that criteria:
1. Does not show much interesting besides a basic understanding of decimal numbers and writing loops.
2. It's hard to imagine much variability in the quality of responses. A "real" atoi implementation is not interview material: https://github.com/golang/go/blob/master/src/strconv/atoi.go...
3. I guess you could follow it up with questions on testing and error handling. Nothing super interesting comes to mind, but that could be lack of imagination on my part.
4. It meets this criteria.
5. It meets this criteria.
Perhaps you have some particularly good way of posing an atoi() question.
[+] [-] marginalia_nu|4 years ago|reply
This really says nothing about the contents of the string. Is it decimal, then maybe they want atoi. They could be looking for a hash of the string as well. Or the levenshtein distance to the word "walrus". Or really, any number of functions that convert a string to a number.
[+] [-] MaxMoney|4 years ago|reply
[deleted]