5 ms·

It is not elitist to point out the flaws in modern web devs who don't know what an HTTP protocol is and the structure of an HTTP request (headers vs body etc).

It is not elitist to point out the flaws in modern web devs who don't know what an HTTP protocol is and the structure of an HTTP request (headers vs body etc). I interview a lot of them who cannot explain the difference between a form submitted directly vs through Ajax but they surely know how to send a POST request through node/express.

sillysaurusx 3y ago
I don’t even know the difference between a form submitted through JS vs a browser. Who cares? Unless there’s a problem, there’s no reason to know such things. And I’ve written http webservers by hand. People here have way too much confidence in their interview questions being a good signal for experience. It’s pretty wild.
- codegeek 3y ago
  "Who cares? " You are proving my point. You should care.
  - sillysaurusx 3y ago
    Why? I’d rather care about ML. My point is that your question is some esoteric gotcha party question that may as well be out of Trivial Pursuit. But you’re treating it like anyone who doesn’t care is just being a bad engineer. There are countless ways engineers spend their time, and choosing what to work on is the most important choice of their careers. It’s on you to justify the claim that knowing the difference between a JS form submit vs browser submit matters at all, let alone that it’s a distinction that comes up in day to day life.
    - nucleardog 3y ago
      The issue isn’t that every single person in the IT field needs to know HTTP in detail. The issue is that people who have invested in training for a role and are applying for a role do not understand fundamental technologies that are essential to that role. For you that would be trying to work in ML not understanding any of the theory or how it works, but having used OpenCV with some premade models a few times. For a frontend web developer who, as a large part of their role, will need to communicate with backend systems… that’s not understanding how their FE web application actually communicates with BE systems. And from experience… yes, this is very common. And it has a noticeable impact on their effectiveness. Trying to debug why some interaction between your application and the BE application isn’t working while thinking the dev tools network inspector is just black magic and nonsense makes your job substantially more difficult. This does make these people bad engineers. They are not able to understand and solve a huge class of the problems that they face day-to-day and instead (in my experience) often fall back on “just try a bunch of different things until something works for reasons I don’t understand” which is a poor way to approach work and leads to overly complex, buggy, brittle systems.
    - recursive 3y ago
      If you're a web developer, form submission is not esoteric trivia, although ML may be.
- quesera 3y ago
  > I don’t even know the difference between a form submitted through JS vs a browser. I think you do. GP just phrased it oddly. The distinction is between a traditional HTML form and browser page load, vs XMLHttpRequest. Ultimately it's all HTTP though and on that level, there is no difference whatsoever.
drzaiusx11 3y ago
I strongly believe tech interviews should be about seeing _how_ a candidate works and less about _what they know_. Everyone has holes in their knowledge, but can easily be filled by training or on the job experience if they have excellent problem solving skills. Maybe they never needed to know the protocol level but can deliver excellent ux results regardless. I've started nearly every position in my career in a different domain without prior knowledge, including workflows, protocols and the languages that implement them. I may be an extreme case, but we exist and your process inherently excludes us. I've worked in robotics, consumer electronics, healthcare, fintech (not even in that order, although that probably would have made more sense.) I've delivered in each domain as well as my expert colleagues. But if you asked me to implement a LLM, I'd shug and tell you I don't know how, but I _would_ explain my process for HOW I would learn to. (Edit: typo)
- codegeek 3y ago
  "how_ a candidate works and less about what they know" I do get your point but depends on the role you are hiring for. I have had candidates get upset at me (for example: bootcampers) because they couldn't explain how to submit a basic HTML form but wanted me to look at their github "portfolio" that was done during the bootcamp with React/Express Code and what not. Their title was "Front end React Developer". That is a problem and I usually wouldn't hire those people.
  - drzaiusx11 3y ago
    If you're specifically _not_ looking for react front-end developers, then the on-the-job training for those candidates on the position you're filling _can_ be cost (time) prohibitive in certain orgs to "get up to speed." Likely you should filter those candidates out earlier if that's your case. Sounds like you are, but I'd like to also point out that this strategy has it's own costs. For example, I would take a react developer with obvious gaps and a strong willingness to learn on my back-end services team over a passable back-end dev who was set in their ways (unwilling/uneager to learn new tech, entrenched opinions stated as fact, etc.) Naturally, my approach is not a one size fits all situation and a great deal depends on org structure and mentorship opportunities being in place for it to work. The benefit being you avoid monoculture "silos", and have more cross collaboration and transfer opportunities between teams (some may call this "full stack", I wouldn't) Several high performers on my team are "self-taught", work comfortably across several languages today and can pickup new tech easily. They came in knowing their "one stack" at the time. If they were "bootcampers" or not seems irrelevant and somewhat reductive/offensive. That said, if the candidate in question shows _no_ understanding of their problem domain, can't reason their way out of a paper bag, and get visibility upset from questions when you try and tease that out, that is a certainly a red flag in my book. With respect to your example given, however, it could be argued that http details because of the abstractions in place inherent in react, aren't critical domain knowledge for what is essentially a UX dev. If they can ship an experience your users enjoy more than the candidate that can recite the HTTP 1.1 RFC and cannot, then what have you gained in hiring the latter other than maintaining a culture of pedantry? TL;DR it comes down to how much risk your team is willing to take on, as there's always risk inherent in hiring ANY candidate, including those that don't already check all your boxes in regards to tech know-how. I'm merely stating that by overlooking candidates that don't fit your self-imposed mold, you're likely missing opportunities for rewards that can pay dividends when it does work.

sillysaurusx 3y ago

I don’t even know the difference between a form submitted through JS vs a browser. Who cares? Unless there’s a problem, there’s no reason to know such things. And I’ve written http webservers by hand. People here have way too much confidence in their interview questions being a good signal for experience. It’s pretty wild.

codegeek 3y ago
"Who cares? " You are proving my point. You should care.
- sillysaurusx 3y ago
  Why? I’d rather care about ML. My point is that your question is some esoteric gotcha party question that may as well be out of Trivial Pursuit. But you’re treating it like anyone who doesn’t care is just being a bad engineer. There are countless ways engineers spend their time, and choosing what to work on is the most important choice of their careers. It’s on you to justify the claim that knowing the difference between a JS form submit vs browser submit matters at all, let alone that it’s a distinction that comes up in day to day life.
  - nucleardog 3y ago
    The issue isn’t that every single person in the IT field needs to know HTTP in detail. The issue is that people who have invested in training for a role and are applying for a role do not understand fundamental technologies that are essential to that role. For you that would be trying to work in ML not understanding any of the theory or how it works, but having used OpenCV with some premade models a few times. For a frontend web developer who, as a large part of their role, will need to communicate with backend systems… that’s not understanding how their FE web application actually communicates with BE systems. And from experience… yes, this is very common. And it has a noticeable impact on their effectiveness. Trying to debug why some interaction between your application and the BE application isn’t working while thinking the dev tools network inspector is just black magic and nonsense makes your job substantially more difficult. This does make these people bad engineers. They are not able to understand and solve a huge class of the problems that they face day-to-day and instead (in my experience) often fall back on “just try a bunch of different things until something works for reasons I don’t understand” which is a poor way to approach work and leads to overly complex, buggy, brittle systems.
  - recursive 3y ago
    If you're a web developer, form submission is not esoteric trivia, although ML may be.
quesera 3y ago
> I don’t even know the difference between a form submitted through JS vs a browser. I think you do. GP just phrased it oddly. The distinction is between a traditional HTML form and browser page load, vs XMLHttpRequest. Ultimately it's all HTTP though and on that level, there is no difference whatsoever.

drzaiusx11 3y ago

I strongly believe tech interviews should be about seeing _how_ a candidate works and less about _what they know_. Everyone has holes in their knowledge, but can easily be filled by training or on the job experience if they have excellent problem solving skills. Maybe they never needed to know the protocol level but can deliver excellent ux results regardless. I've started nearly every position in my career in a different domain without prior knowledge, including workflows, protocols and the languages that implement them. I may be an extreme case, but we exist and your process inherently excludes us. I've worked in robotics, consumer electronics, healthcare, fintech (not even in that order, although that probably would have made more sense.) I've delivered in each domain as well as my expert colleagues. But if you asked me to implement a LLM, I'd shug and tell you I don't know how, but I _would_ explain my process for HOW I would learn to. (Edit: typo)

codegeek 3y ago
"how_ a candidate works and less about what they know" I do get your point but depends on the role you are hiring for. I have had candidates get upset at me (for example: bootcampers) because they couldn't explain how to submit a basic HTML form but wanted me to look at their github "portfolio" that was done during the bootcamp with React/Express Code and what not. Their title was "Front end React Developer". That is a problem and I usually wouldn't hire those people.
- drzaiusx11 3y ago
  If you're specifically _not_ looking for react front-end developers, then the on-the-job training for those candidates on the position you're filling _can_ be cost (time) prohibitive in certain orgs to "get up to speed." Likely you should filter those candidates out earlier if that's your case. Sounds like you are, but I'd like to also point out that this strategy has it's own costs. For example, I would take a react developer with obvious gaps and a strong willingness to learn on my back-end services team over a passable back-end dev who was set in their ways (unwilling/uneager to learn new tech, entrenched opinions stated as fact, etc.) Naturally, my approach is not a one size fits all situation and a great deal depends on org structure and mentorship opportunities being in place for it to work. The benefit being you avoid monoculture "silos", and have more cross collaboration and transfer opportunities between teams (some may call this "full stack", I wouldn't) Several high performers on my team are "self-taught", work comfortably across several languages today and can pickup new tech easily. They came in knowing their "one stack" at the time. If they were "bootcampers" or not seems irrelevant and somewhat reductive/offensive. That said, if the candidate in question shows _no_ understanding of their problem domain, can't reason their way out of a paper bag, and get visibility upset from questions when you try and tease that out, that is a certainly a red flag in my book. With respect to your example given, however, it could be argued that http details because of the abstractions in place inherent in react, aren't critical domain knowledge for what is essentially a UX dev. If they can ship an experience your users enjoy more than the candidate that can recite the HTTP 1.1 RFC and cannot, then what have you gained in hiring the latter other than maintaining a culture of pedantry? TL;DR it comes down to how much risk your team is willing to take on, as there's always risk inherent in hiring ANY candidate, including those that don't already check all your boxes in regards to tech know-how. I'm merely stating that by overlooking candidates that don't fit your self-imposed mold, you're likely missing opportunities for rewards that can pay dividends when it does work.