5 ms·

Somewhat relevantly, a closure isn't a "specific thing in a specific framework." Its a concept that exists in many languages, and has no real relation to framew

Somewhat relevantly, a closure isn't a "specific thing in a specific framework." Its a concept that exists in many languages, and has no real relation to frameworks. I would never treat someone like they're stupid in an interview, but being completely unfamiliar with common programming concepts and treating them as irrelevant or trivial things is definitely a red flag.

trinovantes 5y ago
The person may know what is and how to use it without knowing its formal definition in programming language theory. I personally find interview questions that ask you to regurgitate definitions like an exam to be poor indicators of real world skills. It would better if the interviewer first established terminology to avoid confusion and then ask how they would use such language constructs
- machello13 5y ago
  I don't think it's unreasonable to expect someone applying for an engineering role to know the technical terminology of their field. Especially if they've been "programming for many years" as this person has.
ramraj07 5y ago
I know approximately what a closure is, and I am sure I have used such constructs instinctively in my work many times. I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff. Once a guy asked me to write out merge sort on a whiteboard and I couldn't. I didn't get the job. Surprisingly I'm doing just fine in my current position and am very productive (as much as I may say so myself) and have never heard complaints from anyone that I don't know what I'm doing. So if you don't see a CS degree in the resume then don't ask what a closure is or to implement a merge sort in the interview. Ask them to solve a real problem. The top computer scientists didn't discover the merge sort for years or decades and you want me to figure it out on the spot? Or you just expect me to memorize useless shit like this? Give a problem a programmer would encounter on a day to day basis that wouldn't need a lot of googling. Let them figure out how to solve it and see if it works for you.
- Leherenn 5y ago
  You probably won't need merge sort in your day to day programming, but closures (sometimes called lambdas), definitely. Every time you create a function that captures some variables outside its scope, congratulations, you've just used a closure.
  - Rapzid 5y ago
    Yeah, without knowing the term closure or lambda(which are not necessarily closures but could be as an implementation detail) I'm not sure how one would effectively communicate with others about code in a high-functioning environment using high-level languages. They are very widely used.
  - deleted 5y ago
    [deleted]
  - mewpmewp2 5y ago
    The point being here is that you can use them, but you don't have to necessarily know the term for them. The only reason I know what a closure is in JavaScript is because I have heavily practiced for Frontend interviews. I've been otherwise using them productively forever now.
    - imtringued 5y ago
      That's true. The problem in this case is that they are weeding out applicants based on their knowledge of terminology. Talking about a concrete code sample may not fall into that trap.
  - readonthegoapp 5y ago
    i now know of closures, and have actually used them intentionally, and rarely, and def not enthusiastically. i lived mostly in the java world, and discovered closures when i was getting wacky results while playing around with a Clojure looping example. then ran into similar situations about once a year when doing something in javascript -- usually passing some function for a callback, and needing access to 'this' in the original/calling scope - which only confused things when i needed access to 'this' in the (local?) function scope, too. guess i'm not against closures -- they just seem mysterious to me. ditto lambdas. they seem like a good way to write esoteric code, and write more error-prone/less-defensive code -- that, for instance, might be more likely to produce NPEs, and generally be less maintainable b/c of the focus on brevity instead of clarity, and be geared more towards expert users/coders instead of the generalists (like me) who are often brought in to maintain older code.
brundolf 5y ago
Adding to this, I think even a little bit of genuine esoterica is okay in an interview process so long as: 1) You're looking for someone with deep knowledge of that subject 2) You don't treat it as an automatic fail when they get it wrong If I'm interviewing for a senior role, and I ask them a few super obscure questions about the language/framework/platform I need them to be an expert on, that serves as a litmus test for their overall depth of knowledge. Those facts individually may not be required for the job, but they give a read on how deep the person's knowledge goes in general. But, as you pointed out, I wouldn't really even put closures in that category. For JS it would be something more like, "What does '{} + 12' evaluate to?"
- Rapzid 5y ago
  > For JS it would be something more like, "What does '{} + 12' evaluate to?" It would be really hard for me to take the process serious if I was asked that during an interview.
  - brundolf 5y ago
    Again, it's just a signifier. If you know the answer (or can explain a good guess!), you probably also know a bunch of actually-useful dark corners of the language. If you don't know the answer, you may still know all those other things. It's just one data point among many.
- dorgo 5y ago
  ({}) + 12 evaluates to "[object Object]12" omg, I need to learn / start using typescript
  - brundolf 5y ago
    You're right! Though the original question - '{} + 12' - is extra tricky and actually evaluates to 12 ;) I'll leave figuring out why as an exercise for the reader
    - dorgo 5y ago
rmk 5y ago
If you claim to be very experienced in JavaScript but then say that you are ignorant of closures, then that's definitely a red flag. That language relies heavily on closures, more than others, and almost every programming pattern in the browser involves capturing some sort of state about enclosing scopes etc. given the asynchronous nature of things. The inordinate amount of space the article devotes to complaining about 'credentialism' just reinforces the impression that the writer hasn't taken the time to know his tools/languages/frameworks at a deeper level, and is dismayed to have been found out in interviews.

trinovantes 5y ago

The person may know what is and how to use it without knowing its formal definition in programming language theory. I personally find interview questions that ask you to regurgitate definitions like an exam to be poor indicators of real world skills. It would better if the interviewer first established terminology to avoid confusion and then ask how they would use such language constructs

machello13 5y ago
I don't think it's unreasonable to expect someone applying for an engineering role to know the technical terminology of their field. Especially if they've been "programming for many years" as this person has.

ramraj07 5y ago

I know approximately what a closure is, and I am sure I have used such constructs instinctively in my work many times. I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff. Once a guy asked me to write out merge sort on a whiteboard and I couldn't. I didn't get the job. Surprisingly I'm doing just fine in my current position and am very productive (as much as I may say so myself) and have never heard complaints from anyone that I don't know what I'm doing. So if you don't see a CS degree in the resume then don't ask what a closure is or to implement a merge sort in the interview. Ask them to solve a real problem. The top computer scientists didn't discover the merge sort for years or decades and you want me to figure it out on the spot? Or you just expect me to memorize useless shit like this? Give a problem a programmer would encounter on a day to day basis that wouldn't need a lot of googling. Let them figure out how to solve it and see if it works for you.

Leherenn 5y ago
You probably won't need merge sort in your day to day programming, but closures (sometimes called lambdas), definitely. Every time you create a function that captures some variables outside its scope, congratulations, you've just used a closure.
- Rapzid 5y ago
  Yeah, without knowing the term closure or lambda(which are not necessarily closures but could be as an implementation detail) I'm not sure how one would effectively communicate with others about code in a high-functioning environment using high-level languages. They are very widely used.
- deleted 5y ago
  [deleted]
- mewpmewp2 5y ago
  The point being here is that you can use them, but you don't have to necessarily know the term for them. The only reason I know what a closure is in JavaScript is because I have heavily practiced for Frontend interviews. I've been otherwise using them productively forever now.
  - imtringued 5y ago
    That's true. The problem in this case is that they are weeding out applicants based on their knowledge of terminology. Talking about a concrete code sample may not fall into that trap.
- readonthegoapp 5y ago
  i now know of closures, and have actually used them intentionally, and rarely, and def not enthusiastically. i lived mostly in the java world, and discovered closures when i was getting wacky results while playing around with a Clojure looping example. then ran into similar situations about once a year when doing something in javascript -- usually passing some function for a callback, and needing access to 'this' in the original/calling scope - which only confused things when i needed access to 'this' in the (local?) function scope, too. guess i'm not against closures -- they just seem mysterious to me. ditto lambdas. they seem like a good way to write esoteric code, and write more error-prone/less-defensive code -- that, for instance, might be more likely to produce NPEs, and generally be less maintainable b/c of the focus on brevity instead of clarity, and be geared more towards expert users/coders instead of the generalists (like me) who are often brought in to maintain older code.

brundolf 5y ago

Adding to this, I think even a little bit of genuine esoterica is okay in an interview process so long as: 1) You're looking for someone with deep knowledge of that subject 2) You don't treat it as an automatic fail when they get it wrong If I'm interviewing for a senior role, and I ask them a few super obscure questions about the language/framework/platform I need them to be an expert on, that serves as a litmus test for their overall depth of knowledge. Those facts individually may not be required for the job, but they give a read on how deep the person's knowledge goes in general. But, as you pointed out, I wouldn't really even put closures in that category. For JS it would be something more like, "What does '{} + 12' evaluate to?"

Rapzid 5y ago
> For JS it would be something more like, "What does '{} + 12' evaluate to?" It would be really hard for me to take the process serious if I was asked that during an interview.
- brundolf 5y ago
  Again, it's just a signifier. If you know the answer (or can explain a good guess!), you probably also know a bunch of actually-useful dark corners of the language. If you don't know the answer, you may still know all those other things. It's just one data point among many.
dorgo 5y ago
({}) + 12 evaluates to "[object Object]12" omg, I need to learn / start using typescript
- brundolf 5y ago
  You're right! Though the original question - '{} + 12' - is extra tricky and actually evaluates to 12 ;) I'll leave figuring out why as an exercise for the reader
  - dorgo 5y ago

rmk 5y ago

If you claim to be very experienced in JavaScript but then say that you are ignorant of closures, then that's definitely a red flag. That language relies heavily on closures, more than others, and almost every programming pattern in the browser involves capturing some sort of state about enclosing scopes etc. given the asynchronous nature of things. The inordinate amount of space the article devotes to complaining about 'credentialism' just reinforces the impression that the writer hasn't taken the time to know his tools/languages/frameworks at a deeper level, and is dismayed to have been found out in interviews.