8 ms·

I've had interview candidates for frontend developer positions who only know how to build web pages using frameworks like Angular and React. They don't seem to

by nkassis 10y ago

I've had interview candidates for frontend developer positions who only know how to build web pages using frameworks like Angular and React. They don't seem to understand how those frameworks work but essentially patch together a bunch of example online to get something going. It's truly unfortunate that many beginner web development tutorial introduce these technologies first in my view. Without giving new developers understanding basics of the web platform they get siloed into only knowing one way to do things and it results in using the wrong tools for the job as this example shows.

noobermin 10y ago
Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows? Perhaps the right answer is to code know the basics but also have a handle on the popular frameworks too.
- nkassis 10y ago
  "Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows?" Yes more likely. In fact I would find informative to see the framework that you have built as an example of understanding web development. To expand a bit I think learning the framework is easier once you have an understanding of the web platform's basic. For non web stuff I value more problem solving ability, general CS knowledge over specific technology knowledge. I usually don't set a language requirements in interviews and look more to someone being able to explain how the code they wrote works and why it's a better solution than say some inefficient brute force method. Which in my example when applied to web stuff would translate to why is implementing something this way in angular better than an alternative, what advantages did you gain from angular. Etc...
  - __s 10y ago
    My framework looks like this: https://github.com/serprex/openEtG/blob/master/dom.js https://github.com/serprex/openEtG/blob/master/dom.js The code that uses it looks like this: https://github.com/serprex/openEtG/blob/master/views/MainMenu.js https://github.com/serprex/openEtG/blob/master/views/MainMen... The site looks like this: http://etg.dek.im http://etg.dek.im I recently worked on a site at my job where I was able to implement it with JS + C#/OWIN, all static html, only uses toastr/jquery. Was nice they let me break away from the illusion that the choice is only between WebForms or MVC If you ask me to compare this to Angular, I'd have to say I've never used Angular so I don't know
    - sorry 10y ago
      Seeing that code I would not hire you.
      - Can_Not 10y ago
        Any specific reason? Not trying to be accusatory, but your comment appears not genuine and I don't see anything instantly unhirable about his code after a short peruse.
- dasil003 10y ago
  Depends what you're being hired for, but I tend to believe hiring managers are overly biased towards CV bullet points on the highest common library/framework in the stack. This is after all the most precise information you can put in a job description that is actionable by a recruiter/HR-person. But in my view, building your own framework first and then learning a standard equivalent gives you a much better understanding of the tech of the new framework which will pay dividends. For instance, I built my own PHP framework in 2001, and subsequently played around with Drupal/Django/other homegrown frameworks. When Rails dropped in 2004 I was immediately ready to jump on board because I had been through the same mental process as DHH had when he started building Basecamp in Ruby after having been frustrated by PHP. Whereas a lot of people complained about Rails' magic and lack of transparency, to me it was very easy to dive into the source code and understand the reasoning that led to its architecture. Of course these things calcify over time, and you don't need to necessarily go very deep into every layer of the stack, but you have to at least be competent in a few layers or you'll be helpless the minute you hit a problem with a leaky abstraction. But in the case of JS, yes I think any time spent learning core JS is well-spent, and knowing only React/Angular is a real liability as a front-end engineer, especially because those frameworks are designed to solve heavy SPA problems which are only a tiny subset of the type of interactive web pages one might want to create.
- vinceguidry 10y ago
  I'd hire you but I'd still make you use a framework. Convention makes code readable and maintainable. A framework is essentially shared convention that you don't have to maintain. Making your own framework shows that you understand the value of convention. A framework means that spaghetti code can only get so bad. A bad ad-hoc implementation of a web platform is an order of magnitude worse than bad code written on top of a popular web platform. When I look at ugly React code, I know how to extract logic, where to push it, how to identify poorly-named concepts. When I look at ugly vanilla JS, I don't know what to make of anything.
sn0v 10y ago
How would you suggest breaking out of that silo?
- Zeklandia 10y ago
  Asking for a friend? ;)
  - sn0v 10y ago
    Haha you know it :)
- nambit 10y ago
  Start from scratch/plain ol html. Add dependencies as you need them and for very specific purposes rather than have them "just because"
  - nkassis 10y ago
    Right, start with something simple, say a form and add client side validation to it. Move to making a small widget that updates with data obtained async using plain XHR. Add some styling with out preprocessors (so you know why they make life easier). Understand events and how they propagate etc. Learn a bit about the DOM and how to query it with built in apis. Etc... Consult MDN (Mozilla developer network) and read their articles
- jlg23 10y ago
  Stay curious. If you know only one framework, read its source and understand every bit of it (or which parts you can ignore and why).
clifanatic 10y ago
> only know how to build web pages using frameworks like Angular and React I've never been able to fathom how anybody can do that without understanding the foundation that it's built on. At the bare minimum, how the heck do these people troubleshoot errors? If you have so much as a typo in your code, Angular is going to give you a completely cryptic jQuery error message.
- mlvljr 10y ago
  ...and then Google brings you to the corresponding StackOverflow page :)
- sanderjd 10y ago
  This is why I came to really dislike angular pretty quickly. Maybe it's just evidence that I suck at javascript, but I found it devilishly difficult to debug even seemingly simple issues. But the errors were not in jquery, they were in the maze of the digest cycle. But I agree, I have no idea how beginners manage when things fall off the happy path.
brudgers 10y ago
I think it's partially an artifact of JavaScript's historical arc. Piecing together examples was maybe not best practice, but it was pretty damn good practice in the days when Jquery was best practice and in those days Jquery was best practice because browsers varied. I mean the alternative to using black boxes was to recreate Jquery. It's also partially an artifact of JavaScript's lack of namespaces and scoping rules and prototypical inheritance because these make it easy to make a class of errors that are conceptually difficult to understand without holding a complex mental model in my head...and that's after standardization of browsers reduced the number of arbitrary rules that could cause bugs.

by nkassis 10y ago

noobermin 10y ago

Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows? Perhaps the right answer is to code know the basics but also have a handle on the popular frameworks too.

nkassis 10y ago
"Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows?" Yes more likely. In fact I would find informative to see the framework that you have built as an example of understanding web development. To expand a bit I think learning the framework is easier once you have an understanding of the web platform's basic. For non web stuff I value more problem solving ability, general CS knowledge over specific technology knowledge. I usually don't set a language requirements in interviews and look more to someone being able to explain how the code they wrote works and why it's a better solution than say some inefficient brute force method. Which in my example when applied to web stuff would translate to why is implementing something this way in angular better than an alternative, what advantages did you gain from angular. Etc...
- __s 10y ago
  My framework looks like this: https://github.com/serprex/openEtG/blob/master/dom.js https://github.com/serprex/openEtG/blob/master/dom.js The code that uses it looks like this: https://github.com/serprex/openEtG/blob/master/views/MainMenu.js https://github.com/serprex/openEtG/blob/master/views/MainMen... The site looks like this: http://etg.dek.im http://etg.dek.im I recently worked on a site at my job where I was able to implement it with JS + C#/OWIN, all static html, only uses toastr/jquery. Was nice they let me break away from the illusion that the choice is only between WebForms or MVC If you ask me to compare this to Angular, I'd have to say I've never used Angular so I don't know
  - sorry 10y ago
    Seeing that code I would not hire you.
    - Can_Not 10y ago
      Any specific reason? Not trying to be accusatory, but your comment appears not genuine and I don't see anything instantly unhirable about his code after a short peruse.
dasil003 10y ago
Depends what you're being hired for, but I tend to believe hiring managers are overly biased towards CV bullet points on the highest common library/framework in the stack. This is after all the most precise information you can put in a job description that is actionable by a recruiter/HR-person. But in my view, building your own framework first and then learning a standard equivalent gives you a much better understanding of the tech of the new framework which will pay dividends. For instance, I built my own PHP framework in 2001, and subsequently played around with Drupal/Django/other homegrown frameworks. When Rails dropped in 2004 I was immediately ready to jump on board because I had been through the same mental process as DHH had when he started building Basecamp in Ruby after having been frustrated by PHP. Whereas a lot of people complained about Rails' magic and lack of transparency, to me it was very easy to dive into the source code and understand the reasoning that led to its architecture. Of course these things calcify over time, and you don't need to necessarily go very deep into every layer of the stack, but you have to at least be competent in a few layers or you'll be helpless the minute you hit a problem with a leaky abstraction. But in the case of JS, yes I think any time spent learning core JS is well-spent, and knowing only React/Angular is a real liability as a front-end engineer, especially because those frameworks are designed to solve heavy SPA problems which are only a tiny subset of the type of interactive web pages one might want to create.
vinceguidry 10y ago
I'd hire you but I'd still make you use a framework. Convention makes code readable and maintainable. A framework is essentially shared convention that you don't have to maintain. Making your own framework shows that you understand the value of convention. A framework means that spaghetti code can only get so bad. A bad ad-hoc implementation of a web platform is an order of magnitude worse than bad code written on top of a popular web platform. When I look at ugly React code, I know how to extract logic, where to push it, how to identify poorly-named concepts. When I look at ugly vanilla JS, I don't know what to make of anything.

sn0v 10y ago

How would you suggest breaking out of that silo?

Zeklandia 10y ago
Asking for a friend? ;)
- sn0v 10y ago
  Haha you know it :)
nambit 10y ago
Start from scratch/plain ol html. Add dependencies as you need them and for very specific purposes rather than have them "just because"
- nkassis 10y ago
  Right, start with something simple, say a form and add client side validation to it. Move to making a small widget that updates with data obtained async using plain XHR. Add some styling with out preprocessors (so you know why they make life easier). Understand events and how they propagate etc. Learn a bit about the DOM and how to query it with built in apis. Etc... Consult MDN (Mozilla developer network) and read their articles
jlg23 10y ago
Stay curious. If you know only one framework, read its source and understand every bit of it (or which parts you can ignore and why).

clifanatic 10y ago

> only know how to build web pages using frameworks like Angular and React I've never been able to fathom how anybody can do that without understanding the foundation that it's built on. At the bare minimum, how the heck do these people troubleshoot errors? If you have so much as a typo in your code, Angular is going to give you a completely cryptic jQuery error message.

mlvljr 10y ago
...and then Google brings you to the corresponding StackOverflow page :)
sanderjd 10y ago
This is why I came to really dislike angular pretty quickly. Maybe it's just evidence that I suck at javascript, but I found it devilishly difficult to debug even seemingly simple issues. But the errors were not in jquery, they were in the maze of the digest cycle. But I agree, I have no idea how beginners manage when things fall off the happy path.

brudgers 10y ago

I think it's partially an artifact of JavaScript's historical arc. Piecing together examples was maybe not best practice, but it was pretty damn good practice in the days when Jquery was best practice and in those days Jquery was best practice because browsers varied. I mean the alternative to using black boxes was to recreate Jquery. It's also partially an artifact of JavaScript's lack of namespaces and scoping rules and prototypical inheritance because these make it easy to make a class of errors that are conceptually difficult to understand without holding a complex mental model in my head...and that's after standardization of browsers reduced the number of arbitrary rules that could cause bugs.