3 ms·

> - They think they know more than they really do. I have interviewed a lot of entry level especially bootcampers who can write a app.get('/', (req, res) but ha

> - They think they know more than they really do. I have interviewed a lot of entry level especially bootcampers who can write a app.get('/', (req, res) but have no idea how a GET request actually works. Most cannot tell me the difference between http header and body. But they surely know how to send an ajax request through code. Fundamentals people, fundamentals. I like your points, but want to dig a little deeper here. If someone is writing a new program, do they really need to know how the GET request works at the level you post, and the difference between header and body? You could write websites or applications, front and backend, let a framework like Django handle that, and this lack of knowledge wouldn't get in the way. My main point: How deep should the knowledge well stop? Does the interviewer who expects this deeper knowledge of how HTTP works also expect the candidate to know deeper network levels? How a TCP header is set up? An IP header? Ethernet? How to program the firmware/software that goes into an MCU or OS using a HAL or other abstraction? What about the volatile register reads and writes required? What if they have no idea, but can tell you if they wanted that info, they'd look it up on MDN, or pull up a browser's network tab or Wireshark? I would argue you could justify stopping before the fundamental level you exist, or not consider it enough, depending on job requirements.

livinglist 4y ago
understanding of protocols might be an overhaul for junior frontend engineers especially for those who come from bootcamps but I do think they should not be entield to think they deserve fang level salary… and stop thinking that being a software engineer is as easy as making and hosting a single web page with html and css… my wish is that bootcamps can start making students really interested in software engineering, and not constrained to web development.
tharkun__ 4y ago
Not the OP here. If someone is writing a new program, do they really need to know how the GET request works at the level you post, and the difference between header and body? I think this is actually quite important to know "enough" about. Should I expect you to know all the headers out there? No. I also don't know everything that's around nowadays. Should you I be able to expect that you know the basics of how a request works, the fact that there are headers and bodies and query params and what's different between get and post in those regards? Oh absolutely. Like the OP says, fundamentals. If you know the fundamentals of the split between headers and body you can dig into the specific ones when needed. Do I remember the exact way content transfer encoding stuff works w/ chunking in all details and edge cases? No. But I have enough fundamental understanding of how HTTP works that I can understand when I google it. also expect the candidate to know deeper network levels? How a TCP header is set up? An IP header? Ethernet? I think it's important to understand the basics of networking unless you're literally someone that just does CSS. You should have a basic understanding of a TCP connection. Do you need to be able to tell me anything about SYN/SYN-ACK/ACK? No. Should you know that DNS exists to turn the names we all use into IP addresses and that computers actually create connections between systems using those IP addresses and ports? Absolutely! Do I expect that someone from a bootcamp knows any of this? No, but that's also why I don't like even considering bootcamp people. Been there, burned by that. For a backend person, even if entry level? Oh yes you better know some TCP/IP. Do you need to be able to recite what a TCP or IP header look like from memory? Of course not, I couldn't tell you either any more. Should you be able to tell me that TCP is implemented on top of IP and you can use one without the other? Maybe not for an entry level person. What if they have no idea, but can tell you if they wanted that info, they'd look it up on MDN, or pull up a browser's network tab or Wireshark? If someone tells me they know what wireshark is, they're basically hired (yeah sure I'd also still make sure they didn't just pick up the word and know their TCP after that but I bet you the signal to noise ratio on that is pretty good.
duped 4y ago
I think it depends on the question and what you do with the response. If I were interviewing for an entry position and I asked "how is a GET request structured?" And they don't know, I'd like the answer to be "I don't know." Because then you can try and work through the problem space to go from "what trivia do they know" to "how accountable are they for what they know/don't know and how much do we need to devote in resources to get this person productive on our stack" All that said this stuff is just useful for a technical screen to filter into "entry level" to "junior" to "little experience but lots of knowledge junior" and can be gauged to estimate the success of the person in the business. Ultimately it's all about balancing risk. Some of the people coming out of boot camps are really risky hires because they don't have the tools to thrive in certain businesses, particularly smaller ones without much time to devote senior staff to mentorship. That doesn't mean they can't or won't, it's just about estimating if the risk outweighs the payoff once they're flying. I've been through this myself for even senior roles. I interviewed at a fintech where they asked me in the first call stuff like "how do you access a server from your dev machine" and "how do you edit a file from the command line on Linux" and "how do you kill a process on Linux." Very basic stuff, but it's not insulting. There are devs out there that can't answer those questions and they needed to be filtered out for that particular role. It happens.
codingdave 4y ago
> If someone is writing a new program, do they really need to know how the GET request works at the level you post, and the difference between header and body? I'd argue yes. If for no other reason than the number of times I've seen teams get roadblocked by CORS because they cannot figure out how to configure their servers to handle it. (And the number of interviews when people have dug into whether or not I knew how to resolve CORS errors.) The headers, body, response... all of these are core to what the app actually does as it glues the front-end and back-end together. A lack of understanding leads to teams who get it working once, and thenceforth treat that connection as a black box with a small number of wizards who need to be invoked to troubleshoot problems. You don't need to know everything in depth or spend a ton of time on it, but you need to know enough to debug problems at least well enough to identify the source of the problem so you can go do the research to find the answer.

livinglist 4y ago

understanding of protocols might be an overhaul for junior frontend engineers especially for those who come from bootcamps but I do think they should not be entield to think they deserve fang level salary… and stop thinking that being a software engineer is as easy as making and hosting a single web page with html and css… my wish is that bootcamps can start making students really interested in software engineering, and not constrained to web development.

tharkun__ 4y ago

Not the OP here. If someone is writing a new program, do they really need to know how the GET request works at the level you post, and the difference between header and body? I think this is actually quite important to know "enough" about. Should I expect you to know all the headers out there? No. I also don't know everything that's around nowadays. Should you I be able to expect that you know the basics of how a request works, the fact that there are headers and bodies and query params and what's different between get and post in those regards? Oh absolutely. Like the OP says, fundamentals. If you know the fundamentals of the split between headers and body you can dig into the specific ones when needed. Do I remember the exact way content transfer encoding stuff works w/ chunking in all details and edge cases? No. But I have enough fundamental understanding of how HTTP works that I can understand when I google it. also expect the candidate to know deeper network levels? How a TCP header is set up? An IP header? Ethernet? I think it's important to understand the basics of networking unless you're literally someone that just does CSS. You should have a basic understanding of a TCP connection. Do you need to be able to tell me anything about SYN/SYN-ACK/ACK? No. Should you know that DNS exists to turn the names we all use into IP addresses and that computers actually create connections between systems using those IP addresses and ports? Absolutely! Do I expect that someone from a bootcamp knows any of this? No, but that's also why I don't like even considering bootcamp people. Been there, burned by that. For a backend person, even if entry level? Oh yes you better know some TCP/IP. Do you need to be able to recite what a TCP or IP header look like from memory? Of course not, I couldn't tell you either any more. Should you be able to tell me that TCP is implemented on top of IP and you can use one without the other? Maybe not for an entry level person. What if they have no idea, but can tell you if they wanted that info, they'd look it up on MDN, or pull up a browser's network tab or Wireshark? If someone tells me they know what wireshark is, they're basically hired (yeah sure I'd also still make sure they didn't just pick up the word and know their TCP after that but I bet you the signal to noise ratio on that is pretty good.

duped 4y ago

I think it depends on the question and what you do with the response. If I were interviewing for an entry position and I asked "how is a GET request structured?" And they don't know, I'd like the answer to be "I don't know." Because then you can try and work through the problem space to go from "what trivia do they know" to "how accountable are they for what they know/don't know and how much do we need to devote in resources to get this person productive on our stack" All that said this stuff is just useful for a technical screen to filter into "entry level" to "junior" to "little experience but lots of knowledge junior" and can be gauged to estimate the success of the person in the business. Ultimately it's all about balancing risk. Some of the people coming out of boot camps are really risky hires because they don't have the tools to thrive in certain businesses, particularly smaller ones without much time to devote senior staff to mentorship. That doesn't mean they can't or won't, it's just about estimating if the risk outweighs the payoff once they're flying. I've been through this myself for even senior roles. I interviewed at a fintech where they asked me in the first call stuff like "how do you access a server from your dev machine" and "how do you edit a file from the command line on Linux" and "how do you kill a process on Linux." Very basic stuff, but it's not insulting. There are devs out there that can't answer those questions and they needed to be filtered out for that particular role. It happens.

codingdave 4y ago

> If someone is writing a new program, do they really need to know how the GET request works at the level you post, and the difference between header and body? I'd argue yes. If for no other reason than the number of times I've seen teams get roadblocked by CORS because they cannot figure out how to configure their servers to handle it. (And the number of interviews when people have dug into whether or not I knew how to resolve CORS errors.) The headers, body, response... all of these are core to what the app actually does as it glues the front-end and back-end together. A lack of understanding leads to teams who get it working once, and thenceforth treat that connection as a black box with a small number of wizards who need to be invoked to troubleshoot problems. You don't need to know everything in depth or spend a ton of time on it, but you need to know enough to debug problems at least well enough to identify the source of the problem so you can go do the research to find the answer.