Lol, I've been doing this for 11 years and doing Fibonacci off the top of my head would make me sweat.
To me it seems a fairly unimportant exercise that proves little other than that you know the formula for the Fibonacci sequence of the top of your head under duress.
I'd assume that the interviewer would describe the formula for Fibonacci if asked. This type of question is more of a Fizzbuzz (i.e. testing for very basic programming ability) than a formula quiz.
In an interview setting, I'm sure you could hack something together and then improve it! Eg. an iterative Fibonacci is easy to reason about if you're not used to recursion.
It's a good question for junior people because there's so many ways to write it: iterative, recursive, recursive + memoized, eagerly streamed, lazily streamed.
That said, it is not a problem you'll have in the real world, so at best it's good to get a feel for how a candidate thinks through problems, how easily they can reframe an algorithm in different ways, and how they can reason about tradeoffs of different approaches.
The Fibonacci sequence is not much of a "formula", it's simply adding the previous two values in the sequence together. If you don't know that, the interviewer would probably happily tell you what it is, because the question probably aims at how you would actually implement it.
Though not knowing what Fibonacci is might still be a little bit suspect, given how often it is used in examples and literature in general as a "very simple" recursive function. One might think that the candidate hasn't explored their field very much.
16 years here and I failed a fibo question a few years ago. I don't do live coding well and it's rare to do that kind of "classic" recursion in a JS app. I've since added it to a list of practice questions I go over before I start interviewing, just in case somebody asks it.
what I missed was that these are supposed to be practice questions, so while they are sucky questions, they are question worth practice as opposed to good questions to ask
I hate fib as an interview question as well, but for the record the non-recursive while loop implementation is preferable till tail call recursion lands in major browsers.
Which questions specifically would you have trouble with?
While technically these aren't things someone absolutely has to know in order to be useful on frontend work, I think they are all very useful and practical things to know, so maybe you should learn about them!
I know what IP and DNS are but I couldn't tell you how they work.
I almost never use `this` and therefore don't remember all of its nuances. My team specifically avoids using it because it is harder for junior devs to grasp and makes things harder to read. I tend to agree.
Writing a reduce function? That's what I use lodash for.
What is REST? I use it every day but would have to look up a proper definition for you.
The event loop? I know what it is but I have never needed to know what it is.
I should learn these things because they are practical? Most of them aren't at my current job, but that's just my experience. And I probably get paid enough and have enough day to day freedom that I wouldn't want to work for you. However I would gladly answer all of these questions as a part of take home "homework".
> What is REST? I use it every day but would have to look up a proper definition for you.
REpresentation State Transfer
...
That's about all I can do to define REST. I can't really tell you what it really means beyond describing CRUD, but I can identify a REST interface when I see one.
REST isn't exactly aligned with CRUD, though it's often used for CRUD APIs.
REST generally describes (roughly in order of most common in implementation to least):
- HTTP requests operate on resources
- HTTP verbs describe the specific operations to perform (most typically HEAD, GET, POST, PUT, DELETE; some systems also implement OPTIONS, PATCH, custom verbs; some less-RESTful systems use POST for everything besides GET)
- Resources have a single identifier (URL); some systems get this wrong
- Query string parameters provide filtering and conditional behavior on requests for resources
- HTTP status codes indicate the condition of the response
- HTTP headers provide mechanisms for authorization/authentication, content type negotiation, pagination, error condition mitigation (redirects, rate limiting, etc)
- Responses provide URLs to related resources where appropriate
I'm probably forgetting a ton. The fundamental idea behind REST is to use the semantics of HTTP, as they were designed, to implement and interact with an API.
> I almost never use `this` and therefore don't remember all of its nuances. My team specifically avoids using it because it is harder for junior devs to grasp and makes things harder to read. I tend to agree.
Honestly I think `this` (and any OOP technique) should be avoided except under very specific circumstances, regardless of whether junior devs are involved. Exceptions include (but are not limited to):
- Interaction with native APIs or legacy libraries which mandate its use
- React lifecycle or other modern lib equivalent, if absolutely necessary
- When using a `class`, and only if it would be substantially more clear than a functional alternative
> Writing a reduce function? That's what I use lodash for.
Unless you need it for non-`Array` collections, just use `Array#reduce`.
> The event loop? I know what it is but I have never needed to know what it is.
Every time you do anything asynchronously in JS, you are interacting with the event loop. It would be a good idea to familiarize yourself with it, to understand the constraints and performance impacts of single-threaded asynchrony.
Lists like these are why imposter syndrome is so prevalent among engineers. You read something like this and suddenly you wonder if you're actually qualified to even be in the industry. Most of those questions will give no indication of a person's effectiveness as a frontend engineer, with the exception of the system design questions. Those are mostly rooted in actual problems that you might encounter as a frontend engineer.
What kind of work would this new applicant be doing? What product does your company make?
> What is Big O notation, and why is it useful?
Curious why you lead with this question? The rest of the top 11 questions are very Web dev and Javascript specific so that question sticks out. If people don't know the answer to it do you fault them for that?
It's a basic programming and communication skill. If someone doesn't know what it's called or what the syntax is that's fine. What's more important is the intuition:
If I have program A:
for (let i = 0; i < m; i++) {...}
And program B:
for (let i = 0; i < m; i++) {
for (let j = 0; j < m; j++) {...}
}
Then A is more optimal than B, because A runs the loop m times, but B runs the loop m*m times. That's it - if an engineer can reason through that, it's enough to explain to an interviewer tradeoffs between a few possible algorithms that solve some question.
Have you found that these questions have definitely helped you build a strong team? Has anyone ever passed your interview questions but failed as an actual employee? Just curious
The "Concepts" and "Debugging" sections are very strong signals in my experience. "Coding" is much less useful IMO, but this blog post is to help you practice the sorts of questions that are asked in practice, rather than what I ask specifically.
yeah i figured it was a pick and choose what fits best. Thanks for sharing your list! These kind of interview questions get posted on HN a lot and there's always the same reaction.
To me it's a good indicator of whether someone has a basic understanding of how to write efficient code.
If you're hiring a mechanic, given the same pay request, who would you rather hire: (a) mechanic who can build a car that does 0-100 in 4 seconds or (b) mechanic who can build a car that does 0-100 in 10 seconds?
Interestingly enough, as a front end dev this was one of the few questions I agree with (though I'd present it differently).
I wind up doing a ton of array/collection manipulation in my daily work, and I'd want to make sure any new members of the team could at least speak the same language.
Given this is a means to an end, I'd like to see the overall team hired and the output they're responsible for creating, maintaining and extending. (I'm assuming that's something they do.) And then, of course, the code repositories.
I don't mean to sound arrogant in any way but just to let you know these questions are way too easy. It's usually better to ask more open ended questions instead of it sounding like a quiz on JavaScript fundamentals
That's what the "Concepts" section is for. Those questions are designed so that you can keep going deeper for people that know the concept. At some point everyone bottoms out, but it's a different point for everyone. Eg.
"What is the event loop?"
"It's how JS does async"
"How does it work?"
"There's a stack and a queue managed by the platform"
"How else could you design that?"
"Other languages have threads"
"What are the tradeoffs between evented I/O and threads?"
"Memory safety and programmer error, CPU/memory utilization"
...
I've worked as a JavaScript developer for several years, and not once have I had need to write functions checking for palindromes, asserting prime-ness or other such efforts in rewriting lodash.
I guess I must just be missing the job adverts for all those businesses writing JavaScript utility libraries.
The specific functions you're implementing aren't important. What's important is that you can reason through a question, suggest possible algorithms, reason about their tradeoffs, write some code, and communicate all of that to the interviewer.
"What happens when I point my browser at $CANDIDATE'S_LAST_PROJECT?"
"What's your strategy for avoiding bugs?"
"How do you choose technologies?"
These three questions will prove
- that the developer understands the technology they work with (they know about networking, infrastructure, the server tech and are curious enough to learn about the runtimes their apps actually live on);
- that the developer has a mature opinion on testing (she knows what is and isn't worth automating, and that E2E automation often has a poor ROI)
- that the developer uses due dilligence and smart heuristics to choose technologies ('write a prototype!', 'eyeball the open source community!') rather than trends and groupthink ('everyone uses React!', 'someone on Medium said it was "curated"!')
These are the real competencies to filter by. The actual programming part, in most jobs, is easy. 80% of the roles I've interviewed candidates for have just been extravagant excuses to move around strings and shuffle integers between databases and browsers. I see no reason to believe this will soon change.
The last time I did anything vaguely 'algorithmic' was when I needed to sort a few thousand items without killing IE8's UI thread, and I solved it fairly trivially by writing a quicksort that used the recursion calls as an opportunity to yield the event loop. That's it. That is as far as most JS jobs go. I think anyone insisting otherwise is just being self-important.
To be honest none of these questions really give any insight into the
skills/experience of the applicant as most of them come down to just reciting
Wikipedia entries. If you want to get a better understanding of the applicant,
try asking them to solve simple problems relevant to the position instead of
performing a pop quiz.
In case of Javascript such a question could be:
Users are reporting that page X takes a long time to load. How would you go
about finding out why this page takes long to load and where time is being
spent? What are the benefits and drawbacks of your approach, and what are
the alternatives?"
The phrasing is just an example, but the idea is to:
1. Propose a problem that one can solve in e.g. 5-10 minutes
2. Ask them to think about the problem, their approach, benefits, drawbacks, etc
3. Have them deal with a problem that's actually relevant to the position,
giving the applicant a better taste of what it's like to work at the
organisation
Now that I've asked that pesky question, I will not ask anything more about the essential thing you need to manipulate as a front end engineer, what I want to ask about is algorithms implemented in many libraries because for some reason everyone else asks these questions in interviews.
There's a lot better questions you could potentially ask that are algorithmic but more relevant and more approachable than mathematical functions, like text manipulation, json manipulation.
well I often start with simple things like reversing the words in a string so "The cat sat on the mat" becomes "ehT tac no eht tam". Parse CSV into json. Various things to show how people manage state ( write a mini game of some sort )
> missing - Takes an unsorted array of unique numbers (ie. no repeats), and returns the missing number in the sequence (there are either no missing numbers, or exactly one missing number). Can you do it in O(N) time? Hint: There’s a clever formula you can use.
There is about a 50% chance I would answer "It is what values of β will give rise to", and hope the interviewer is an old Unix hand and gets a chuckle out of it [1].
56 comments
[ 3.1 ms ] story [ 113 ms ] threadOP
To me it seems a fairly unimportant exercise that proves little other than that you know the formula for the Fibonacci sequence of the top of your head under duress.
It's a good question for junior people because there's so many ways to write it: iterative, recursive, recursive + memoized, eagerly streamed, lazily streamed.
That said, it is not a problem you'll have in the real world, so at best it's good to get a feel for how a candidate thinks through problems, how easily they can reframe an algorithm in different ways, and how they can reason about tradeoffs of different approaches.
Though not knowing what Fibonacci is might still be a little bit suspect, given how often it is used in examples and literature in general as a "very simple" recursive function. One might think that the candidate hasn't explored their field very much.
While technically these aren't things someone absolutely has to know in order to be useful on frontend work, I think they are all very useful and practical things to know, so maybe you should learn about them!
I know what IP and DNS are but I couldn't tell you how they work.
I almost never use `this` and therefore don't remember all of its nuances. My team specifically avoids using it because it is harder for junior devs to grasp and makes things harder to read. I tend to agree.
Writing a reduce function? That's what I use lodash for.
What is REST? I use it every day but would have to look up a proper definition for you.
The event loop? I know what it is but I have never needed to know what it is.
I should learn these things because they are practical? Most of them aren't at my current job, but that's just my experience. And I probably get paid enough and have enough day to day freedom that I wouldn't want to work for you. However I would gladly answer all of these questions as a part of take home "homework".
Sorry if I'm being a curmudgeon. Shrug.
P.s. your website is down!
REpresentation State Transfer
...
That's about all I can do to define REST. I can't really tell you what it really means beyond describing CRUD, but I can identify a REST interface when I see one.
REST generally describes (roughly in order of most common in implementation to least):
- HTTP requests operate on resources - HTTP verbs describe the specific operations to perform (most typically HEAD, GET, POST, PUT, DELETE; some systems also implement OPTIONS, PATCH, custom verbs; some less-RESTful systems use POST for everything besides GET) - Resources have a single identifier (URL); some systems get this wrong - Query string parameters provide filtering and conditional behavior on requests for resources - HTTP status codes indicate the condition of the response - HTTP headers provide mechanisms for authorization/authentication, content type negotiation, pagination, error condition mitigation (redirects, rate limiting, etc) - Responses provide URLs to related resources where appropriate
I'm probably forgetting a ton. The fundamental idea behind REST is to use the semantics of HTTP, as they were designed, to implement and interact with an API.
Honestly I think `this` (and any OOP technique) should be avoided except under very specific circumstances, regardless of whether junior devs are involved. Exceptions include (but are not limited to):
- Interaction with native APIs or legacy libraries which mandate its use - React lifecycle or other modern lib equivalent, if absolutely necessary - When using a `class`, and only if it would be substantially more clear than a functional alternative
> Writing a reduce function? That's what I use lodash for.
Unless you need it for non-`Array` collections, just use `Array#reduce`.
> The event loop? I know what it is but I have never needed to know what it is.
Every time you do anything asynchronously in JS, you are interacting with the event loop. It would be a good idea to familiarize yourself with it, to understand the constraints and performance impacts of single-threaded asynchrony.
> What is Big O notation, and why is it useful?
Curious why you lead with this question? The rest of the top 11 questions are very Web dev and Javascript specific so that question sticks out. If people don't know the answer to it do you fault them for that?
If I have program A:
And program B: Then A is more optimal than B, because A runs the loop m times, but B runs the loop m*m times. That's it - if an engineer can reason through that, it's enough to explain to an interviewer tradeoffs between a few possible algorithms that solve some question.If you're hiring a mechanic, given the same pay request, who would you rather hire: (a) mechanic who can build a car that does 0-100 in 4 seconds or (b) mechanic who can build a car that does 0-100 in 10 seconds?
I wind up doing a ton of array/collection manipulation in my daily work, and I'd want to make sure any new members of the team could at least speak the same language.
I guess I must just be missing the job adverts for all those businesses writing JavaScript utility libraries.
But...tacocat!
What sort of questions do you ask instead?
"What's your strategy for avoiding bugs?"
"How do you choose technologies?"
These three questions will prove
- that the developer understands the technology they work with (they know about networking, infrastructure, the server tech and are curious enough to learn about the runtimes their apps actually live on);
- that the developer has a mature opinion on testing (she knows what is and isn't worth automating, and that E2E automation often has a poor ROI)
- that the developer uses due dilligence and smart heuristics to choose technologies ('write a prototype!', 'eyeball the open source community!') rather than trends and groupthink ('everyone uses React!', 'someone on Medium said it was "curated"!')
These are the real competencies to filter by. The actual programming part, in most jobs, is easy. 80% of the roles I've interviewed candidates for have just been extravagant excuses to move around strings and shuffle integers between databases and browsers. I see no reason to believe this will soon change.
The last time I did anything vaguely 'algorithmic' was when I needed to sort a few thousand items without killing IE8's UI thread, and I solved it fairly trivially by writing a quicksort that used the recursion calls as an opportunity to yield the event loop. That's it. That is as far as most JS jobs go. I think anyone insisting otherwise is just being self-important.
In case of Javascript such a question could be:
The phrasing is just an example, but the idea is to:1. Propose a problem that one can solve in e.g. 5-10 minutes
2. Ask them to think about the problem, their approach, benefits, drawbacks, etc
3. Have them deal with a problem that's actually relevant to the position, giving the applicant a better taste of what it's like to work at the organisation
Now that I've asked that pesky question, I will not ask anything more about the essential thing you need to manipulate as a front end engineer, what I want to ask about is algorithms implemented in many libraries because for some reason everyone else asks these questions in interviews.
There's a lot better questions you could potentially ask that are algorithmic but more relevant and more approachable than mathematical functions, like text manipulation, json manipulation.
I often work with concurrency, data structures, and integrating with existing code. It never seems like these challenges map to the work I do.
- what is the challenge of asynch programming in JavaScript?
- what is your personal approach to solving the challenge of async programming in JavaScript?
- do you know what promises are? if yes, can you explain how promises work?
- what is the key problem with scope and this in ES5? how do you address it?
- have you used ES2015/ES6?
- if candidate has ES2015 knowledge: what are the features of ES2015 that you find most valuable?
- if candidate has ES2015 knowledge: what is the key value of arrow functions?
- if you have used asynch and await, can you explain how to use them?
- which JavaScript build tools do you use? what purpose does each of them serve?
- which JavaScript frameworks or libraries are you most familiar with?
- do you use the browser developer tools? which do you use? explain the process of using them.
- how do you use 'inspect element' as part of your development process?
I'm not interested in questions of syntax because doesn't every programmer spend all their time looking up syntax?
Is the correct result for
undefined or 1?What is the correct result for
There is about a 50% chance I would answer "It is what values of β will give rise to", and hope the interviewer is an old Unix hand and gets a chuckle out of it [1].
[1] https://www.bell-labs.com/usr/dmr/www/odd.html