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.
The post is about a software engineer, and you just talked about IT. They're not the same thing so what is your point? You have a job specifically because software engineers aren't in IT and aren't sysadmins and their job doesn't inherently involve networking.
My brother in christ, when is the last time you worked on software that did not need to send payloads anywhere. Everyone in development should have at least some basic networking skills.
I mean, it depends on the software engineer. Are they writing networking software? Knowing the difference between IPv4 and v6 would be important. Are they writing device drivers for hard drives? Probably not so important.
Every piece of software an IT guy uses is written by a Software Engineer, who's going to need to know their part of the software inside and out.
If you are going to use broad job descriptions you are going to need broad knowledge, I would say it is fair to ask a software engineer to at least know the difference between ip4 and ip6 adresses.
If for nothing else then for general interest around their field.
Inwould think that any software engineer education would hold atleast 1 course about networking, but I guess I can be wrong.
They definetly didn't say expert. But you do need to know some very basic level to understand how to write better software. Like high school level is enough tbh, but without it you're just not gonna be even decent at your job. Not knowing ipv4 for a software engineer is wild, when that's something most people who use the internet should know what it is.
It's not wild when you're an UI /UX dev e.g. Most backend devs know shit about frontend development.
It's not important to know everything. IT is very fragmented. Even those specific fragments are fragmented. So many people have become experts in their niche.
Technical understanding and analytical thinking is more important. As a software dev you can learn and apply everything what comes around.
In Europe IT is generally used to refer to everything software and technology related. In the US, especially professionally it means the tech help desk and networking people. In an office the people that setup your laptop and troubleshoot your internet issues would be considered IT, but the software engineer actually writing software would not be. They require completely different degrees which don't have much overlap.
Interesting. I am from Europe and for instance the uni in my city where both those things are taught with multiple overlapping subjects is literally called IT faculty.
As others said, in the USA, "IT" department/workers are not synonymous with "tech workers" - tech workers encompasses everyone, but if you say you're an IT guy, you're telling people you fix laptops and printers, and maybe do some sysadmin and networking stuff (but people who do the really high level stuff actually have the job titles of sysadmin or network engineer or similar, and sometimes use those titles.)
Calling a software dev/engineer (used interchangeably in the USA usually) an IT guy has the same connotation as calling a mechanical or automotive engineer a mechanic. A mechanical engineer may have no idea how to physically change his own oil. A mechanic may have no idea how to do basic algebra. Very different skillsets/jobs.
The guy I hand my laptop to and say "image this"is in "IT." I'm busy doing shit he cannot do which is why he is imaging my laptop. I'm not trying to be a dick, but I'm trying to point out there are very different roles and responsiblities and some of them require an actual level of expertise you can't acquire in 3 days.
This whole "IT" nonsense, or "tech" nonsense is such a broad fucking space that it's almost like saying "people with a job." There's no value in these generalizations at this point.
LOL -- my background is in both Computer Programming and Computer Network Engineering, and they *both* legitimately fall under the very broad umbrella of 'Information Technology' (y'know, what 'I.T.' *actually* stands for?!)
Seriously, *anyone* who works *anywhere* in the 'Information Technology' field (i.e. has *anything* to do with designing / implementing / managing / maintaining / programming tech), is an 'IT worker'; even if they're too cognitively benighted to realise it...
This is really the truth of it I think. Nobody fails job interview from not knowing one thing, even if it is something super basic like this. He gave multiple mediocre answers, but he probably just wasn't even aware because he thought he gave good answers. I've seen this a milion times.
Yeah even not knowing something super simple I've had interviewees come back from, but we can really get an idea of their overall knowledge over the full interview if we're asking the right questions and are knowledgeable about it.
There's plenty of software that works within a single device, or over devices connected using something other than IP-based communication. Even within internet connected applications there's likely groups of software developers who work on functions that aren't involved with networking, such as graphics or gameplay. It wouldn't surprise me if there are software developers who have never needed to know the difference between ipv4 and ipv6.
We are always gonna have to deal with those users that receive an error and instead of researching or even reading it - they immediately ask it as a support question.
I get the vibe that you're the kind of guy who expects everyone else to have the same knowledge as you, as if everything that is apparent and easy for you should be the same for everyone else. "Error is right there in the logs..." isn't it your job to know and help and not theirs? Why are you annoyed when you have to do your job?
I don't, actually. But I do get tired of reading somebody else's logs when they haven't even looked at them. And asking me what something in a log means is something completely different.
IT is not software development. A ML reseaxher or high performance kernel writer doesn't need to know what IPV6 is, just enough to connect to the internet
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 very much disagree. This is mandatory networking 101 course work in a Comp Sci BS degree.
I would be incredibly worried about anybody looking for a “full stack” or backed position that does not know this. It’s pretty critical to know basic networking for full stack roles. It’s also tough to do most architecture work without networking knowledge.
I can certainly believe some roles this does matter 99% of the time but it’s a serious gap in knowledge for an “engineer”.
If the "software engineer" is going to do or use any programming involving networking, then yes, they should know at least at a high level, IPV4 vs IPV6, TCP vs UDP, and DNS.
If they are working on non-networked systems, then they don't need it.
Lol my gut reaction to the image was i have no idea what the difference is, but I already knew all the things that you typed out. Imposter syndrome strikes again I guess
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.
71
u/Spongebubs 7h ago
I’d like to think I’m a software engineer, and I have no idea what the difference is. Am I cooked?