6 ms·

> Spending months to get the basics up and running in their React frontends just to be able to think independently of hand-holding tutorials for the most basic

> Spending months to get the basics up and running in their React frontends just to be able to think independently of hand-holding tutorials for the most basic operations. Frontend devs who were present before the advent of the major web frameworks, and worked with the simplicity of js script + DOM (or perhaps jquery as a somewhat transparent wrapper) benefited from seeing the evolution of these frameworks, understanding the motivations behind the problem they solve, and knowing what DOM operations must be going on behind the curtain of these libraries. Approaching it today not from the 'ground up' but from high level down is imo responsible for a lot of jr web devs have surprising lack of knowledge on basic website features. Some, probably a minority, of student web devs may get conditioned to reach for libraries for every problem they encounter, until the kludge of libraries starts to cause bugs in and of itself or they reach a problem that no library is solving for them. I feel like this is particularly bad outcome for web devs because web I feel is uniquely accessible for aspiring developers. You can achieve a ton just piggybacking off the browser and DOM and it's API, the developer tools in the browser etc. But not if you are convinced or otherwise forced to only approach it from the other side -- running before you crawl, or trying to setup a webpack config before you even understand script loading, etc.

sarchertech 4y ago
At my current company we have a take home assignment for some roles. When I have to grade one the first thing I do is check to see whether you can submit the input by pressing enter. About half the time you can’t because it’s not actually a form, and they forgot to add handler for enter.
- 7speter 4y ago
  As someone whose been learning the last few years, a lot of learning materials suggest you don’t make a proper form element and just make your own button instead of using using a form element and all the built in benefits it brings for reasons I don’t really know. I’ve probably wondered about this sort of thing for few good hours total, but I guess this comment steers me in the right direction.
  - Falkon1313 4y ago
    Yeah, don't do that unless you have good reason to do so. Browsers have a standard, default, expected behavior. Sometimes, in rare cases, it makes sense to break that in order to do something else instead. But you shouldn't just silently break it for no reason other than to confuse the user.
  - Mezzie 4y ago
    In addition to what others have mentioned, using elements for their stated/official purpose helps with accessibility. Yes, you can use the role attribute, but some accessibility technology works more completely if you use proper elements. (And just can be easier to use; I guess the best way to compare it is using VO on a site where everything is just divs is like the blind version of this[0] Or Comic Sans. Just visceral 'ugh'.). [0] https://www.theworldsworstwebsiteever.com/ https://www.theworldsworstwebsiteever.com/
- wruza 4y ago
  I always found this behavior strange. Tab often doesn’t work correctly in a browser, cycling through elements that shouldn’t be focused, sometimes in a strange order. Enter submits a form. How does one cycle through “fields” then? I have also seen premature form sends when you hit enter to autocomplete etc. It also creates multiline textarea vs input inconsistency. Desktop frameworks “committed” input on enter and most often focused the next field, so you could skip them by enter enter enter. This worked correctly since FoxPro/TurboVision/Norton times. Only Ctrl-Enter would press a “default” button out of order. But web has its own ways as usual.
- swid 4y ago
  At my current company, we changed enter to stop submitting because it’s not intuitive to users. I think there are exceptions for forms with only one field. So perhaps that isn’t the best litmus test? I wonder if it’s written down that should work as part of the assignment.
  - sarchertech 4y ago
    It’s intuitive to any user who has used a web form anytime for the last 2 decades. Breaking default browser behavior because you find it unintuitive is generally a bad idea. Now if you’re dealing with something that isn’t really a web form—as in you’re overloading input fields for some interactive non form like behavior—then I can see it. In my case, if the person had some well thought out reason for doing it, I might let it slide. But the vast majority of times I’ve seen it, it’s because the person doesn’t even know how to use forms. Not understanding the underlying technology at at least a very basic level is a strike against you in my book.
    - swid 4y ago
      fwiw, in my industry, I should not assume anything about technical literacy. We’ve had honest debates over whether we can even rely on people to have an email address. Again, it’s not that I disagree with most of your premise, but in fact, as the comments (not just mine) show - people have issues with submitting too early, so it can be a good decision to break that depending on context. Fewer errors. Which is why I brought up how the problem is presented to the candidate. You might be filtering out people based on something less universally accepted and understood than you think.
      - sarchertech 4y ago
        Web forms have a default behavior. It doesn’t matter whether you accept it, you should understand it. If you accidentally break it because you don’t understand it, that’s a strike against you in my book. If you consciously break it for a good reason and can coherently defend that reason, that’s a different story.
      - 4y ago
- kasey_junk 4y ago
  I’d suggest adding instructions to handle enter if that is your criteria. When doing a take home exercise the candidate is desperate to figure out what you are judging on. The more you make that explicit the better your outcomes will be. Right now your process biases for enter handler adders. Is that your intent?
  - klodolph 4y ago
    Part of the difference between a junior and a senior role is that people in a senior role are expected to fill in missing details independently, without detailed directions. If you only test people on their ability to follow detailed directions, then you will only be able to test for junior roles. When I give candidates prompts / questions / scenarios, I try to include some specific instructions, but also leave some details out. The idea is to come up with a prompt that junior developers can still work with by going head-on, but which has some open-ended nature to it, to see how people respond to things which are open-ended or even ambiguous. It's not a trick or trap; candidates are explicitly told what's up, and that I'm evaluating not only their ability to solve a problem, but to define the problem in the first place.
    - tptacek 4y ago
      This is kind of silly. Actual senior developers get near-real-time feedback from the rest of the organization, and if their interpretation of a request is off, they get multiple attempts to satisfy the request. None of this is true of a coding exercise. If you want to evaluate a candidate's ability to cut through ambiguity or manage sprawling scope, evaluate that and only that in a specific exercise. Don't just build a shoddy coding test and then rationalize it's weaknesses by saying that good candidates will succeed despite the flaws of the test. That's both disrespectful and un-rigorous.
      - klodolph 4y ago
        > Actual senior developers get near-real-time feedback from the rest of the organization, and if their interpretation of a request is off, they get multiple attempts to satisfy the request. Junior developers get near-real-time feedback from senior developers who are supervising them. Senior developers have to be able to give that feedback, have to be able to anticipate user needs, and have to be able to run long-term projects where you may have to work for days, weeks, or months before receiving critical pieces of feedback. > If you want to evaluate a candidate's ability to cut through ambiguity or manage sprawling scope, evaluate that and only that in a specific exercise. This is a common mistake that I see inexperienced interviewers make. Trying to throw more detailed and specific exercises at candidates is a fool's errand at best, and at worst it means that you're putting candidates through additional tests (and your acceptance rate will suffer). The main problem with ambiguity is that it appears unexpectedly. If you give someone an ambiguous problem and say, "Tell me what is ambiguous about this problem," then you're not testing what you want to know. What you actually want to know is whether candidates can recognize ambiguous problems without being prompted to recognize them--and the reason for this is that ambiguous are extremely common in real-world scenarios. An ambiguous problem is not a trick or a trap. It is explicitly part of the interview process, and interviewees are given guidance that the problems they are given may not be precisely defined. > Don't just build a shoddy coding test and then rationalize it's weaknesses by saying that good candidates will succeed despite the flaws of the test. Why do you say that the coding test is shoddy? My observation is that a large percentage of candidates will succeed at coding tests if you give them an ambiguous prompt. In practice, they will either ask questions to resolve the ambiguity, or just pick a way to resolve the ambiguity for the purposes of the test. This matches real-world scenarios--you are going to often encounter ambiguous or incomplete problems in the real world. If you want a precisely-specified coding problem, then go to Hacker Rank or Project Euler or something like that, or join a competitive programming team.
oldge 4y ago
Looking back over my relatively short 30 year career across an assortment of tech companies (hp, google, microsoft, apple, etc) I would add that this mostly changed due to what was rewarded. Around 15 years ago when the first vestiges of OKR review processes and the idea of "impact" started to form; We shifted our designs from things that made our long term outlook better (simple) to things that were easy to explain to management how they had HUGE impact (complex). Be right back, writing a new design doc for a messaging service and protocol spec to go with it that I can use to pad my next review cycle.
ozim 4y ago
This is a good explanation. Newbies drop directly to webpack/react and are overwhelmed or having a lot of trouble getting some details right. Unfortunately a lot of details that are lost in time are accessible if you go through "build stuff basically from ground" so understanding first "why" we needed these frameworks and what were problems to solve. There is also bunch of people who go to rediscover basic stuff and they claim "you don't need a framework - vanilla js is enough" - but they also miss context and did not run into problems that were pain points before we had frameworks.
Karrot_Kream 4y ago
This is true for other devs as well. I started playing around with networking code as a teenager (back when port 80 (before 443) was prominent but not the clear majority of traffic on the net.) Watching the evolution of TCP, HTTP, the C10K problem, retry storms, and event loops has made a lot of sense: clear responses to clear issues. But I've noticed a lot of junior devs grow up with the solutions (nginx, haproxy, exponential backoff, etc) but don't know the problems that necessitated the solutions. A lot of junior training is teaching juniors which solutions to apply to which problems, because unlike us they didn't watch the field evolve to where it is now.
phpisthebest 4y ago
I remember when jQuery was first released.... I wish things were that simple again
irrational 4y ago
> Some, probably a minority, of student web devs may get conditioned to reach for libraries for every problem they encounter I teach an online web development course for a university as a side gig. Our students are forbidden from using any third party code, libraries, frameworks, etc. They have to do everything with native html, css, and JS.

sarchertech 4y ago

At my current company we have a take home assignment for some roles. When I have to grade one the first thing I do is check to see whether you can submit the input by pressing enter. About half the time you can’t because it’s not actually a form, and they forgot to add handler for enter.

7speter 4y ago
As someone whose been learning the last few years, a lot of learning materials suggest you don’t make a proper form element and just make your own button instead of using using a form element and all the built in benefits it brings for reasons I don’t really know. I’ve probably wondered about this sort of thing for few good hours total, but I guess this comment steers me in the right direction.
- Falkon1313 4y ago
  Yeah, don't do that unless you have good reason to do so. Browsers have a standard, default, expected behavior. Sometimes, in rare cases, it makes sense to break that in order to do something else instead. But you shouldn't just silently break it for no reason other than to confuse the user.
- Mezzie 4y ago
  In addition to what others have mentioned, using elements for their stated/official purpose helps with accessibility. Yes, you can use the role attribute, but some accessibility technology works more completely if you use proper elements. (And just can be easier to use; I guess the best way to compare it is using VO on a site where everything is just divs is like the blind version of this[0] Or Comic Sans. Just visceral 'ugh'.). [0] https://www.theworldsworstwebsiteever.com/ https://www.theworldsworstwebsiteever.com/
wruza 4y ago
I always found this behavior strange. Tab often doesn’t work correctly in a browser, cycling through elements that shouldn’t be focused, sometimes in a strange order. Enter submits a form. How does one cycle through “fields” then? I have also seen premature form sends when you hit enter to autocomplete etc. It also creates multiline textarea vs input inconsistency. Desktop frameworks “committed” input on enter and most often focused the next field, so you could skip them by enter enter enter. This worked correctly since FoxPro/TurboVision/Norton times. Only Ctrl-Enter would press a “default” button out of order. But web has its own ways as usual.
swid 4y ago
At my current company, we changed enter to stop submitting because it’s not intuitive to users. I think there are exceptions for forms with only one field. So perhaps that isn’t the best litmus test? I wonder if it’s written down that should work as part of the assignment.
- sarchertech 4y ago
  It’s intuitive to any user who has used a web form anytime for the last 2 decades. Breaking default browser behavior because you find it unintuitive is generally a bad idea. Now if you’re dealing with something that isn’t really a web form—as in you’re overloading input fields for some interactive non form like behavior—then I can see it. In my case, if the person had some well thought out reason for doing it, I might let it slide. But the vast majority of times I’ve seen it, it’s because the person doesn’t even know how to use forms. Not understanding the underlying technology at at least a very basic level is a strike against you in my book.
  - swid 4y ago
    fwiw, in my industry, I should not assume anything about technical literacy. We’ve had honest debates over whether we can even rely on people to have an email address. Again, it’s not that I disagree with most of your premise, but in fact, as the comments (not just mine) show - people have issues with submitting too early, so it can be a good decision to break that depending on context. Fewer errors. Which is why I brought up how the problem is presented to the candidate. You might be filtering out people based on something less universally accepted and understood than you think.
    - sarchertech 4y ago
      Web forms have a default behavior. It doesn’t matter whether you accept it, you should understand it. If you accidentally break it because you don’t understand it, that’s a strike against you in my book. If you consciously break it for a good reason and can coherently defend that reason, that’s a different story.
    - 4y ago
kasey_junk 4y ago
I’d suggest adding instructions to handle enter if that is your criteria. When doing a take home exercise the candidate is desperate to figure out what you are judging on. The more you make that explicit the better your outcomes will be. Right now your process biases for enter handler adders. Is that your intent?
- klodolph 4y ago
  Part of the difference between a junior and a senior role is that people in a senior role are expected to fill in missing details independently, without detailed directions. If you only test people on their ability to follow detailed directions, then you will only be able to test for junior roles. When I give candidates prompts / questions / scenarios, I try to include some specific instructions, but also leave some details out. The idea is to come up with a prompt that junior developers can still work with by going head-on, but which has some open-ended nature to it, to see how people respond to things which are open-ended or even ambiguous. It's not a trick or trap; candidates are explicitly told what's up, and that I'm evaluating not only their ability to solve a problem, but to define the problem in the first place.
  - tptacek 4y ago
    This is kind of silly. Actual senior developers get near-real-time feedback from the rest of the organization, and if their interpretation of a request is off, they get multiple attempts to satisfy the request. None of this is true of a coding exercise. If you want to evaluate a candidate's ability to cut through ambiguity or manage sprawling scope, evaluate that and only that in a specific exercise. Don't just build a shoddy coding test and then rationalize it's weaknesses by saying that good candidates will succeed despite the flaws of the test. That's both disrespectful and un-rigorous.
    - klodolph 4y ago
      > Actual senior developers get near-real-time feedback from the rest of the organization, and if their interpretation of a request is off, they get multiple attempts to satisfy the request. Junior developers get near-real-time feedback from senior developers who are supervising them. Senior developers have to be able to give that feedback, have to be able to anticipate user needs, and have to be able to run long-term projects where you may have to work for days, weeks, or months before receiving critical pieces of feedback. > If you want to evaluate a candidate's ability to cut through ambiguity or manage sprawling scope, evaluate that and only that in a specific exercise. This is a common mistake that I see inexperienced interviewers make. Trying to throw more detailed and specific exercises at candidates is a fool's errand at best, and at worst it means that you're putting candidates through additional tests (and your acceptance rate will suffer). The main problem with ambiguity is that it appears unexpectedly. If you give someone an ambiguous problem and say, "Tell me what is ambiguous about this problem," then you're not testing what you want to know. What you actually want to know is whether candidates can recognize ambiguous problems without being prompted to recognize them--and the reason for this is that ambiguous are extremely common in real-world scenarios. An ambiguous problem is not a trick or a trap. It is explicitly part of the interview process, and interviewees are given guidance that the problems they are given may not be precisely defined. > Don't just build a shoddy coding test and then rationalize it's weaknesses by saying that good candidates will succeed despite the flaws of the test. Why do you say that the coding test is shoddy? My observation is that a large percentage of candidates will succeed at coding tests if you give them an ambiguous prompt. In practice, they will either ask questions to resolve the ambiguity, or just pick a way to resolve the ambiguity for the purposes of the test. This matches real-world scenarios--you are going to often encounter ambiguous or incomplete problems in the real world. If you want a precisely-specified coding problem, then go to Hacker Rank or Project Euler or something like that, or join a competitive programming team.

oldge 4y ago

Looking back over my relatively short 30 year career across an assortment of tech companies (hp, google, microsoft, apple, etc) I would add that this mostly changed due to what was rewarded. Around 15 years ago when the first vestiges of OKR review processes and the idea of "impact" started to form; We shifted our designs from things that made our long term outlook better (simple) to things that were easy to explain to management how they had HUGE impact (complex). Be right back, writing a new design doc for a messaging service and protocol spec to go with it that I can use to pad my next review cycle.

ozim 4y ago

This is a good explanation. Newbies drop directly to webpack/react and are overwhelmed or having a lot of trouble getting some details right. Unfortunately a lot of details that are lost in time are accessible if you go through "build stuff basically from ground" so understanding first "why" we needed these frameworks and what were problems to solve. There is also bunch of people who go to rediscover basic stuff and they claim "you don't need a framework - vanilla js is enough" - but they also miss context and did not run into problems that were pain points before we had frameworks.

Karrot_Kream 4y ago

This is true for other devs as well. I started playing around with networking code as a teenager (back when port 80 (before 443) was prominent but not the clear majority of traffic on the net.) Watching the evolution of TCP, HTTP, the C10K problem, retry storms, and event loops has made a lot of sense: clear responses to clear issues. But I've noticed a lot of junior devs grow up with the solutions (nginx, haproxy, exponential backoff, etc) but don't know the problems that necessitated the solutions. A lot of junior training is teaching juniors which solutions to apply to which problems, because unlike us they didn't watch the field evolve to where it is now.

phpisthebest 4y ago

I remember when jQuery was first released.... I wish things were that simple again

irrational 4y ago

> Some, probably a minority, of student web devs may get conditioned to reach for libraries for every problem they encounter I teach an online web development course for a university as a side gig. Our students are forbidden from using any third party code, libraries, frameworks, etc. They have to do everything with native html, css, and JS.