I remember one time I was hiring for a JavaScript developer. The most important technical competency was a brief working knowledge of the DOM. The actual position required modifications to pages for A/B tests and jQuery was either too slow or broke in production when other developers used it for their test code.
Of everybody that passed through HR to me I sent out a notice that there would be a minor code assessment and they could not use jQuery. 6 or 7 people instantly dropped out. There were 22 people left that I actually talked to which only three could pass the code assessment.
The assessment was never designed to be challenging. Candidates were using their home computers had access to any reference material. There was no hurry. They could look things up. I also told them if they got stuck just ask me and I would point them in the right direction without any penalty, but only 2 candidates tried that.
The assessment was an hour long phone call. At the start of the call I would send out a static HTML page for the candidates to open in their browser and for them to write an answer in whatever tool they wanted but it had to execute in the console of a browser on that page. Tasks were things like take this item out of the page and reinsert at some other location or change the color of a particular paragraph to red. Stupid simple stuff that you would expect any UI developer to do easily. After all these were beginner skills and this was a senior level position.
I did ask to see the code they wrote only to make sure they completed the tasks. I would drop their code in my browser console and run. I never looked at code style or sloppiness. It’s a job interview where people are rushed and nervous. Their code is allowed to be sloppy.
Only 3 candidates were able to pass this code filter. The people that did pass either did well enough to pass or extremely excellent. The people that failed, maybe 19 of 22 people, all failed epically.
That experience really shocked me. I did everything I could think of to make this relaxing and take the edge off because there is always pressure during a job interview. No matter how much of a lifeline I threw out almost nobody would bite. They would sit there silent on the call or they would attempt to stall like that would somehow make code magically appear. Sometimes I would remind candidates they could ask me questions because I cannot evaluate a blank answer. Other times I would try nudge them to get started or guide them into progress, which only seemed to hurt more than help.
> No matter how much of a lifeline I threw out almost nobody would bite. They would sit there silent on the call or they would attempt to stall like that would somehow make code magically appear. Sometimes I would remind candidates they could ask me questions because I cannot evaluate a blank answer. Other times I would try nudge them to get started or guide them into progress, which only seemed to hurt more than help.
Because they felt that it was a false help. If they take it they're disqualifying themselves because they didn't know something.
I suppose they could have assumed I lied about the assistance, but surely they could have reasoned that would be less disqualifying than delivering nothing.
I've had very similar experiences with Delphi, Jade and embedded C developer interviews. It makes me wonder why other companies don't actually care whether I can write new code, only whether I can replay algorithms.
When interviewing I build a set of simple examples like yours and run people through them, normally in person. How they talk to me is also important.
Albeit here in Australia FAANG interviews are mostly regarded as yet another US foible like driving on the wrong side of the road. I've had exactly one attempt in ~10 job changes but they failed (I walked out as soon as they made it obvious that they were serious... but were not offering FAANG money).
I've written a fair amount of vanilla JS over the past 20 years and know what you're talking about.
But in the circle of people that I've talked to, everybody else uses frameworks, and I doubt they could make surgical changes in the browser console.
So you're excluding most of today's working front-end developers, and appealing to "edge cases." I guess you could pre-screen candidates by asking, "Are you familiar with vanilla JS?"
Doesn't something seeming insane automatically make you question and check your own assumptions and information first? Isn't the most likely explanation for your premise either that it's not true, or that your expecations don't match reality?
Is it true that most front-end devs don't know how to manipulate a DOM with JS? I don't know, but it's not exactly true; Jquery is still javascript. Do you do front end dev professionally, and use strictly the pure javascript DOM API with no frameworks? There's a reason most people who do front end dev for a living don't do that: because it's time-consuming and there are easier options. Also because there better options than fiddling with the DOM at all, like React.
Is it insane that most programmers wouldn't be able to code something up in X86 assembly during an interview? (Not to mention that most wouldn't be interested.) To me that seems like a similarly unrealistic expectation.
I'd assume that a developer should at least have a mental model of what DOM is and what it consists of, and that it can be queried and transformed by calling functions on JS objects that represent DOM nodes.
If the dev doesn't remember the names of actual functions (which is no fault, since that comes only with using them regularly), this would at least allow them to figure out what to search for on the Internet and how to use the results.
Is that a far fetched assumption? It's not really comparable to wanting a webdev to write some assembly code.
Well, the original problem seemed to be that interviewees were not able to even find the API. If they had a mental model od DOM, this shouldn't be a problem.
They'd knew that there are nodes, can be queried from the document via JS and moved in relation to other nodes, so they could just google: "move dom node", or "query dom node" and put the pieces together via JS.
Look, yes this very well might be a case of lots of inexperienced people shooting ambitiously high (you don’t win unless you try, right?). And it might be true that most people interviewing for front end jobs don’t know squat. The story above just doesn’t actually demonstrate that.
My point here is that there are other explanations, we can’t jump to the conclusion that the cause is because most people lack a mental model of the DOM, that’s overlooking many possible reasons. Nothing about the state of developers is proven by this anecdote.
The interview specifically asked about an API that most people simply do not use. It’s not a surprise that a bunch of candidates backed out when they learned this, and it’s not a surprise that it was accidentally more challenging than the interviewer thought for those who stayed.
It doesn’t really matter that Google was allowed, it’s an assumption to think that it’s easy to come up with keywords and search terms for a API you haven’t used, during a job interview. I’ve interviewed a lot of people and watched a lot of people freeze during interviews, people that I know would figure it out quickly if I wasn’t interviewing them and they were relaxed. A job interview is a test, and the test administrator isn’t in a position to claim that it should have been relaxing or easy for the test-takers.
I generally don't do front end development professionally.
I do know how to manipulate the DOM without frameworks. Learned it over a weekend.
If I were interviewing for front end, I wouldn't recall the syntax immediately, but I would know what to google or be able to have enough of a conversation with the interviewer to show them I have the basic understanding of what is happening.
I do backend. A similar situation might be something like using curl to make individual http requests.
Yeah, we don't do that in real life and I forget some of the parameters and flags available, but if I acted like I had no idea how to use curl, I hope an interviewer would be very disappointed with that.
The issue here is precisely is about recalling the syntax of a low-level approach, not whether you understand it conceptually. It’s the difference between being asked to make a request using curl, and constructing an HTTP request buffer manually without the help of a wrapper to tool to do it for you. It’d be the same as going to an interview, and having the interviewer ask you to complete an HTTP request on the spot using telnet and a keyboard. Sure, you can look it up, but when you do that you’re showing the interviewer you don’t already know.
Many devs know very well how to manipulate the DOM using JQuery, or construct the page they want using React. Most people do not use the low-level pure JS API. Conceptually I totally know how to make things happen in the DOM. Using the JavaScript built-in API, not really. Yeah it’s easy to learn in a weekend, that doesn’t change the fact that the API is tedious, hardly used in practice by most people, and rarely if ever necessary to use for performance reasons.
You say "The issue here is precisely is about recalling the syntax of a low-level approach, not whether you understand it conceptually" and in a scenario where an interviewer blindsided a candidate with such expectations I would agree, but that's not how we got to this topic.
The parent says, "Candidates were using their home computers had access to any reference material. There was no hurry. They could look things up," which is the opposite of that.
It even says they let candidates know ahead of time that's what the interview was.
I mean come on, people are on here and Reddit all the time acting like it's reasonable to grind leetcode for months to get a job, but a Saturday afternoon of studying the basics for an open book quiz on Monday is too much?
I should have said it’s about “using” the low-level syntax, and not “recalling”. You’re right that the story superficially claimed the interview was open-book and didn’t require memorizing the low level API, but it did say specifically that JQuery was not allowed. It was definitely not about conceptually understanding DOM manipulation.
As an experienced front-end developer, I can see from the story I might have personally bowed out of the interview too, not because I can’t use JavaScript to manipulate the DOM, but because I don’t want to. If the job involves doing that, I might think twice about that job.
You might be over-estimating how easy an open-book quiz is. I don’t think I’d pass an interview that asked me to write only x86 assembly, or write HTTP requests manually, or use pure JS to do what I know how to do in JQuery or React, even if it’s an open book quiz.
Of everybody that passed through HR to me I sent out a notice that there would be a minor code assessment and they could not use jQuery. 6 or 7 people instantly dropped out. There were 22 people left that I actually talked to which only three could pass the code assessment.
The assessment was never designed to be challenging. Candidates were using their home computers had access to any reference material. There was no hurry. They could look things up. I also told them if they got stuck just ask me and I would point them in the right direction without any penalty, but only 2 candidates tried that.
The assessment was an hour long phone call. At the start of the call I would send out a static HTML page for the candidates to open in their browser and for them to write an answer in whatever tool they wanted but it had to execute in the console of a browser on that page. Tasks were things like take this item out of the page and reinsert at some other location or change the color of a particular paragraph to red. Stupid simple stuff that you would expect any UI developer to do easily. After all these were beginner skills and this was a senior level position.
I did ask to see the code they wrote only to make sure they completed the tasks. I would drop their code in my browser console and run. I never looked at code style or sloppiness. It’s a job interview where people are rushed and nervous. Their code is allowed to be sloppy.
Only 3 candidates were able to pass this code filter. The people that did pass either did well enough to pass or extremely excellent. The people that failed, maybe 19 of 22 people, all failed epically.
That experience really shocked me. I did everything I could think of to make this relaxing and take the edge off because there is always pressure during a job interview. No matter how much of a lifeline I threw out almost nobody would bite. They would sit there silent on the call or they would attempt to stall like that would somehow make code magically appear. Sometimes I would remind candidates they could ask me questions because I cannot evaluate a blank answer. Other times I would try nudge them to get started or guide them into progress, which only seemed to hurt more than help.
Very bizarre experience.