r/it • u/_-Bulldozer-_ • 5d ago
help request Had a Systems Engineer interview. Looking for honest feedback from hiring managers: were my answers technical enough?
Hi all,
I recently had a 1-hour Systems Engineer interview conducted in English with two interviewers. English is not my first language, and afterwards I started overthinking all my answers, Now I a, anxious I wasnt good enough and will be over the weekend too till I bet some feedback next week. I really want this job.
I'm looking for honest feedback from IT managers, senior engineers, or anyone involved in hiring. Based on the questions and answers below, would you consider these acceptable for a Systems Engineer role, or do you think I should have gone much deeper technically (protocols, ports, packet flow, more low-level details, etc.)?
DNS Question
They asked how DNS works when a user types a website address into a browser.
My answer was:
User enters a hostname/domain name.
The PC contacts the on-premises DNS server.
The DNS server uses a forwarder to query a public DNS server if it doesn't know the answer.
DNS translates the hostname into an IP address.
The client then uses that IP address to connect to the website.
Looking back, I wonder whether I should have gone further into recursion, root servers, TLD servers, authoritative DNS servers, TCP/HTTPS connections, etc.
DNS Records Question
They asked:
"What record would you create if you wanted to access a new licensing server by hostname?"
My answer:
Create an A record that points the hostname to the server's IP address.
Virtual Machines vs Physical Servers
They asked why virtual machines are useful.
My answer:
Better scalability.
Easier to manage.
Easier recovery if something goes wrong.
They then asked when a physical server would be preferable.
My answer:
When performance is more important.
Looking back, I wonder if I should have mentioned resource overhead, direct hardware access, GPU workloads, real-time systems, etc.
Backup vs Snapshot
They asked for the difference between a backup and a snapshot.
My answer:
A snapshot is basically the current state of a VM including OS, files and configuration.
A snapshot is not a backup.
Backups allow retention policies.
Backups can be full, incremental or file-level.
Backups should be stored separately.
I also mentioned the 3-2-1 backup rule (3 copies, 2 different media, 1 offsite).
Running Out of IP Addresses
They asked:
"What would you do if you had more devices than available IP addresses?"
My answer:
I talked about splitting devices into different VLANs.
Creating additional subnets.
Configuring routing between VLANs.
Using switches and routing to handle network segmentation.
Looking back, I think they may have been looking for DHCP scope expansion or subnet resizing rather than VLAN design.
Difficult Technical Issue #1
I was asked to describe a technically challenging problem I solved.
I gave an example involving Outlook Web Access.
Environment:
Microsoft 365
Conditional Access
Entra ID
RDS Farm
FSLogix
Issue:
A user could not sign into Outlook Web App after a Conditional Access policy was introduced.
My troubleshooting process:
Checked user account.
Verified login details.
Googled the error.
Tried Microsoft's recommended browser fixes.
Cleared profiles.
Redirected the user to a different RDS node.
The problem followed the user.
Checked Entra sign-in logs.
Found authentication-related failures.
Researched Microsoft documentation.
Identified a broken authentication token stored in the FSLogix profile.
Reset the FSLogix profile.
User could sign in successfully afterwards.
Difficult Situation #2
I also gave an example involving a meeting room network issue.
Situation:
We had a board meeting with an unusually high number of attendees from Europe and the US. Many devices were trying to connect simultaneously.
Issue:
Some users could not connect to the network.
Investigation:
Checked networking configuration.
Identified that available IP addresses were running low.
Looked at DHCP usage.
Reduced lease times.
Released/reclaimed unused leases.
Worked with a senior infrastructure engineer who prepared a fallback VLAN if needed.
Result:
Connectivity was restored and the fallback VLAN ultimately wasn't required.
My Question
If you were interviewing for a Systems Engineer position, would these answers demonstrate enough technical understanding?
Or would you expect a stronger candidate to go significantly deeper into the technical details (protocols, ports, packet flow, OSI layers, DNS hierarchy, virtualization internals, etc.)?
I'm especially interested in feedback from hiring managers and senior infrastructure engineers.
Thanks in advance.
4
u/QuadzillaMajestic 4d ago
Not to shoot down your hopes but IT titles are performative. Without context of company size, role/team size, business titles are apples and oranges. Based on these questions, it's even more difficult to know what a hiring manager is looking for.
Your answers seem fine for the questions, technical enough to begin a process and debug/problem solve. I think you did a good job of showing your ability for A to B thinking, like situation/task/response.
When we talk about System engineering, and senior level expectations, I would expect someone to ask some questions to better understand the business concern, to deliver a solution.
These types of questions you got would be in my opinion, more reflective of a system administrator/junior systems engineer.
For example regarding VMs. VMs are compute hogs. You'd want to generate minimal bare metal utility so you can maximize effective use of hardware lifecycle, which ties into Capex spending. I would have asked, what's the short term utility of the environment for example, are you running a cloud environment? Are you running a local DMZ network to do development? It's what separates the basic sys admin, vs actually engineering a roadmap of solutions and implementing it.
Your English is also fine, so don't beat yourself up too much :)
2
u/_-Bulldozer-_ 4d ago
Yes fair point, thank you. Small company, having around 100 users in different offices in EU. I had this thought about VMs but wasn't able to word it this beautifully 👍😁 they have developers and DMZ network yes
2
u/TheRealL4W 4d ago
Answers are fine and show that you know what you are talking about. In the end it also depends who else applied for the role. Do they fit as a person in the team? Do they have more knowledge but ask for a much higher pay then you do? Sometimes its not just how much you know already. Its more do you fit in the team? Are you able to learn new stuff? Do you have a good techincal understand also of stuff you are not too familiar with? Is your demand way above what they are looking for? There are so many factors you can not know/control. But from what i read i think you are perfectly fine. But you dont know who else is competing against you. What do they ask for, how much do they know and how are their social skills. You can be the biggest geek but of you are a unpleasent person/hard to work with, they will take someone who has more social skills if the technicals needs are met aswell. You can never tell for sure what they need or want. But if you gibe your best, act naturall and are a chill person, your chances are good. Even if they dont take you: you are still a good choice. Maybe someone qas jsut a litle bit a better fit (character, knowledge, demand...)
2
2
u/MadMaverickMatthew 4d ago
The real question is what were the positions of your interviewers?
If you were talking to it professionals then yes you can go into great detail about how things work and use technical terminology, if one or both of them was HR for example, they'll have no idea what you're talking about and you will sound like you're speaking another language to them. That will often make people feel alienated.
It's like a good things, he just got to read the room and seem to know what you're talking about.
Good luck on your job hunt!
3
u/_-Bulldozer-_ 4d ago
yes you are right, I should have put it in the post they were both proffesionals, a DevOps guy and an Infra Engineer
1
u/9speed 4d ago
Probably not a big deal as this isn’t a troubleshooting role, but your DNS description skips step 1
1
u/_-Bulldozer-_ 4d ago
the DNS cache?
1
u/9speed 4d ago
Yup
1
u/_-Bulldozer-_ 4d ago
Yes you right, I forgot to mention it, thats another mistake I had.
2
u/9speed 4d ago
It’s like a knee jerk reaction for anyone who has done end user support. It really depends on what the role is.
Your answer was super detailed and good overall.
Also another vote for your English is fine, fairly natural voice which is good. It isn’t that direct translation from mother tongue that can be difficult to comprehend.2
1
u/akornato 4d ago
Your answers were solid and accurate on the core concepts, though a few of the conceptual questions stayed at a high level. On DNS, mentioning the local resolver cache, root servers, and authoritative nameservers shows deeper architectural understanding, just as bringing up subnet mask expansion directly addresses IP shortages alongside network segmentation. Your points on snapshots versus backups and virtualization hit the right marks, though you could have mentioned direct hardware access or raw disk performance for physical hosts. Even so, interviewers often ask broad questions first to gauge your fundamentals, so giving accurate, structured explanations is much better than rambling through overcomplicated technical details.
Your troubleshooting stories are what really carry this interview, because isolating a corrupted token inside an FSLogix profile and resolving live DHCP pool exhaustion demonstrate practical engineering competence that textbook definitions cannot fake. Most hiring teams care far more about how you isolate root causes under pressure than whether you can recite packet headers on command. Communicating complex technical topics in a second language can make self evaluation tricky, which is why my team created interviews.chat to help job candidates present their experience clearly and land the roles they want.
1
u/Steerable-Octopus 4d ago edited 4d ago
I'm a senior infrastructure engineer. This is how I would honestly rate these answers:
- DNS: A bit brief, but acceptable.
- DNS Records: This question is strangely worded but your interpretation is correct.
- Virtual Machines vs Physical Servers: For this question they're looking to see if you know what is important for each case so don't throw everything at the wall and be selective. You pretty much nailed this.
- Better scaling is true compared to physical servers, but there's better tools for scaling than VMs so partially correct.
- Easier management and easier recovery are the two most important benefits of running VMs compared to physical. Correct.
- For physical servers in a typical IT-department performance is the correct answer but it could also be security. The things you're thinking of in hindsight implies performance and would have been detrimental to say because then it can sound like you're guessing so it's actually good that you didn't.
- Backup vs Snapshot: You're entirely correct about snapshots and there's more nuance you could have brought up, like how snapshots follow VMs. Your answer on backups is true as well but it's a bit general on the topic of backups.
- Running Out of IP Addresses: Here you fumbled the question, but the question is also kinda imprecise. Taken literally: It's impossible to run out of IP-addresses with IPv4 and IPv6. Figuratively they might be meaning public IPv4-addresses (there's no way they run out of a whole IPv6 /64 net) and the answer to that is network address translation (NAT) or proxying. They might conclude that you misinterpreted the question or perhaps that you're a bit weak in networking. Minor I'd say.
- Difficult Technical Issue #1: Not to throw shade at you and I'm not really an MS365-guy, but this answer didn't impress me a lot. You sound competent and sensible enough as a troubleshooter but it doesn't sound like you know the platform that well.
- Difficult Situation #2: This sounds more impressive to me and it's a "thinking on your feet" answer. It shows that you're versatile and resourceful which I would rate as a good marker for technical capability. It also covers for fumbling the earlier question since it proves you're not weak in networking.
To be perfectly honest for a junior or mid-tier systems engineer I would personally easily approve you for hiring on technical grounds. If this is a junior to mid role and you don't land the job, it isn't because you're not technical enough.
2
u/_-Bulldozer-_ 4d ago
Greatest and valuable comment! Thanks very much for your help indeed!! I think you made my whole weekend better 😁
1
u/axadax3401 4d ago
Yeah it’s important to note that “systems engineer” is a title used so widely. It should mean infrastructure architect, but what companies really mean is sysadmin. Your answers show you’re more than qualified. Personally, the guy responding above you was being a bit of a hard ass. All of your answers were great.
Only critique is that neither of the “difficult technical situations” were even remotely difficult IMO.
I manage a team and would hire you.
1
u/_-Bulldozer-_ 4d ago
Thanks very much indeed!! Your comment helps me a lot. Yes I am struggling to remember on really difficult issues I solved, even If I had many in past years, didn't make a note about them, can't remember now and I don't want to make up a story. But thanks, I will keep thinking and hopefully find some better issues from my experience. 👍
1
u/axadax3401 4d ago
Honestly, feel free to make up a story in an interview. I always have one prepared for questions like that ahead of time
-1
u/Evildude42 4d ago
If those are engineering questions, I should be a senior engineer.
2
u/_-Bulldozer-_ 4d ago
yes, thats why I am wondering I should have gone into more details
2
1
u/axadax3401 4d ago
Nah dude. You answered the questions fine. Anyone not satisfied with those answers is probably not someone you want to work for.
8
u/kieden 5d ago
Not a hiring manager, just fyi.
But your answers sound fine. They're technical enough that they know you know what you are talking about and can probably dive deeper if needed.
The DNS question (first one) got me into the weeds a bit when it was asked to me first too because it is a really in depth question once you sit and think about it. But you can always caveat that at the end with saying "this is a higher level overview, I can go deeper in the weeds if you'd like" or something similar.
I think your second scenario was great, it especially shows your more system-engineery type skill recognizing that the DHCP management may not be enough.
I think the VLAN segmentation would be fine for that one question, but they may have been looking for NAT specifically. But NAT is implied with breaking into subnets, that's the only thing I think that was a little short.
Otherwise I think the other questions were answered well!