3 ms·

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 pa

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.

dahart 7y ago
> 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.
- austincheney 7y ago
  > No. The idea of A/B testing does not require DOM manipulation or code "injection". We were using Adobe's Test and Target (Omniture) application for launching and measuring our tests. It works via code injection.
  - dahart 7y ago
    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?

dahart 7y ago

> 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.

austincheney 7y ago
> No. The idea of A/B testing does not require DOM manipulation or code "injection". We were using Adobe's Test and Target (Omniture) application for launching and measuring our tests. It works via code injection.
- dahart 7y ago
  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?