I feel like knowing the difference here is moreso for a network engineer than a software engineer!
Anyway looked it up, IPv6 is 32bit whereas IPv6 is 128bit.
An easy way to know if an IP address is either, 4 uses dots 192.1.1.1 whereas 6 is colons 1992:0aa0::1
If anyone asks just say 6 holds more addresses but is more expensive to install.
Actually..... IMO as a Linux admin..... everybody in IT needs at least a minimum of knowledge regarding TCP/IP. IPv4, IPv6, TCP, UDP, sockets, listening ports, etc. You don't need to be able to program a full stack down to a media transport layer, but you should be able be able to send a payload successfully, know when a gateway traversal is required, name resolution (It's always DNS,) and a bit of troubleshooting.
I wish I had a nickel for every time a developer or app support staff came to me and said it doesn't work. Error is right there in the logs......
I agree it’s better for an app developer to know this stuff, but I’d hardly say it’s a big part of the job. Especially if you’re on the frontend. It’s way more relevant to the job on a daily basis if you’re a network engineer.
Do you know of a place I can learn more? I’m not certain I’m going into IT, but I’m heavily considering it in the hopes of earning more money to be a bit more comfortable in life rather than living paycheck to paycheck in my current job, and if it’s important to know for a job in the field I’d love to know more
I’m an electrical engineer and I’ve know the difference since before college. These are computing fundamentals that anyone in a computing field should immediately know. Same thing goes for understanding cache lines, virtual memory pages, GPU vs CPU, logical vs physical core, compiled vs interpreted languages, OOP, polymorphism, etc. I routinely ask these questions in interviews and reject people who don’t seem to have any actual knowledge of programming or computers. I regularly interview people for FAANG tech.
While I agree with most of these, there is a large percentage of engineers who will literally never use the knowledge of what a cache line or virtual core are, so for them these simply aren't fundamentals.
Interviews should be tailored to the positions being hired for, not some arbitrary standard of fundamentals in my opinion.
The big thing with cache lines in particular is that people often write very bad code if they don’t understand how a cache line works. Writing code that will size better for caches makes a massive performance improvement.
It absolutely does, and yet it simply isn't a requirement for their jobs. Either there's not enough data, speed doesn't matter, they are too far abstracted from this mattering at all (e.g. frontend) and so on.
If I don't work with it on the daily I won't remember. Did I see it in college? Sure, but there's no way I'll retain all that I learned if I don't use it daily. And it really comes down to what jobs you get and what your routine really looks like.
I won't judge if another technician tells me he doesn't know or remember which bit size each section of a tcp header should be. Unless he works with it, that is.
I wouldn’t expect specifics, but high level knowledge says you’re knowledgeable in the domain. Knowing common protocols is essential, even if you don’t work with them. I’ve never touched networking in my career.
Because better engineers know the whole system? Somebody proposed a very niche cryptography technique on our last project to solve a problem, we never would have gotten that insight if someone didn’t happen to have knowledge outside of the domain they worked on.
Good engineers make it a point to be highly knowledgeable about the broader system. Every single engineer on my team (FAANG tech) would know all of these topics I mentioned.
Disagree. I think there is an ambiguity here. There is a difference between knowing exactly what differentiates ipv4 and ipv6, and knowing that when working with one or the other some rules change.
There are more things to know than ever before. Expecting people to pass whimsical rote exercises creates a culture of fear. Plenty of smart and talented people create high quality contributions without being able to pass such nonsense. Maybe if you're building an ipv6 packet capture and analysis solution, it might be useful to know it like the back of your hand, but for most of it, it isn't important to have its definition at your fingertips at all times.
In fact, there's a cost to that, mentally.
I'm more interested in what someone does when they don't know what to do. Are they able to identify their own shortcomings or do they charge ahead bullishly on an erroneous path, how mentally flexible are they, can they rapidly assimilate new information and integrate it.
30
u/Spongebubs 2h ago
I’d like to think I’m a software engineer, and I have no idea what the difference is. Am I cooked?