3 ms·

This is a weird mix of stuff I would consider basic and stuff that no one should ever need to worry about.

johnnyanmac 2y ago
I'd never call myself a JS dev but have used it to develop web pages on the side. this list shows me how little I really understand the more intimate details of JS. I'd personally love to see a variation of this for C/C++/C#. And in all fairness, "stuff no one should ever need to worry about" is prime interview material for jobs. Though there's so many formats of technical interviews you never really know.
- rnallandigal 2y ago
  https://cppquiz.org https://cppquiz.org contains a list of similar questions in C++.
  - johnnyanmac 2y ago
    perfect, that was exactly what I was looking for. Thanks!
- hn_throwaway_99 2y ago
  > And in all fairness, "stuff no one should ever need to worry about" is prime interview material for jobs. In reality, when I've seen this: 1. Shitty companies will ask you esoteric details like this that aren't relevant to your job, in which case you should avoid them anyway. It's usually from immature devs that just go down a laundry list of stuff just because it's "easier to grade". Note I'm not referring to Javascript "weirdness" that may seem esoteric but is actually pretty important to know. For example, anyone who has been programming in javascript for more than a hot minute should know `typeof null === 'object'`, because (a) nearly everyone hits this as a bug at least once and thinks "that's nutty", and then (b) if you don't know this you will be likely to write bugs in your code. 2. This also doesn't apply if you're interviewing for a job where you need to know those esoteric details, like the other commenter who replied who wrote a transpiler. But if you're just, say, a front-end web dev, yeah asking some of the nuttier details (especially all of the inherent type conversion rules) is sign of a bad company IMO.
  - johnnyanmac 2y ago
    >Shitty companies will ask you esoteric details like this that aren't relevant to your job, in which case you should avoid them anyway. I sure do wish I had the luxury to do that. How the times have changed so quickly. That's pretty much why I detest the leetcode stuff that pops up even in games interviews. I'm going to be digging into decades old poorly documented legacy code to provide custom tooling for a studio's workflow. Why the hell do I need to know how to make NxN Bingo solver in Log(N) time on the fly? I guess if you gave me 20 minutes to refresh myself on dynamic progamming I could do it, but I made the "mistake" of studdying Unreal Engine/C++ trivia instead (which I've also had on other interviews), as well as real questions like what impacts and tasks I was doing at other studios. But it's a circus out there and I just have to put on the makeup. I'm preparing long term to not have to deal with this, but I just need another 3 years or so minimum to stabilize myself and prepare my plans.
hn_throwaway_99 2y ago
Besides yet another "damn, Javascript is whack" article, I thought a lot of the details were actually really interesting, and stuff that I either outright didn't know or had just forgotten because I use TypeScript and a lot of these thing would make the TS compiler complain. For example, I can't remember the last time I used the `var` keyword, and I had either forgotten or never really realized it had subtly different semantics compared to `let` and `const`, e.g. with respect to hoisting rules.
- tstrimple 2y ago
  Which in this case most folks have moved on to let and const. But tons of code in the wild is still sprinkled with var. If you’re mostly working greenfield JavaScript, you can ignore a lot of the warts and have a pretty good experience. If you’re working on a lot of legacy stuff you’ll see mixed use of var and let and it’s quite helpful to understand the differences more fully.
seanp2k2 2y ago
This. If this were part of a coding interview, I'd pass on the company. Don't do this. This is also why real developers use tests and actually try things before shipping them, as almost all of these fictional scenarios should be caught ahead of time by any reasonably sane tests.

I'd never call myself a JS dev but have used it to develop web pages on the side. this list shows me how little I really understand the more intimate details of JS. I'd personally love to see a variation of this for C/C++/C#. And in all fairness, "stuff no one should ever need to worry about" is prime interview material for jobs. Though there's so many formats of technical interviews you never really know.

rnallandigal 2y ago
https://cppquiz.org https://cppquiz.org contains a list of similar questions in C++.
- johnnyanmac 2y ago
  perfect, that was exactly what I was looking for. Thanks!
hn_throwaway_99 2y ago
> And in all fairness, "stuff no one should ever need to worry about" is prime interview material for jobs. In reality, when I've seen this: 1. Shitty companies will ask you esoteric details like this that aren't relevant to your job, in which case you should avoid them anyway. It's usually from immature devs that just go down a laundry list of stuff just because it's "easier to grade". Note I'm not referring to Javascript "weirdness" that may seem esoteric but is actually pretty important to know. For example, anyone who has been programming in javascript for more than a hot minute should know `typeof null === 'object'`, because (a) nearly everyone hits this as a bug at least once and thinks "that's nutty", and then (b) if you don't know this you will be likely to write bugs in your code. 2. This also doesn't apply if you're interviewing for a job where you need to know those esoteric details, like the other commenter who replied who wrote a transpiler. But if you're just, say, a front-end web dev, yeah asking some of the nuttier details (especially all of the inherent type conversion rules) is sign of a bad company IMO.
- johnnyanmac 2y ago
  >Shitty companies will ask you esoteric details like this that aren't relevant to your job, in which case you should avoid them anyway. I sure do wish I had the luxury to do that. How the times have changed so quickly. That's pretty much why I detest the leetcode stuff that pops up even in games interviews. I'm going to be digging into decades old poorly documented legacy code to provide custom tooling for a studio's workflow. Why the hell do I need to know how to make NxN Bingo solver in Log(N) time on the fly? I guess if you gave me 20 minutes to refresh myself on dynamic progamming I could do it, but I made the "mistake" of studdying Unreal Engine/C++ trivia instead (which I've also had on other interviews), as well as real questions like what impacts and tasks I was doing at other studios. But it's a circus out there and I just have to put on the makeup. I'm preparing long term to not have to deal with this, but I just need another 3 years or so minimum to stabilize myself and prepare my plans.

hn_throwaway_99 2y ago

Besides yet another "damn, Javascript is whack" article, I thought a lot of the details were actually really interesting, and stuff that I either outright didn't know or had just forgotten because I use TypeScript and a lot of these thing would make the TS compiler complain. For example, I can't remember the last time I used the `var` keyword, and I had either forgotten or never really realized it had subtly different semantics compared to `let` and `const`, e.g. with respect to hoisting rules.

tstrimple 2y ago
Which in this case most folks have moved on to let and const. But tons of code in the wild is still sprinkled with var. If you’re mostly working greenfield JavaScript, you can ignore a lot of the warts and have a pretty good experience. If you’re working on a lot of legacy stuff you’ll see mixed use of var and let and it’s quite helpful to understand the differences more fully.

seanp2k2 2y ago

This. If this were part of a coding interview, I'd pass on the company. Don't do this. This is also why real developers use tests and actually try things before shipping them, as almost all of these fictional scenarios should be caught ahead of time by any reasonably sane tests.