Here is something that unfortunately cost me a job as a front end "engineer" at Facebook. It's so simple and I fucking cringe when I think about it but they had me on a phone interview and wanted to do a live coding session, so the guy on interview could see what I was typing in real time. He asked me to code a function that would "walk the DOM", so a recursive function that would return all DOM elements below a particular element. Not that hard and something that I had coded more than once back around 2005 when I was getting started in web dev and before jQuery and similar libs were so common place. Trouble is since then I had grown to rely more and more on libs like jQuery because I didn't have time to fuss with raw js when working against inconsistent DOM APIs, not to mention every project I worked on was always on a tight deadline, so I choked on the phone trying to code this function because I hadn't coded something like that in a while. He was not impressed.
All of this was AFTER I had completed some programming task for them as a test on my own time. It was a pretty difficult scheduling problem but I kept working at it until I had a reusable elegant solution and I completed it well within their allotted time limit. That all meant nothing to them as soon as they saw that I was getting frustrated with writing a function I hadn't needed for years in less than 30 seconds. I asked them if they really avoided using jQuery in their code base. They said they avoid it because it's heavy on bandwidth... they avoid using the massive productivity boost to developers because it's heavy on bandwidth. I don't even believe that to be true. I think they were just feeding me a line in order to justify forcing me to code something using the raw DOM API.
So what is the lesson here? FUCK FACEBOOK!
No, the real lesson is to not grow too dependent on libraries, but this is largely dependent on the culture of the shop you happen to work in. In my experience, most places understand that libraries are designed to save time and energy that would be better spent building applications instead of writing a million and one workarounds for browser bugs, but you never know when the situation is going to call for lower level browser specific javascript APIs.
Here is something that unfortunately cost me a job as a front end "engineer" at Facebook. It's so simple and I fucking cringe when I think about it but they had me on a phone interview and wanted to do a live coding session, so the guy on interview could see what I was typing in real time. He asked me to code a function that would "walk the DOM", so a recursive function that would return all DOM elements below a particular element. Not that hard and something that I had coded more than once back around 2005 when I was getting started in web dev and before jQuery and similar libs were so common place. Trouble is since then I had grown to rely more and more on libs like jQuery because I didn't have time to fuss with raw js when working against inconsistent DOM APIs, not to mention every project I worked on was always on a tight deadline, so I choked on the phone trying to code this function because I hadn't coded something like that in a while. He was not impressed.
All of this was AFTER I had completed some programming task for them as a test on my own time. It was a pretty difficult scheduling problem but I kept working at it until I had a reusable elegant solution and I completed it well within their allotted time limit. That all meant nothing to them as soon as they saw that I was getting frustrated with writing a function I hadn't needed for years in less than 30 seconds. I asked them if they really avoided using jQuery in their code base. They said they avoid it because it's heavy on bandwidth... they avoid using the massive productivity boost to developers because it's heavy on bandwidth. I don't even believe that to be true. I think they were just feeding me a line in order to justify forcing me to code something using the raw DOM API.
So what is the lesson here? FUCK FACEBOOK!
No, the real lesson is to not grow too dependent on libraries, but this is largely dependent on the culture of the shop you happen to work in. In my experience, most places understand that libraries are designed to save time and energy that would be better spent building applications instead of writing a million and one workarounds for browser bugs, but you never know when the situation is going to call for lower level browser specific javascript APIs.