For example, they might ask for a hard problem you've recently solved in your last company.
If you say something related to code splitting, you can expect he'll drill down more specifically into webpack, dependency cycles, etc.
If you say something related to frameworks, you'll get questions asking you to back up the choices you've made. Was it mainly developer productivity or performance you optimized? If you say performance, how did you measure? What metrics are you logging?
...
You should prepare by just reviewing hard problems you've done and brushing up on aspects of it you might've forgotten or remind yourself what was difficult about it.
This applies to the coding portion of your interview as well. If you write "===", you should be able to answer what that's for. If you use ".bind(this)", you should know why you had to bind it. For this portion, you can prepare by looking at code you've written and trying to pick out those parts which you never bothered to figure out but always "just did" (e.g. for many people, the === is just something they do because they see it everywhere).
If I had known this as a high school student, I never would have studied math and computer science. Easily one of the most anti-inclusivity and self-defeating aspects of tech.
Not exactly what you want, but that's still what I'd ask.
That will tell me more about the candidate's abilities than syntax questions or other silly things like that. INCLUDING how good they are at syntax and silly things (the way they speak will show it).
What I like about these kind of open-ended problems, is that it accounts for variety of backgrounds and skillsets. People can surprise you with solutions and ideas you'd never have thought about.
It does require 2 things: 1) make it absolutely clear that this isn't a question with a predefined answer. 2) you have to be open minded about how the candidate answers.
Most frontend devs will go through their frameworks of choice, project structures, backend tooling preferences, how they sketch a UI, how they work with designers, etc. I had one once walk me through a complete system architecture analysis. We gave them an offer to lead our devops team ;)
As other commenters will point out, such quirks are as easy to look up as they are irrelevant to actual software development.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... "Defining getters and setters"
That must be downright hilarious, depending on how the question is asked. Promises are an absurdly complicated construct considering how little they actually do. If you don't give the candidate the expected spec, 95% of candidates won't get even close. If you do, working through the answer will take long enough that the candidate (and honestly, the interviewer) might get bored.
If you simplify the problem space a lot and ask for a minimal "promise-like"-ish construct, then It can be an interesting coding exercise I guess.
Of course an hour long interview is not enough time to implement the full Promise spec but it should be enough time to gauge the level of a candidate.
"1" of base 0 is 1
"1" of base 1 is NaN
"1" of base 2 is 1
The gotcha here is if you map(fn), you're going to get all three arguments sent to the fn, where map(v => fn(v)) explicitly only sends the first one.
Then again I suppose that you could recreate JavaScripts behaviour even in the fairly strongly typed C# if you wanted to, by defining two overloaded versions of Map as follows:
IEnumerable<B> Map<A,B>(this IEnumerable<B> list, Func<A,B> f)
IEnumerable<B> Map<A,B>(this IEnumerable<B> list, Func<A,int,B> f)
In this case, the index of the element (1, 2, 3) is getting passed as the radix with which to parse the element (1, 1, 1).
[1, 2, 3, 4].reduce((x, y) => Math.min(x, y))
[1, 2, 3, 4].reduce(Math.min)
To save everyone from having to look this up on Stack Overflow:
.map passes two arguments to the function it calls - the value and the index. The parseInt function takes up to two arguments, a string and a radix.
So there’s nothing broken here about .map, you just aren’t expecting the second optional argument for parseInt.
So the actual equivalents are: ['1','1','1'].map(parseInt)
And
['1','1','1'].map((n, index) => parseInt(n, index))
['1', '2', '3'].map(parseInt)
That's just about language specifics, not a question for seniors in my opinion.
I've asked a lot of code structure questions. JS really easily turns into spaghetti code if a dev isn't careful. I like to test candidates on whether they make code understandable with clean closures, modules, files, etc. I'll also ask about which libraries they used, why they used them, and what they liked/disliked about the library. Also, "because that's what the code base was in, and there was no reason to change it" is a legitimate 'why'.
For language specific things: - How closures, scopes, and prototypal inheritance work is important. This is often tested with nested callbacks. - Web API design - HTTP methods (Not as important if a candidate's background is in RCP, GraphQL, or something that doesn't use HTTP methods RESTfully)
On the other hand, ""gotchas" are usually easily Google-able too." isn't that simple. You don't know what you don't know. We're in a world now when even some extremely senior devs don't know the tools they use. A lot of it can be blamed on the whole "if you know one language you can learn any other in an afternoon!" tenet. Having so few people these days with vertical/deep knowledge of the tools they use gets really annoying when trying to deal with major production issues and no one in the room can debug them in a timely manner.
Almost makes me think that some form of "tech guru" role should start being a thing, and THOSE people could be interviewed with the stream of obscure gotchas...because sometimes you need a tech guru.
I agree with others though that you probably won't get the trivia treatment, I wouldn't give one and I don't see them being done by coworkers... But it doesn't hurt to be prepared. So long as you don't present yourself as a "Master" I would think the knives would be less likely to come out. Things like this github has https://github.com/denysdovhan/wtfjs are on the mean spectrum to use against some so-called master, the meanest might probably be demanding they do something with representations like in http://patriciopalladino.com/blog/2012/08/09/non-alphanumeri...
A year later another guy from "same book store" asked me to center text in a div during a live screen share.
So, YMMV and its all parlour tricks anyway.
just.apply(you, ['who', 'knows', 'anyway]);
Though it sounds a bit jaded— can confirm. I've been asked to re-implement `bind` before.
I gave it a shot but ultimately shrugged and explained that I'd rarely ever extend a native object and would rather use a community-supported polyfill. Nevermind that in my current field we haven't had to support ES3-capable browsers for ages.
I'd certainly be better off knowing, but rarely would I need to know on the spot. There is more beneficial knowledge to have up front.
If I'm ever in a position where I'm responsible for technical interviews I'm pretty sure I'll give them open internet questions. Then ask them to talk me through their thought process. Even though questions could probably be answered by anyone with decent skills, the best will certainly stand out in how they talk you through their thought process.
You might see a dumb question that is just a bunch of spaghetti nonsense you'll have to unravel. Explain what this ridiculous codeblock does.
Definitely expect to see closure-based problems. You can almost bet your money on seeing an anonymous function in a loop printing an unexpected value of i:
(copy these code blocks into your browser console and test them out)
for(var i = 0; i < 10; i++) {
setTimeout(function() { console.log(i); }, 1);
}
setTimeout(func, 0);
variable scoping with var, let and const. Variable and function hoisting. Expect brain teasers exploiting the differences in const / let and var:
const x = [1, 2, 3];
for (var i = 0; i < x.length; i++) {
setTimeout(function() { console.log(i, x[i]); }, 1);
}
2) Functions that are being returned from the Browser API are pushed to a special waiting area (called the "Callback queue"), not to the immediate Call Stack
3) Functions are only taken from the Callback queue when both the Call Stack and the other higher priority queues (like the "Job" Queue) are empty.
When setTimeout is invoked, the Javascript engine sends func and 0 as arguments to the API, then moves on. The engine doesn't get blocked by setTimeout, nor does it wait to see the end result. Javascript's job is done here, and so it just moves on to the rest of the code.
When the API receives setTimeout's arguments, it executes the Timer(?) method, passing to it an argument of 0 seconds. This resolves immediately.
However, the API isn't allowed to send functions straight back into the Call Stack. Functions are forced into an intervening waiting area called the Callback Queue. (In the case of promises, there's also a higher priority queue that functions can be sent to instead: the "Job" or "Micro-task" Queue).
Javascript's event loop will only pull functions from the Callback Queue when 1) the main thread of execution has finished all of its synchronous code, 2) the Call Stack is empty, and 3) no higher priority queues have functions left to be pulled either.
Therefore, in the case of "setTimeout(func, 0)", func can be forced to wait a very long time, indeed. If the intervening synchronous code takes 10,000 ms to run, the func from setTimeout(func, 0) will, at a minimum, run at the 10,000 ms point.
However, back in the days of "callback hell", this was often the reason why you'd do a "setTimeout(func, 0)" or two in the first place: to manipulate the order in which certain functions were run by the thread of execution.
Since, literally, what it does it knock a function out of the normal order of events and places it into a lower priority queue.
How it works is func is scheduled to execute asynchronously on the next tick of the event loop at the soonest, so if func() printed "wat" and you have console.log('huh') directly after that statement, you'd see "huh" then "wat"
You see a lot of things happening which may not make sense like "The Great Mystery of the Tilde(~)"[1], etc which are not only fun to figure out but you also see them being used practically too.
[1] https://www.joezimjs.com/javascript/great-mystery-of-the-til...
Good advanced JS questions (in my opinion) will involve things that are useful but also challenging, like details about promises, prototypical inheritance (that one is debatable, since some JS experts avoid that), the browser event loop, etc.
But as other have already pointed out, quiz-type questions that are trivially searchable and irrelevant for practical programming tell about a culture of the company. Use that as hint if you want to work for them.
variable hoisting
how to extend a class/prototype
es6 features
typescript/flow
tdd
tooling/webpack