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.
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.
You are right it’s not the best, but I think it’s a fine starting/warm up question for a C or C++ interview. Atoi can make for a fun discussion just because error handling is so bad in the standard c version. The most common output value is also the same as the return value for an error: 0. I think some versions set the Errno global on failure, can’t recall.
There is definitely room for 2x to 3x performance improvements on the implementation you linked by changing the main loop to not have each iteration depend upon the result of the previous iteration.
I like your criteria, so I'm going to put a question I used to ask in interviews up against it: let's write (and test) the world's worst JSON encoder, in TDD style. The ultimate goal of this question was to end up with a function (in Python, when I was asking it) that could JSON encode primitive types, along with lists and dicts. No fancy stuff about trying to figure out what to do with general objects or anything. No worrying about circular references. No tricks. Just take a Python data structure as input and output a string representing a valid JSON encoding of that data structure.
1. You need to know how to write a half decent test case, and, for full credit, how to write a recursive function. Check.
2. As alluded to in the previous point, we can judge the quality of the test cases. So, I think this is at least a provisional pass.
3. A really good candidate can talk about issues like Unicode, how to handle or avoid stack overflow, dealing with circular references, maybe think a bit about optimizations.
4. Unless you consider recursion to be "fiddly code," then we meet this criterion as well. I allowed people to use str() or repr() to convert things to strings, so there was no incidental difficulty there, either.
5. Nope, no tricks. Just use recursion.
So, it looks to me like I had a pretty okay question.
Anybody take issue with any of what I wrote, or have any suggestions for making it a better question?
As a follow up you could scope out how familiar the candidate is with alternate encoding options and what the trade-offs and use cases are. (BSON/MessagePack, Protobuf/Avro/Thift, FlatBuffers/Cap'nProto).
> 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.
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.
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.
> "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.
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.
20 comments
[ 3.5 ms ] story [ 60.0 ms ] threadThe 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 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.
There is definitely room for 2x to 3x performance improvements on the implementation you linked by changing the main loop to not have each iteration depend upon the result of the previous iteration.
1. You need to know how to write a half decent test case, and, for full credit, how to write a recursive function. Check.
2. As alluded to in the previous point, we can judge the quality of the test cases. So, I think this is at least a provisional pass.
3. A really good candidate can talk about issues like Unicode, how to handle or avoid stack overflow, dealing with circular references, maybe think a bit about optimizations.
4. Unless you consider recursion to be "fiddly code," then we meet this criterion as well. I allowed people to use str() or repr() to convert things to strings, so there was no incidental difficulty there, either.
5. Nope, no tricks. Just use recursion.
So, it looks to me like I had a pretty okay question.
Anybody take issue with any of what I wrote, or have any suggestions for making it a better question?
As a follow up you could scope out how familiar the candidate is with alternate encoding options and what the trade-offs and use cases are. (BSON/MessagePack, Protobuf/Avro/Thift, FlatBuffers/Cap'nProto).
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.
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)".
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.
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.