4 ms·

I think most people in this field respect someone with a strong foundation and accomplishments. I think a strong kick that you might need would be to take inte

I think most people in this field respect someone with a strong foundation and accomplishments. I think a strong kick that you might need would be to take interviews with firms in SF or NY. When I first started doing that I realized quickly just how little I could recite by rote that I should've been able to. The questions IMO are not difficult, but they dig deep into your fundamental understanding of programming. In other words the questions don't require you to be a genius. They just reinforce just how high the standards are in these cities and set an appropriate bar for people who want to be programmers. Those things that are easy for you to lookup on MDN or your programming language's website? Your goal should be to become so familiar with those concepts and fundamental APIs / function calls that you no longer need to reference them each time you need to use them.

klibertp 9y ago
Could you provide examples "concepts and fundamental APIs / function calls" that you had to "recite by rote"? There are things worth learning by heart, but there are also things better left in the manuals (esp. if the docs are searchable like most are nowadays). Being asked about the former is usually a sign of a good employer and/or competent interviewer. Being asked about some obscure corner case in a function you only used twice in the last decade, on the other hand, is often a sign of the opposite. Without a couple of examples, it's hard to say which kind of questions you were asked.
- perpetualcrayon 9y ago
  A great example would be to explain differences between bind, call, and apply in JS. Especially when talking about the difference between call and apply you might want to be familiar with the function signatures of each. Object.create. requestAnimationFrame. Promises. Knowing ES6 syntax vs traditional prototypal inheritance in JS. Can't be said enough, you absolutely must understand scope in JS without the need to reference docs. Another example, I once had to do a coding challenge in front of a camera recording my coding session where having intimate familiarity with sort, filter, map, etc was useful. That's not the only language I've dealt with in interviews, but statistically probably the language you could associate w/ most readily. Finally I'll mention that it's no joke these days when you're interviewing as a developer w/ experience in one of the modern JS frameworks. Especially in places like SF and NY. If you don't have experience in at least one you should start now. If you have "experience" but have never felt the need to dig a little deeper now would be a great time to do so.
  - dennis_jeeves 9y ago
    >If you have "experience" but have never felt the need to dig a little deeper now would be a great time to do so. Talk about getting priorities wrong! How deep does one dig in? How long? Is it time well spent? With software it can be a rabbit hole and it is prudent only to dig deep enough to get the work done reasonably well. One can certainly debate how 'resonable' one should be, but that's besides the point. Now if I were to dig in 'deep' into the chemical contaminants of the water or food that I drink - that in my opinion is time well spent, and takes enormous priority over digging up the innards of JS( one could go right up to the level of what's happening at the CPU level when a line of code executes.). JS - my foot! Sorry to take a dig at you, but if indeed your priorities are digging deep into the things that matter - like the water you drink then I will take back my words and apologize.
  - klibertp 9y ago
    > That's not the only language I've dealt with in interviews, but statistically probably the language you could associate w/ most readily. I have been programming for two decades now and personally, I'm a PL nerd and a fan of polyglot programming, with more than a hundred languages surveyed, a few tens of languages known, and a dozen or so languages used in production. I have a blog (see my profile) on the topic and everything... In other words, you don't need to hold back if you have some more interesting examples just because they're in a "not in the first five on TIOBE" language :-) > explain differences between bind, call, and apply in JS You weren't joking saying the questions were about fundamentals. This is an incredibly basic knowledge to be asking about. I last touched JS probably more than 4 years ago, yet I have no trouble explaining this. How could any active JS developer not know this? Or are we talking about very junior positions? > you might want to be familiar with the function signatures Why should I bother? I know that one of the functions takes a list of values as a single argument and the other takes any number of arguments, just like they do in many other languages which have them both (for example Erlang has apply, but it doesn't have call, because it doesn't support variable arity functions). Let's assume for a moment that I don't remember which is which, and also don't remember the order of other args (obj first and arglist second or the opposite), and also don't remember if they are methods or standalone functions. I can check all of these in 10 s on the web, but my editor displays a function signature while typing, so, in practice, it makes no difference if I remember this or not. In other words: why should I spam my memory with useless trivia? There are more interesting things to remember! > Knowing ES6 syntax vs traditional prototypal inheritance in JS. Again, the prototype inheritance is a fundamental property of JS. I have a side-project in Io lang and I know Lua quite well, not to mention I debugged more than enough CoffeeScript back when source maps weren't universally supported, so I believe I have a good grasp of prototypal inheritance. The exact class declaration syntax, on the other hand, is just a tiny bit of info that I can check in 30 seconds. > If you have "experience" but have never felt the need to dig a little deeper Then you should change the occupation to something else than programming. If you don't have the curiosity to dig deeper, you most probably don't have a desire to learn and improve, which, in the industry where you need to run as fast as you can just to remain where you are, makes you a liability for any team you'd join.

klibertp 9y ago

Could you provide examples "concepts and fundamental APIs / function calls" that you had to "recite by rote"? There are things worth learning by heart, but there are also things better left in the manuals (esp. if the docs are searchable like most are nowadays). Being asked about the former is usually a sign of a good employer and/or competent interviewer. Being asked about some obscure corner case in a function you only used twice in the last decade, on the other hand, is often a sign of the opposite. Without a couple of examples, it's hard to say which kind of questions you were asked.

perpetualcrayon 9y ago
A great example would be to explain differences between bind, call, and apply in JS. Especially when talking about the difference between call and apply you might want to be familiar with the function signatures of each. Object.create. requestAnimationFrame. Promises. Knowing ES6 syntax vs traditional prototypal inheritance in JS. Can't be said enough, you absolutely must understand scope in JS without the need to reference docs. Another example, I once had to do a coding challenge in front of a camera recording my coding session where having intimate familiarity with sort, filter, map, etc was useful. That's not the only language I've dealt with in interviews, but statistically probably the language you could associate w/ most readily. Finally I'll mention that it's no joke these days when you're interviewing as a developer w/ experience in one of the modern JS frameworks. Especially in places like SF and NY. If you don't have experience in at least one you should start now. If you have "experience" but have never felt the need to dig a little deeper now would be a great time to do so.
- dennis_jeeves 9y ago
  >If you have "experience" but have never felt the need to dig a little deeper now would be a great time to do so. Talk about getting priorities wrong! How deep does one dig in? How long? Is it time well spent? With software it can be a rabbit hole and it is prudent only to dig deep enough to get the work done reasonably well. One can certainly debate how 'resonable' one should be, but that's besides the point. Now if I were to dig in 'deep' into the chemical contaminants of the water or food that I drink - that in my opinion is time well spent, and takes enormous priority over digging up the innards of JS( one could go right up to the level of what's happening at the CPU level when a line of code executes.). JS - my foot! Sorry to take a dig at you, but if indeed your priorities are digging deep into the things that matter - like the water you drink then I will take back my words and apologize.
- klibertp 9y ago
  > That's not the only language I've dealt with in interviews, but statistically probably the language you could associate w/ most readily. I have been programming for two decades now and personally, I'm a PL nerd and a fan of polyglot programming, with more than a hundred languages surveyed, a few tens of languages known, and a dozen or so languages used in production. I have a blog (see my profile) on the topic and everything... In other words, you don't need to hold back if you have some more interesting examples just because they're in a "not in the first five on TIOBE" language :-) > explain differences between bind, call, and apply in JS You weren't joking saying the questions were about fundamentals. This is an incredibly basic knowledge to be asking about. I last touched JS probably more than 4 years ago, yet I have no trouble explaining this. How could any active JS developer not know this? Or are we talking about very junior positions? > you might want to be familiar with the function signatures Why should I bother? I know that one of the functions takes a list of values as a single argument and the other takes any number of arguments, just like they do in many other languages which have them both (for example Erlang has apply, but it doesn't have call, because it doesn't support variable arity functions). Let's assume for a moment that I don't remember which is which, and also don't remember the order of other args (obj first and arglist second or the opposite), and also don't remember if they are methods or standalone functions. I can check all of these in 10 s on the web, but my editor displays a function signature while typing, so, in practice, it makes no difference if I remember this or not. In other words: why should I spam my memory with useless trivia? There are more interesting things to remember! > Knowing ES6 syntax vs traditional prototypal inheritance in JS. Again, the prototype inheritance is a fundamental property of JS. I have a side-project in Io lang and I know Lua quite well, not to mention I debugged more than enough CoffeeScript back when source maps weren't universally supported, so I believe I have a good grasp of prototypal inheritance. The exact class declaration syntax, on the other hand, is just a tiny bit of info that I can check in 30 seconds. > If you have "experience" but have never felt the need to dig a little deeper Then you should change the occupation to something else than programming. If you don't have the curiosity to dig deeper, you most probably don't have a desire to learn and improve, which, in the industry where you need to run as fast as you can just to remain where you are, makes you a liability for any team you'd join.