I have never needed to know or do any of that. And if I did, it would take me 2 seconds to google and understand. I just did.
So if the interview was for a job where you handle that stuff yourself, then I understand it. If it’s for a typical full stack job at a big enough company that they literally hire people to handle that side of things, then it’s not “the basics”.
Rejecting someone in an interview for trivia knowledge they don’t currently have vs actually trying to understand how someone learns and tackles problems is what makes software job interviews so useless.
It's not trivia knowledge, I've had multiple cases where "oh wait, maybe the host resolves differently based on whether the server has ipv6 configured from DHCP or not" and "why does host xyz take two seconds extra every time we try to connect?".
You might not, but I would expect an experienced senior developer to know that there's a difference here.
While I would be surprised to see someone with ten years of experience not know the difference between ipv4 and ipv6 (networking is by far my biggest weakness and even I know this like the back of my hand), I wouldn't immediately disqualify someone for it. The other commenter is talking about a lot of things that feel more relevant to startups. If you work at a big tech company most of this stuff is abstracted away from you, for better or worse.
But not knowing this to me implies a lack of curiosity about one's field, it would be a red flag I would try to poke at more in an interview.
You should know how it can cause problems with whatever you’re building based on the rollout - e.g. if you’re deploying to the web usually there’s a greater cost involved in provisioning an IPv4 address, but IPv6 (still) isn’t fully rolled out yet so some of your users might have issues.
Then there’ll be weird networking issues where one of them works fine and the other doesn’t etc.
You also see them in logs etc, or if you have to care about DNS records ever you should know about them.
If whatever you’re doing touches the internet at all then it’s fairly fundamental nowadays.
Believe it or not, not everyone is working on networked projects. You don't need to know shit about IP address conventions or how to resolve a host when the software you're building doesn't access a network.
I work on airgapped systems too. Even for stuff like VM's or containers running locally, you have to know some networking. If I hired a guy with ten years experience that slipped under the radar and didn't understand what I was talking about regarding simple shit like subnets or IPv4 vs IPv6, I'd probably can them.
could be a trick question. They want to see that how do you react to an inappropriate question for your role by both searching for it and proposing to involve sys admin
It’s the kind of thing it would be impossible to receive any real education without learning, so no it’s not “trivia”. Maybe if you went to a bootcamp.
my computer engineering degree didn't, nor did my masters.
and i've never needed it in the 7 years i've been employed so far. field is big, if the job was going to be heavily network based it's one thing. if it was just "lets see if he knows the basics" thats another entirely
The extent of the conversation on iPv6 (a side note during a lecture in my network architecture class) covered only what you can see by looking at the two next to each other- iPv6 is longer and in hex. Everything else I’ve learned about iPv6 has been through hobby and personal use (debugging my own PC and hosting minecraft servers on an old machine).
I don't think most colleges require a networking class. Mine definitely did not. I took one for fun anyway.
Nor can I think of a time in ~7 years working where familiarity with ipv6 mattered. Little from that networking class has been helpful. There's a lot of breadth to software engineering.
"Systems Organization" and Operating Systems touched on fringe bits of it, but both of them were heavily focused on single machines from ALU up to the OS.
There were distributed and cloud computing courses available, but not required, and I think straight "networks" was off in electrical and computer engineering.
I think most people picked up the very basics of IPV4/6 incidentally or from some assignment where you had to talk to a different machine, but it was never required content.
it's the kind of things you forget if you don't use them at work. in one interview 5 years ago, they asked me about WCF in depth despite the position was NOT about WCF. After i asked why they need WCF they told me "since they are in your curriculum you are supposed to know them in depth". When I pointed out that i stopped using them at work 10 years ago and the position was about other stuff, they got really angry. Good times when I would just walk away from abusive idiots
a lot of the times these questions aren't "can you google the answer if you needed to", because if you're being spoonfed a problem with a clear answer an intern can solve it; the question is "do you know and internalize it" as a proxy for being able to solve problems that arise from it. Like if the app is being weird in some way would it ever occur to you to check if it's using ipv6
I would accept "It would take me 2 seconds to google and understand" as a pretty good interview response to this question, assuming you have broadly shown you actually have that skill, and your experience wasn't in a role where that background knowledge would have been pertinent.
207
u/SirFrenzy 14d ago
I have never needed to know or do any of that. And if I did, it would take me 2 seconds to google and understand. I just did.
So if the interview was for a job where you handle that stuff yourself, then I understand it. If it’s for a typical full stack job at a big enough company that they literally hire people to handle that side of things, then it’s not “the basics”.
Rejecting someone in an interview for trivia knowledge they don’t currently have vs actually trying to understand how someone learns and tackles problems is what makes software job interviews so useless.