Coincidentally, I just commented yesterday about an interview experience I had about the DOM. I did not expect it to be so highly upvoted. https://news.ycombinator.com/item?id=22740897
I don’t know if I would pass your test, but the outcome is more or less exactly what I would have expected. The vast majority of employed web devs do not use pure JS to manipulate the DOM because it’s incredibly tedious. That was true 5-10 years ago when the most popular option was JQuery, and now we have massive swaths of React where people don’t manipulate the DOM directly at all. And they get by just fine. Major commercial sites are built with little to no direct DOM manipulation.
Saying that you’re going to let people have time, use the web to lookup the answer, that there’s no penalty, etc., that seems blind to the fact that you’re signaling what it takes to pass the test as well as what people will be doing once they start working for you. I’m certain you lost the opportunity to interview some good candidates simply because they are choosing to not work somewhere that thinks pure JS is the only performant solution, and might not know that there are both good and bad ways to use JQuery, and/or functional reactive solutions that avoid keeping messy/buggy state around when you could instead re-render. I’m sure you also lost interviews because some candidates were basically told by you that already knowing how to manipulate the DOM via pure JS was what was required to ace the interview. They assumed, and reasonably so, that spending the hour showing you they didn’t already know how would result in not getting a job, so why bother with the interview right now? You might have sent several smart people off to study and do homework about it, but you don’t know that because they walked out the door.
So, while I do think it’s very useful to know how to use pure JS on the DOM, and I think your interview experience is interesting, the incredulity about it makes it seem to me like you’re not entirely taking responsibility for the implicit message that you sent to your candidates for the interview, nor that the outcome is fairly predictable.
The job position was for people to write A/B tests. A/B tests are a form of white hat hacking where code is injected into a page to manipulate or deface the page to test a business idea as an experiment.
It would not make sense to inject something like Angular or React as part of test code and would be detrimentally regressive to inject Angular or React targeted logic over an existing framework application without a more thorough consideration for second and third order consequences. An experiment is meant to be something that is created with the least possible labor since its not production code and short lived.
That said the most desirable approach was to manipulate the DOM directly since this achieved the fastest execution, provided the smallest risk/footprint, and was fastest to QA for regression.
---
In hindsight we learned a couple of things from A/B testing.
* In a page with a lot of asynchronously loading content everything can be precisely altered before the user can notice it. The more precise form of delay were recursive setTimeouts where the interval delay could be manually adjusted to the millisecond and there was never interval overlap. This took practice to know when and where to increase the interval rate without impacting the performance of other logic already in the page.
* The tests did not often reflect the actual business results compared to the production code written later. We found the test logic, even though it was just hacky throwaway code, was generally less defective and faster executing than the more thoroughly tested production code and so performed better than the actual results from the formally released code.
> A/B tests are a form of white hat hacking where code is injected into a page
No. The idea of A/B testing does not require DOM manipulation or code "injection" after the fact on an already rendered page. I don't know about your A/B tests, but A/B tests in general are site experiments you run on your users/customers -- the idea does not in general involve code injection, or say anything about the implementation. I have built A/B tests in React myself, and there is simply zero technical or performance issues with doing so. You render one thing for some people, and a different thing for other people, and measure their reactions.
It might not make sense to use React or Angular for you, for your particular site design, but there is nothing wrong with implementing A/B testing using React in general.
There's nothing wrong with using JQuery either, if you want direct DOM manipulation. It would be worth studying why your previous A/B tests were slow, because it can uncover some knowledge about JQuery. There are bad practices in JQuery, there are ways to do things really slowly. There are also ways to fix it when it goes slow, and learning those things might be overall a lot more efficient than resorting to pure JS DOM manipulation.
Yeah, that makes sense. The specifics of what you're doing certainly will drive what the implementation looks like. It makes sense that using Omniture for tests means that pure JS DOM manipulation is the best way forward. This detail is actually incredibly important to your story, and so I think it's easier than not to draw the wrong conclusion from the story because that important detail was left out. Omniture testing might be something a lot of candidates aren't exactly clamboring to spend their time doing. Certainly, with an A/B testing job I would be hoping and aspiring to learn more about things like site UX, maybe some data science, do HTML & JS that is relevant to the business team, and be involved in the production site's implementation and design, etc. I would personally be less excited about using an older legacy testing framework that requires low level DOM hacking, especially if it seemed separated from the core dev team. How do you implement the design that wins? Does the A/B test writer's version get put into production, or does someone else take the code injection and translate it into HTML?
> Major commercial sites are built with little to no direct DOM manipulation.
Little implies some, and I think the average bundle is already large enough without saying, "Oh, just throw jQuery in there whenever you do need to do DOM manipulations.", which will happen. I built a React app a couple weeks ago where I had to use portals to integrate it with a legacy form solution because we didn't have time to rewrite the entire form backend to justify a custom frontend. It involved a fair amount of manual DOM manipulation, but it worked out fine. All said and done, it was probably ~75 lines in a file with a few more comments than usual. It doesn't make sense to add 30kb or even 10kb to the bundle for that, so yes, I would expect the average developer to know the base DOM api at least somewhat well.
edit: I completely forgot about TDD. Depending on your testing environment, you may need to understand the DOM api for mocking or base utilities built into the test suite.
I did not suggest using React and Jquery at the same time, and I don't really encourage that. I do not agree that it's a slippery slope and people will just start using JQuery with React. It's possible that something is already starting to go wrong if you're trying to manipulate the DOM using both React and DOM manipulation. The very point of React is to avoid direct DOM manipulation.
I've been in about half a dozen interviews in the last 6 months and I've never had to do this problem, but honestly my first reaction would be "this is a trick problem" out of paranoia that it's too easy. I wonder if more anxious people fall into that trap and overthink it to the point of overwhelming themselves; kind of like freezing up during an exam that you studied extensively for.
My biggest issue in interviews is remembering the recursion formula with some of the sorting algorithms. I eventually get it, but I end up burning a good chunk of time figuring it out, so it looks bad. In my entire career (almost 15 years now?), I've never had to use recursion or sorting algorithms believe it or not. That's what I get for working strictly on enterprise business applications.
