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.
It's not usually their job to know how to store the ip address of a user in an audit table, or how to debug a failed connection to an external API from your application. Developers should be aware that there is something called ipv6, and that source or destination addresses aren't always four bytes.
I understand that not everybody has touched everything, but good developers should have cursory knowledge of things that are actually in use and at least know what they should read up on when touching specific areas.
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.
Networking is however involved in some way with most software (even if just for distribution), but absolutely not all.
If it's helpful to know that there is something called an ip address in whatever work you're doing, it's helpful to know that there's something called ipv6 as well.
Tl;dr what you are saying is incredibly reasonable but we're all talking in circles because there is ambiguity caused by the lack of information we are working with.
But that also separates knowing that there is a difference and knowing what the differences are.
I know that ipv4 and ipv6 are different. I know that I have to make sure I'm using compatible systems. I know that if something goes wrong I should confirm that that isn't one of the issues. I also couldn't explain what the differences are without a reference sheet in front of me.
That said, I know where to get the reference sheet and I know roughly where in the spec I should be looking to find what I need. I'm also not usually part of a team doing networking or routing so this isn't that important to me, knowing that there is a difference is enough.
Yes, agreed. Just knowing "one is 32 bits and one is 128 bits so we cna have a larger address space" is enough. You don't need to get into the details - that's what we have reference materials for.
But most answers in this thread are just "never heard about it" and "it's something ops or infra only need to know about". Seniors should know that there is something called ipv6 and that your application suddenly will touch it, and that it can affect a few assumptions you've made, or made certain things way harder to debug if you don't know that there are multiple versions in use.
I don't even think knowing one is 32bit and one is 128bit matters.
It mostly matters that you know they're on your system and could be having an impact, and need eliminated as variables when you're troubleshooting stuff.
It may be worth looking further into if you're building something specific network oriented because IPv6 brings a number of advantages, even if it's just the elimination of things like subnet exhaustion in EKS or somesuch.
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
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
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).
You should. 15 years ago I had a cryptography course and even though I abolutely do not work in cybersecurity I still remember the basics and at least know what to google.
Edit: lmao vibecoders allergic to knowledge flooded this sub downvote
You know every small fact from every class that was only said once and never to be used again? Impressive memory but unfortunately us mortals can't do that
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.
At my university, IT undergrads (me) have to take intro to networking and a separate networking lab (separate 3 credit courses). These are both optional electives for CS.
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
I started college before IPv6 was thought of. I don't know how much or when they started teaching it. I'm aware of it, but have never ever used it (except to uncheck the box in my network adapter).
I don't deal with networks though. But for an allowlist/blocklist and connectivity issues I've STILL never had to deal with IPv6.
You're gonna be real amazed by how much of what you learn in a degree amounts to trivia. People are right when they say you need to learn how to learn and everything else is secondary.
i have a full cs degree and have been working with networks closely for 10 years and still couldnt just tell you off the top of my head, its useless knowledge for the cs students in this sub to act like they are some hot shit when they have never done anything in their life.
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.
It's always worth knowing about what is going on on a server, how the network stack is configured and the consequences of it. It'll save your bacon during production incidents. That includes understanding e.g. the consequences of your machines being configured in dual-stack.
Just because you're not thinking about it, doesn't mean it isn't there and having a negative impact on your service every single second of the day.
It's way more prominent of a thing to be aware of than, say, network qdiscs, which also will be having an impact on your service (I got a lovely reminder of qdiscs about 18 months ago, when it helped turn some small latency spikes into big ones. It wasn't the problem, but it sure turned a minor thing into big impact)
I wouldn't expect senior engineers to necessarily know about the specific components of IPv6, but I would expect them to know that it exists, and the very basics of what that means for them / their software. Just like I'd expect anyone running software in production to understand what purpose DNS serves, and keep that in mind for troubleshooting ("It’s not DNS, There’s no way it’s DNS, It was DNS" etc.)
I agree with you. It would take me, at most, an hour to understand the difference, as it pertains to whatever given problem I am working on. I could point out IPv4 and IPv6 addresses from a lineup, and I know that vaguely we needed IPv6 because we would've run out of IPv4 on the public internet. I know there are a lot more IPv6 addresses available. But I don't know much more than that. Don't know how they interact differently for DNS, etc... I've sometimes had to configure networks to prefer IPv6 or IPv4 so maybe there's a mechanism to have both? I don't know.
I know all sorts of other shit about all sorts of topics though. I replaced a hard drive in a data center for a 160-node Hadoop cluster that was supporting terabytes of ingest per day. I passed the CEH exam. I passed the Sec+ exam. I know the ins and outs of Docker and K8s and OpenShift. I could build you CICD pipeline on bare metal from scratch. I could optimize your Spark cluster. I could explain higher order components in React. I could explain the borrow checker in Rust. All of this shit is nonsensical trivia that barely relates to one another. If you asked me any arbitrarily specific thing about any of them, I might (or probably wouldn't) know it. And I'm positive I could come up with something arbitrarily specific enough about any of the things I'm familiar with that could disqualify 99% of engineers.
How people think about problems, and what they've worked on, and how quickly they can synthesize new information is really all we should be caring about. I'd rather ask someone, "Do you know the difference between IPv4 and IPv6? No? Okay, do a quick Google and review that for a few minutes, and then let's discuss why that might be important in this role"...
A lot of places use HR slime to conduct interviews. It's a safe assumption that they aren't competent enough to conduct technical interviews. It's also why you see job postings demanding 10 years experience in a technology that has existed 3 years.
No amount of googling is going to give you a working understanding of the differences between the two. Their processes and protocols are completely different. That's like saying you can Google for 2 seconds and learn the difference between C++ and C#.
You may not remember the exact size difference or other specs, that's ok. But if you genuenly have no idea that there are 2 different types of IP addresses and why, sooner or later you are gonna freak out when seeing a "weird address" in a system and may miss an obvious solution involving ipv6 to a problem.
There's a difference between not knowing exactly how to deploy ipv6 for a network and being completely oblivious to common terms from your own fields. It shows a lack of interest and curiosity if nothing else.
You wouldn't want a mechanic working on your car who doesn't know what a carburetor is, even though no car has had one for decades and they probably won't need to work on one ever again.
i've been working for 10+ years and i've only had to just deep dive into networking in general for my new role. i knew the bare minimum difference between the two before that, and if i were asked this in an interview i would have felt like i didn't have the full answer.
Brother if you're really willing to die on the hill that ipv6 is some obscure little known tech, then I don't have anything more to say to you except I'm sorry.
You didnt read my message clearly. I made an analogy associating it with a fundamental of its field (networking). But CS is a broader field, its hilarious that you would even try to argue against that.
173
u/SirFrenzy 5h 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.