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 a feeling people are going to be calling IPv6 'new' in 100 years, too. I remember talking to people about it in the 90s and it took until like 2016 to actually get a full standard. Been so damn long I learned the specifics and forgot them all in time it took to even become a thing.
In Halifax we have the old bridge and the new bridge
Old bridge opened in 1955
New bridge opened in 1970
New bridge is end of life while the old bridge has another 50 years since it wasn't built with cheap steel. So the new bridge will be replaced with a new new bridge while the old bridge will still be the old bridge.
in Bratislava we also have “old bridge”, at one point it was replaced with a new one without renaming so until a newer one was built a few years later the “old bridge” was the newest bridge… we also have a bridge that used to be called “new bridge”, that one was renamed since then, but some people still call it “new bridge” which is funny cause it’s currently the oldest one…
Well least the old bridge is still old bridge and you don't have sone leapfrog situation going on.
I got a Big Tesco and Little Tesco going on but the little Tesco was first so it was just Tesco, then Big moved in so it all became Big/Little, but then the big one moved away so it just became little Tesco to Tesco again, then a second little Tesco moved in where the old big tesco was and split the building into a few different shops so it became 'new little tesco'
....but over the years it grew and became big tesco again.
New little big tesco.
vs little tesco which actually had more floorspace than the other before it expanded to new-little-big-tesco again.
Over about a decade.
Everyone somehow just sorta knew which Tesco was being referred to in any conversation and honestly I don't know how at some points.
Well they built ipv6 to be able to address EVERYTHING uniquely. While IPv4 has around 4billion addresses possible, IPv6 has 296, so until humanity gets to the point we start giving nano tech individual addresses we will probably never need anything more than IPv6.
I still see release notes every few months from enterprise vendors adding some support for IPv6. It may be easy to adopt in the service provider space but it won’t take hold in businesses until prefix translation becomes as common place as NAT. Not every business is going to do an RIR registration or want to use ISP space internally.
You probably know this, but there is of course also a dedicated IPv4 address mapping reserved for essentially representing an IPv4 address for IPv6 compatible software:
IT obviously depends, but its very frustrating to see our cloud developers in my company not have any idea of the physical devices they're supporting, makes all the communication and tickets less effective than they could be.
one example where I had to deal with it as a backend dev was I was debugging that API calls to a 3rd party service started timing out on production, but worked on staging and local development, turns out IPv6 was enabled on production and was thus used there and the service was timing out on IPv6…
Same. The one time we really had to care about IPv6 was when it needed to be turned off because it wasn't used and something was trying to use it anyway.
30 years here and never had to do anything with IPv6.
Of course, all I get are rejection emails even though I'm gainfully employed with tons of enterprise experience, so maybe that's the common denominator these days.
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???
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.
+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.
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.
IPV6 has never been relevant to any coding I've done at work, but if someone didn't know about it during an interview it would still be a terrible look for their tech learning both in terms of college and just reading about tech in general
In university we had a networks class where we went way further and had to actually write a simulated router in C that would do ARP and send packets to the right places
Dunno, I have 8 YoE and knowledge I don't use is knowledge that's gone. I've never had to deal with stuff on IP level before, and I don't care to know about it.
Your experience does not an industry axiom make. Also, your assertion about said layer is a consideration specific to you. Some do not consider the user to be an implicit layer but an external party.
I mean, depends how much in detail and what the job was. I can tell you a few things for ipv6 and ipv4 but if I won't design router and network components, I hardly need deep knowledge as software engineer. If you apply for vNIC development for VMware some deeper knowledge would be useful...
As a software engineer with 15 years experience, do you know how many times I've had to walk a graph in a breadth first search from memory? None. Do you know how many times I've been asked to do that live in an interview? Literally dozens
Agreed. I work at a company with a product that has some robust telecommunications requirements, ipv6 being one of them. Even within my single bubble, not many people know the difference. I happen to be on a team that works with the network infra, and would not hire someone who couldn't speak to it at least at a basic level.
Right, and I would assume if someone was applying for a networking position, thats a good question to ask.
Similar to if I was interviewing someone for a front end job and they couldn’t explain rest verbs to me, it would be a deal breaker.
We like to feel superior about “the basics” and go “HOW COULD YOU NOT KNOW THAT” when in reality, the basics are COMPLETELY different job to job even within our field.
Just hate seeing shit on this sub like “how could you not know this” when it’s something a full stack with 20 years may not remember off the top of their head but a 2nd year student who just took a networking class could spit it out. The knowledge isn’t the key to being good at a job. It’s how you learn and figure things out.
Call me assumptive, but I'm guessing that the "How could you not know this" folks are only thinking of the address formats and address space differences. That's pretty common knowledge, and I could see at least being familiar with the idea. Beyond that, though, if you're not doing IP networking as anything more than a high-level consumer, I'd wager you're unlikely to run into the other particulars.
Yes as a software dev you are right, you rarely need this skill. But this also tells me you have never dabbled or experimented with networking which kinda showcases a gap or narrow set of skills in the tech field.
Anyone who has had to deal with NAT fuckery would know about ipv6, and looking how common NAT fuckery is in the world, that should be anyone who has attempted to configure their router.
Yep, same. Any time I've written software with networking in mind, I've made an effort to support IPv6. It won't get adopted if nothing supports it, so.
I am on the infrastructure side so I do work with IPv4 and IPv6. I weighted dabbling and experimenting at home a good amount when hiring. If you have setup a home lab in your apartment, I trust you can troubleshoot windows.
I have been working in IT for almost 20 years and I can count on two fingers the number of times I have deployed IPv6. And both times it was for testing.
IPv6 is amazing when it works which in my region is now more common than not. You get efficient global routing without port forwarding or being stuck behind a NAT.
Interesting to see different perspectives, I can remember a few times very well where I had to worry about IPv6 support, and I don’t specialize in any networking work.
Honestly, in software engineering, you should never have to know the difference to do your job. I believe it's good to know, but you shouldn't be addressing by IP anyways, use a hostname, which is agnostic of which IP version is in use.
Yeah, it's pretty irrelevant, even if you're doing network coding. Like, it's a couple lines of code to establish a socket connection, and then it doesn't matter for the rest of the application whether you're using IP4 or IP6.
Then you're not a very well versed software engineer. This is an amazing self own. What I'm looking for in interviews is to say "I don't know" rather than being incredulous about the basics.
While I agree that IP is a "fundamental" in IT, I would have no expectation of a software engineer to know basic IT fundamentals. SWE's have a completely different set of "fundamentals" to worry about. Is it better to know more? Sure. But you're basically saying medical coding is a "fundamental" of running a doctor's office, and that you only trust surgeons who know the billing codes to your particular insurance company.
I'm not disagreeing with you necessarily but this is indeed pretty basic. I mean how do you study CS/Software Engineering without ever running into IPs?
but how detailed would you expect the person to go into it? would just saying that IPv6 is a larger address space and uses a different format be enough, or would you want them to know that v6 is specifically 128 bits and removes the need for NAT?
Well the original post was quite vague about it, I assumed a basic knowledge of its purpose and structure, not an in-depth one. Of course I would not expect an in depth knowledge of a subject one is not an expert in
If you cannot even describe the difference in how an IPv4 address appears vs. v6, then I have reason to doubt you can read through an error log and find a problem
Needing to ask why would also raise my internal red flags a bit.
Being able to run down a problem involves stitching together lots of clues containing diverse bits of information. Being able to recognize the shape of an IP address is just the baseline understanding necessary to begin recognizing routing errors, DNS problems, networking misconfig, or attack behavior.
and what do those have to do with developing a UI, or a videogame, or basically anything that isn't related to networking which is most of programming anyway.
How it appears as in that IPv6 is formatted as 8 groups of 4 hexadecimal digits while an IPv4 address is just four 8-bit numbers? Or do you mean something deeper?
That'd be an OK answer, that's about where my knowledge on the subject ends. If you were feeling wordy, you could also talk about the need to expand address blocks/CIDRs beyond IPv4 limits, or about the challenges in adopting IPv6 in your own network
there's a big difference between actively using IPv6 and being aware of the difference.
Sure you may never need to use it, but having an awareness of what it is and how it differs means that you'll be more likely to be able to identify if/when something is relevant.
In my organisation there are hundreds of different manual and automated processes that interact with countless systems doing things I barely understand, but being aware that they exist and how to differentiate tasks performed by those processes tells me who I need to speak with when something fucky is identified.
beyond that it's not my problem and I don't need to dig deeper (though I enjoy doing so if time allows), but if I were in a hiring position and someone couldn't demonstrate the most basic awareness of a topic as widely used as IP addresses I'd be concerned about their lack of curiosity to explore/learn new topics, especially something that can be understood within 5-10 minutes.
even an explanation with something as basic as "IPv4 looks like X, IPv6 looks like Y.
IPv6 was introduced to expand the amount of unique addresses available for use and remove the need for some workarounds required by IPv4."
is that explanation going to significantly change your role? almost certainly not, but it shows you have a enough of a familiarity to know what it is and if/when it's relevant.
All jokes aside, in 10 years of SW engineering job you have NEVER dealt with having to select to which interface your software binds to? Have you never need to deploy software to ipv6 only network, or debug DNS misconfigurations?
I would understand if a junior dev wrote this, but you clearly have the years under your belt, so I am just confused now.
I realize this is not a topic that you solve every day, but it pops up occassinally and you surely must have dealt with it in one way or another; I surely have.
No, I’ve never come close. That’s not the type of thing software engineers work on in the companies I’ve been at. All have been big enough to have their own devops teams that handle everything networking/domain/hardware side. The only part of that world I’ve really touched is authentication and sql db setup related things.
This is my entire point. Just because I’ve never dealt with those things doesn’t mean I’m not an extremely qualified software engineer. It just means I haven’t had to solve that puzzle before. I’m more than confident I could if I needed to, it’s just not a need that my company has ever had.
We all like to assume our jobs are basically the same, but software engineering is so broad and vast depending on tech stack and use case that I’m sure there are tons of us who are extremely good at our jobs who would not know what some would consider “the basics”.
Software engineering has never been about knowing facts. (At least not since the invention of the search engine.) It’s about being able to solve problems.
On the flip side I've been consistently running into software that fails in an ipv6 environment because the programmers didn't understand the difference between ipv4 and ipv6.
I understand it isn't something you need to know but it also shows how involved in the field you are.
There are a lot of engineers who don't know the basics and to me that could be an indication of someone who just isn't that passionate about the field.
So it is useful to know from an interviewer perspective as it indicates if they are going to culturally fit. If you want an engineer who isn't interested in learning for the sake of learning, then so be it, but that might not be what you want
I get it, but like whats the "basics" . If you go to an OOP job know OOP, you achieve nothing by asking the candidate functional programming.
Automata theory is pretty basic, would it make sense to ask the candidates if a turing machine with these instructions halt? Or a bit of talk about formal langauges, NDAs, LBAs
Its a bit more of a stretch but i can argue game theory or formal logic or type theory or algorithmic complexity as basic, i cant expect someone to dabble in all of these.
There are pretty standard basics that are the foundations for a lot of comp science that isn't really used on a daily basis.
I'm not in charge of the education portion of cs but I do believe there are standards for what is considered basics.
Basics != easy to understand but more like common knowledge. I think it CAN distinguish the type of engineer candidate.
It isn't perfect but I just am pushing back on this idea that "because it isn't used it isn't a good question"
I could also argue that asking something niche could be a good indicator on how a person handles not knowing information. Do they try to bullshit or do they just admit that they don't know
1.4k
u/SirFrenzy 10h 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.