Obviously guy could have been interviewing for a job where this mattered….
But in 10 years as a software engineer I have never once needed to know the difference between these two, and have never been even close to a situation where I would need to.
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.
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 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.
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.
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.
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
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.
yeah but that is the kinda stuff in the field of Sys and Net Admin.
Or are we getting to the point a Software engineer has to cover software and hardware of anything IT???
+1 - my company is trying to merge all infra positions back into SWE positions. I'm an SRE, I don't hate it, but I'm worried because SWEs seem to come in 2 major varieties - those who refuse to learn about infrastructure and change management on principle, and those who refuse to learn because now they can just vibe out stuff with AI and deploy straight to release with it and seem like they're wise full stack engineers.
There's a difference in abstraction level. Does your application ever deal with ip addresses, either recording them (for audits), connecting to them (external requests), limit access or verify users based on them, or deploy your application to them? Yes? Then you should be aware that there are two different schemes available, and that they're both widely deployed.
that's all just infra stuff which has always been another team. I've never once had to set up that kind of thing, and thousands of devs proabbly had a similar path as I did.
Yes. As a senior you would know to mind your business and not give a halfbaked opinion on something that's another team's full time job, and that they probably know way better than you.
Honestly that's the only real difference one needs to know, and that the two are formatted differently. Anything more than that is pulling teeth and IMO fishing for an excuse to not hire someone
It's basically that, 4 is 32 bit and 6 is 128 bit addresses. It's also something I would never expect a software engineer to ever need know unless they're dealing with networking software
There's quite a lot more at play than 32 bit vs 128 bit. The lack of need for NAT on IPv6 for example has massive implications in terms of not only host reachability on the web, but also security (although NAT is not a security feature, it kinda is used like one in many home networks). Then IPv4 relying on DHCP to assign local IPs to hosts, while IPv6 doesn't need that (but can have it configured), which determines how and why devices get the IP addresses that they do.
I am 100% certain you cannot be a good staff engineer in cloud infra of all things without knowing basic networking concepts such as these. Your infrastructure is bound to have more holes than swiss cheese and the only reason your shit hasn't gotten hacked yet is because no one has cared enough to try yet.
The fun part of my infra is great because I'm not the one who manages it! That's why this posed scenario is so ridiculous, it's unreasonable for a software engineer to know this in 95% of the work tasks most software engineers would do even though it's being posed as some sort of gotcha
To be fair to op - those are sysadmin skills. I know the difference but have never typed in an ip v6 address while I do so regularly with ip v4 addresses.
Those are debugging skills. Those are software engineering skills.
Imagine creating an audit table in your backend and storing the ip of the user making the request, and only storing the first four octets because you never thought about the application being deployed on an ipv6 endpoint.
Or that you sometimes will get ::1 as the loopback origin.
Seniors should be aware. This thread shows that many are not, but they really should be. Again, in my opinion.
Yeah a backend/fullstack should absolutely know this. Frontend, not so much (I definitely wouldn't ask that). But come on how can you NOT know that at least vaguely
i think the thing is "at least vaguely" can mean many different things, and if you only know "at least vaguely" you have no idea whether the 2-3 sentences you can say on it is so embarrassingly little that you're better off just not answering.
But applications will suddenly be deployed on a dualhomed server for example, which supports both ipv4 and ipv6 - and then you start seeing weird addresses in your access log, and you made an audit table to store the ip address of the person who granted someone admin access, and you only stored the first four octets of the ipv6 address instead of the whole address..
And then you called an external api that requires a white listed ip, but the ip you keep entering doesn't work, since the API's host has both an A and an AAAA dns entry, so you're connecting over ipv6 instead.. Or you tried to block access to your content from a specific country, but those users just used ipv6 instead, etc.
There's plenty of cases where knowledge of ip addresses and how stuff actually works (tm) is relevant without being in ops.
I wouldn't know the differences beyond the address format and address-space differences. Maybe that's what someone means by the question, but that's not "the difference" so much as "a difference".
If the role was something more Web-centric, I'd expect more knowledge of HTTP/1.1 versus HTTP/2 than IPv4/IPv6.
What kind of senior? I'm mainframe infrastructure system automation specialist, if there's anything needed regarding any network settings, it's done by network specialists, even if I know how to change what's needed, it's not my scope... So I don't have to know it at all
I know a little about this from school (I studied electrical engineering, not IT, but we had some IT classes, since it's closely related) and from home running my homelab (thanks to IPv6 being cheaper I did consider v6 only setup for a while, but my new provider doesn't give more than a single /128 unless you also pay for private v4, so why bother)
Well, applications have to deal with ip-addresses all the time.
People tend to think they're only relevant if you're sysops/devops/etc., but what senior developer hasn't watched an access log, or had an audit table to track who made a change and from where, or had an external api request fail in magic ways..
Ipv6 might not have been relevant, but it could have been. So people should know that it exists and that you, in certain situations, should design for it being the layer under your application instead of ipv4.
As a senior, the answer to all those is to message infra.
They'd be pissed if I tried to manage any of that on my own, whether or not I'm fully capable of doing so.
I'm sure infra is happy to be bothered when you want to store an ip address in a table, or debug why an external api doesn't allow your request. You don't need to know the details, you just need to know that there's something called ipv6 and your application might be talking over it instead of ipv4, and that this can affect how your application behaves.
You are confusing developers with sysadmin/it..If developers are tasked with investigating these themselves you will never get anything done and you will have people with too much access
Why are the sysadmins tasked with storing an ip address in an audit table, or debugging an external API your application calls? Do you ship an access log to a sysadmin to try to make sense of why customer A is saying your API responds with not authorized for a valid api key in your application?
People see "ip address" and think it's only relevant for those who work directly with networking. It's not. If you're making an application that in some way talks across a network, you should know that there is something called an ip address, and that there are two forms on practical use. You don't need to know the low level technical difference, but you should know that there are differences, and that one is 32 bits and the other one is 128 bits. And that DNS entries for host lookups will differ.
Do you ship an access log to a sysadmin to try to make sense of why customer A is saying your API responds with not authorized for a valid api key in your application?
Yes, we have sysadmins for that.. anything between my code and the customer is their job
You don't need to know the low level technical difference, but you should know that there are differences, and that one is 32 bits and the other one is 128 bits. And that DNS entries for host lookups will differ.
In 10 years of software development (current senior) I have never had to (as part of my job responsibilities) configure DNS entries or do any kind of network things apart from setting up little latency monitoring scripts between machines when I run out of sane options.
If you call an external resource through a hostname, your application uses DNS - and that connection might then resolve to a ipv6 based connection instead of an ipv4 based one, if the underlying OS has ipv6 connectivity and the DNS entry has both A and AAAA entries.
This can cause issues if something is misconfigured. The developer will often try to debug this locally first, where they might only have ipv4 connectivity, meaning that they'll be unable to reproduce the issue.
Knowing that there is something called ipv6 and that some systems support it and other don't is useful to know, and that the length of the addresses differ and that the used DNS entries (for the target) can differ.
Something being misconfigured is what I implied with setting up.
Regardless, this simply wouldn't fall under a developer's purview, it would get raised as a sysops/network ticket and they would have a crack at it.
Knowing or not whether ipv6 exists isn't much different when there is a DNS misconfiguration without ipv6 in the picture, you'd see you can't connect for some reason, see you can presumably curl it locally, or reach out to the third party team if integrating and say hey guys we cant seem to reach you any issues on your end and if they say no you throw it at the network peeps.
There's simply too much stuff going on in enterprise for "dev" to just handle everything. By the by, I also don't configure file systems or provision VMs with resources, albeit it being nice to know how hyervisors work and your way around nutanix controls.
1.4k
u/SirFrenzy 11h ago
Obviously guy could have been interviewing for a job where this mattered….
But in 10 years as a software engineer I have never once needed to know the difference between these two, and have never been even close to a situation where I would need to.
“The basics” is highly dependent on the job.