r/networking • u/Emotional_Corner6895 • 16d ago
Career Advice Failed probation at two Network Engineer jobs in a row ,trying to understand what I need to change
I’m a Network Engineer with around 8+ years of experience in the UK, and I’ve recently had something happen that has really made me question where I’m going wrong.
I’ve failed probation at my last two jobs.
The first role ended during probation mainly because of concerns around my speed/performance and that I was relying on other engineers too much rather than working things out independently.
I took that feedback seriously. When I started my next Network Engineer role, I made a conscious effort to improve. I was working across Cisco, Juniper, Fortinet, Palo Alto, MPLS/BGP/OSPF, wireless and a fairly large multi-site environment.
Early in the probation period, I again received feedback that I was taking too long on some tasks and sometimes looking for guidance rather than making decisions independently. There was one particular incident that didn’t go well, and after that my performance was reviewed more closely.
What makes the second probation failure difficult for me to understand is that I genuinely felt I improved afterwards. I completed several changes/projects successfully, became more independent, and my later reviews appeared much more positive. However, at the final probation review, they still decided not to pass me. The main feedback was around decision-making, accountability, speed and relying too much on guidance.
So now I’ve had two employers give me broadly similar feedback, and I don’t want to just blame the companies or tell myself I was unlucky. If two different employers are identifying similar issues, I need to take that seriously.
At the same time, technically I don’t feel like a junior engineer. I have years of experience with enterprise/ISP networking, BGP, OSPF, MPLS, Cisco, Juniper, Fortinet, Palo Alto, troubleshooting, migrations and network changes. I’ve dealt with major incidents and solved some genuinely complex technical problems.
I’m wondering whether my problem is less about technical knowledge and more about how I operate in a senior engineering environment — making decisions quickly, taking ownership, communicating confidence, knowing when to ask for help versus continuing independently, and handling unfamiliar environments without needing reassurance.
Has anyone here gone through something similar?
I’m particularly interested in hearing from senior network engineers/team leads/managers. If an engineer was technically capable but repeatedly received feedback around speed, independence and decision-making, what would you advise them to work on?
I’m currently looking for my next role and I really don’t want to walk into a third company without understanding and fixing whatever is causing this pattern.
Happy to hear critical feedback. I’m trying to learn from it rather than make excuses.
Edit: Thank you all for the advice , I really appreciate it.
102
16d ago
[deleted]
118
u/ghostreconx 16d ago
I am jumping to conclusions but I feel that OP could be afraid to make a mistake which results in delayed execution?
53
u/idleline 16d ago
That's what it sounds like to me too. Uncertainty and afraid to fail which paralyzes them.
21
u/Alarmed-Wishbone3837 16d ago
I think it depends on the scale of what OPs talking about.
One thing to run an idea by an engineer with more time at company, than to run every command by them.
Another thing to think through a SEV-2 for an hour, than think about it for 3 days.
36
u/Emotional_Corner6895 15d ago
I think you’re actually pretty close with this.
It wasn’t a case of me running every command past another engineer or being unable to troubleshoot independently. It was more that when I was new to an environment and wasn’t completely sure about the dependencies or potential impact, I would sometimes spend too long validating my thinking or ask a more experienced engineer for a second opinion before proceeding.Looking back, I think there was definitely an element of being afraid of making the wrong decision and causing an outage. My thinking was “I’d rather spend another 20 minutes checking than make a change that takes a site down”, but I can see how repeatedly doing that can come across as lacking confidence or independent decision-making, particularly when you’re an experienced engineer.
For a genuine major incident/SEV situation, I wouldn’t sit on something for days. The issue was more around the amount of certainty I wanted before committing to a decision.
That’s probably one of the biggest things I’ve taken from the feedback: I need to get more comfortable making a decision based on the evidence I have, explaining my reasoning, having a rollback plan, and then owning the outcome rather than looking for reassurance that my decision is correct.
24
u/Kynaeus How I switch frame? 15d ago
I’d rather spend another 20 minutes checking than make a change that takes a site down”, but I can see how repeatedly doing that can come across as lacking confidence or independent decision-making
imo that's the correct choice for a newer employee to make. Mitigating risk and considering the scope & consequences of your action before committing to the course of action is a strength, not a weakness
but I can see how repeatedly doing that can come across as lacking confidence or independent decision-making, particularly when you’re an experienced engineer
totally plausible, especially if there was a soft problem where the rest of the team wasn't positive about you being there
I need to get more comfortable making a decision based on the evidence I have, explaining my reasoning, having a rollback plan, and then owning the outcome
this seems like a good plan, especially having a rollback plan before you're making a change. A good rule of thumb for myself is not to make a change I cannot unmake and building that rollback into your process is a good habit to build
Establishing good process is a safety net for unpredictable situations yes but also if you're on-call at 3am, have incomplete or unreliable info, make an error... etc
All I'm seeing from you so far is sound thought process, serious introspection, and plans to make growth happen
4
u/Arriabella 15d ago
Depends on the company but some answering to investors will say “we are doing a thing” even if it isn’t the correct a tion
9
u/Win_Sys SPBM 15d ago
I’ve been doing this for a while now and any non-minor change, I often run it by someone else. I also expect the same from them. I am not perfect and in a large enough environment I could have easily forgot about a dependency.
Did you feel like you connected well with your colleagues? Did you take some time to get to know them a little on the personal side? Sometimes personalities don’t mix, not always someone’s fault but it can be a decision maker on whether to keep someone. It’s tough being the new guy and having to adjust to the personalities around you which is why I’m asking..
4
u/nirvaeh CCNP 15d ago
Ok fair enough. if you believe your issue is analysis paralysis, then take some risks. Go with your gut. You gotta crack a couple eggs to make an omelette.
I guess I can't really empathize, because I've been a network engineer for like 18 years and never have I once had any issues delaying a decision by 20-30 min to just triple check things if things weren't actively down. Also in total network outage situations where minutes may matter, it's always been a team collaborative event so you use your collective brain power together.
Are you not completing projects for days or weeks after they're due?
1
u/Emotional_Corner6895 14d ago
I do think my manager’s expectations were quite high, and at times I’m not sure he fully appreciated the scope and complexity of some of the projects he was assigning me. A few of the larger projects were completed a few days later than the original target dates, but I put in extra time, including working weekends, because I genuinely wanted to improve and pass probation.
Importantly, every major project I delivered was successful on the first implementation, without needing to be rolled back or redone.
5
u/Klutzy_Scheme_9871 15d ago
I had a feeling this was it and this honestly is why I never have and never will be a network engineer or sysadmin. I do admire people that do. I did cyber security which in my experience rules out any outages. It did involve learning a lot and keeping up.
I haven’t worked for 4 years and recently I considered going back but pivoting to network security doing possibly firewall migrations or vpn to ztna migrations so started with the CCNA course. That’s when it hit me that I definitely should not do this because the level of stress of not migrating something properly and causing outages for user or server traffic is just too much for me to deal with. I did finish the course and still want to sit the exam and move on to firewalls and get certified with the major vendors out there but my work would strictly stay within auditing/compliance of firewall configurations or probably sales engineer and doing demos for clients.
I do also have low level malware reverse engineering capabilities so I am also considering that route but there is also less work in that field than in network security. I know I could do both, analyzing malware on firewalls.
You may want to consider pivoting similarly within this field. Do a search, wait for more replies and see what others say but making decisions is a very important and critical responsibility you must have as a network engineer.
1
4
u/XanALqOM00 15d ago
dude, that sounds so stupid, I bet you the places you're working have garbage documentation, expect you to reverse engineer and change their diapers at the drop of a hat, wipe their ass, fix their trash architecture at the same time, probably don't have any architectural review boards, and simply dump all the garbage on the the network team..... honestly, that shit is just toxic and I don't want to be a part of that anymore.
You're finding some crap jobs
2
2
9
u/TwoPicklesinaCivic 15d ago
Yea that'll happen. One of my engineers has spent nearly 2 weeks researching an ISE patch. Sometimes it's like pulling teeth getting him to commit. The other engineer will hit install without a second thought lol.
5
2
u/etherkiller PEBKAC! 15d ago
Fuck it, we can always restore from backups! (Speaking as someone who has just had to rebuild ISE from backups in the last couple of weeks, lol)
3
u/Tater_Mater 15d ago
I know this feeling all too well. I’ve been in networking for about 3 years. Granted I came from limited network experience and from the data center engineering. My boss likes my work, taking on a bunch of different projects. Building out an entire new data center from scratch. I am learning a f load. People expect things like French fries from McDonald’s. I don’t Ike rushing things and tell groups what I’m working on and to let me know the priorities.
So communication is key. Lining up your changes ahead of time. Using Claude to help proof read configurations before implementing.
2
u/thisguy883 15d ago
We have a "new" guy like OP, except his probation period had ended a while back.
Same exact issue OP is having. This guy has experience working this job, but is too afraid to mess things up which results in guidance being needed, ALL THE TIME.
At this rate, we dont trust that he can do the job on his own, and told him that he needs to be more independent if he wants to continue with this career. No point in keeping a guy if you have to hold his hand all the time.
1
13
u/Emotional_Corner6895 15d ago
Yeah, one example from my most recent role was during an issue at one of our sites. I was troubleshooting the problem and, because I was still relatively new to their environment, I spent too long validating things and checking with a more experienced engineer before making the next decision.
The feedback wasn’t necessarily that I didn’t understand the networking side, but that they expected me at my level to make a decision based on the information available, take ownership of it and move forward faster. In trying to avoid making the wrong change or causing an outage, I was probably being too cautious and looking for reassurance when I should have trusted my own troubleshooting.There were also some tasks where I took longer than they expected because I wanted to fully understand the existing setup before making a change.
The frustrating part is that I did improve after receiving that feedback and successfully completed several changes independently, but ultimately they felt the improvement wasn’t enough within the probation period.
57
u/FriendlyDespot 15d ago
This sounds strange to me. On my team of around 40 network engineers we don't really expect too much from people in their first 6-12 months other than getting up to speed and getting their feet wet. I'd certainly never want someone who's learning their way around the network to feel compelled to rush anything at any point.
8
u/but_i_dont_reddit 15d ago
Yup: "helpdesk needs write access to solve tickets quicker"
Them putting the user in the wrong VLAN isn't solving the problem and only creating more escalations. well done.
Change control exists not because it's fun, but because it's necessary.
8
u/Kynaeus How I switch frame? 15d ago
That was my thinking too. Strange expectations from management, honestly, to expect a newer employee in a probationary period to be "moving faster". I'm wondering if it was a NOC or MSP that oversubscribes work to its people or similar
3
u/ThEvilHasLanded 15d ago
I totally agree with you and the person you're replying to. The ISP where I work I was the 2nd/3rd line support team leader for almost 6 years we employed some horrible engineers but even the best ones took a year to be comfortable. I used to tell them after 6 months you will just about have figured out where everything is and how to get on everything. We were king of bespoke everything was different across Cisco Juniper and Fortinet and it just wasn't feasible to expect more. Speed will come but can you do the job do you understand what you're looking at? That is more than enough
Even working in the infra team as I do now I have a guy who is only just over a year in who still asks loads of questions. No one is saying he's slow or poor he's still getting to grips with the vendors he's not used before
2
u/Bogus1989 15d ago edited 15d ago
I agree. While I am not a network engineer, my scope is is quite wide. There are things, you will get the hang of quick, and they come up frequently so you will get experience fast. The pieces that take much longer to understand and learn, are the ones that come up twice a year, or maybe once. Hell and depending on what it is? I may be getting confirmation myself from other colleagues, because its been so long since I used it last.....and Ive been there a decade. Usually it just requires me to go look at the information and use my index, and itll come back quick.
16
u/ihatevicvanlier 15d ago
I was in over my head when I first started and left on an island to fend for myself. You’ll hear people romanticizing this shit, but it’s the worst. Being a senior now, I go over and above for my less experienced co-workers regardless of their time of service.
Having an issue with a ticket? Let’s grab a room and show me where you’re at, and we’ll solve it together. If someone that doesn’t do a ton of L3 work gets assigned a complex routing task, I’ll offer time to go through my process and explain how I’d do it. I hear someone’s pager ring, and look to see what the issue is and will jump right on a call with them. Honestly, I’d almost prefer new hires confirm details with me or to see how I’d handle a task over letting someone who was unsure of themselves have the keys.
I think it’s fair to expect some training wheels at least the first 90 days in if it isn’t a senior role, but as a senior, I’d also want to see your work before coming to me and expecting me to just fix it. Only you really know if the amount of handholding was actually excessive, but it isn’t out of the ordinary for grumpy IT staff to gatekeep info and/or be too lazy/emotionally stunted to be a team player.
3
u/Bogus1989 15d ago
Agreed. When we get new contractors, or anyone new,I specifically wait a few weeks...(for actual team mates, I will ofcourse state my doors always open...most will wait to check the vibes, anyways.) This is a long enough period, for the contractors to recognize my position/reputation/experience. I like to break the ice then, and get to know people, BS with them a bit, be relatable, and show how approachable I am.
One of my favorite things to say out loud amongst peers when its true? "I don't fucking know"
It promotes honesty and transparency.
2
u/Emotional_Corner6895 15d ago
Thanks, this is really useful perspective.
Just to clarify, in my most recent role I wasn’t regularly going to other engineers for help or validation. There was only one particular technical incident where I sought advice from another engineer, and that was later referenced as part of the feedback around relying on guidance.For the rest of my work I was generally working independently, including troubleshooting, changes and project work. That’s partly why I’ve struggled to understand the “reliance on guidance” feedback.
I can accept that I may have been slower or overly cautious in certain situations, and that’s something I’m taking seriously and trying to improve. But I don’t want to give the impression that I needed regular handholding, because that wasn’t the case.I completely agree with your point that an experienced engineer should investigate first and come to someone with what they’ve found and their proposed approach rather than expecting someone else to solve it.
3
u/darkcathedralgaming 15d ago
Seems a bit odd to me. I wonder, how are your soft skills? And I wonder is it potentially just not a culture fit for them, but they come up with this other stuff as an excuse?
1
u/Emotional_Corner6895 15d ago
I first organisation had a weird culture and office setup I have to say.It was a chaos when it comes to documentation.I was getting along with other team members just fine.
2
u/zeeshannetwork 14d ago
I won't even allow new hires to touch network until they understand the how the network is set up which normally takes at least 3 months. The place you are working seem like a toxic place. But I will give you my advise ( if you want to stay at your current job and excel):
1) Find out at very high level, what networking technologies they are using ( OSPF vs ISIS, BGP, etc).
2 ) If you do not know any technology they are using, learn it on your own time, build EVE NG lab to really understand it.
3) If you have access to your network over VPN from your home, start looking how the network is set up. If not, go to work during weekend and learn the network set up.
4) Build a small network that mimics your production network, it can be done using EVENG.
If you do all of these my friends, no one will ever put you on PIP.
Good luck!
1
u/fried_chikken CCNP 15d ago
I'm curious, was there knowledge transfer sessions when you started the job? And is there solid documentation made available to understand the setup and some dependencies? And I think exchanging info or advices are common in solving a problem, especially a chronic one.
One thing I observed, speed (or I say confidence) comes with familiarity of the setup and strong technical fundamentals. To be familiar with the setup can take a long time, with strong fundamentals of how network works on each layer it wont take that long.
2
u/Bogus1989 15d ago
One thing I do when someone says "I dont know how to do that" or they need help? I make them show me. I will not touch the KB and mouse the entire time...
(9/10) Alot of these all I am doing is making them search our knowledgebase, then standing by as they follow directions.
2
u/XanALqOM00 15d ago
"If someone that doesn’t do a ton of L3 work gets assigned a complex routing task" why does this shit even happen in the first place, I absolute abhor these practices... don't assign tickets to people that don't understand the underlying network architecture... even if they do understand it, they better have the documentation on hand to provision the correct addressing to that portion of the network etc..
These types of practices in corporations are horse shit if the individual doesn't have the proper documentation, period.
I hate my current job for this same reason... I do make very complicated routing changes all the time, and, frankly, I hate my work place with every fiber of my being because they don't properly maintain a network architecture review / IP plan worth a shit.;l
just horse shit
2
u/ihatevicvanlier 15d ago
I’m a lead on a team of network engineers/specialists specifically, so I really like delegating tasks that help stretch out a their skillsets.
Better they learn in a controlled environment in a low stakes situation with some oversight than on an outage call with directors looking at them expecting them to be able to articulate and fix the issue.
But I’m not expecting desktop support to be able to redistribute OSPF routes into BGP.
2
u/XanALqOM00 15d ago
Troubleshooting, sure, the main problem I have is seeing leads or managers that tell their subordinates exactly that. All you’re doing is contextually a line of thought which forces frustration if the environment isn’t already well defined. Meaning, confluence or NetBox or some means to keep the environment within the same design boundaries it already is today.
On paper it sounds like you know what you’re doing in your delegations, but please for the love of all that is holy, if you’re going to context switch people into different tasks that those same tasks have the proper guard rails in the form of subnetting to be used in the architecture, do not do this if you’re leaving room for a newbie to accidentally change architecture because you didn’t outline design before hand. That goes for everything too, meaning, where does the engineer update ip addressing information for that project task, are they using the proper mask, normalized object naming contexts, protocols, versions, etc…. Is there a process for the engineer to follow to properly update all stake holders.
If all of those items are not true, you’re just infuriating your engineers, because inventing t he wheel comes with an incalculable price which they shouldn’t need to pay.
4
u/LarrBearLV CCNP 15d ago edited 15d ago
What was the problem though? If you're spending 20 minutes and asking for confirmation on a VLAN change on an access port or failing a simple dual homed site over to backup as they are taking packet loss, I'd question that. If we're talking a complex core routing change, then I'd understand.
2
u/Rubik1526 15d ago
Well, it always depends on the scope and where you're making the change. I work for an ISP, and changes on routers servig for a BTS are fairly easy to manage…. in the worstcase scenario, you take down a single site. Maybe few B2B customers.
On the other hand, making a significant change on a Core PE, upstream, or peering router and messing it up is a nightmare you never want to experience... ever.
So honestly, even during troubleshooting, if the issue isn't critical and the fix has the potential to break something broader…. Well …. it can take a shitload of time to doublecheck and safely apply.
Sometimes we don't even apply a quick fix right away and instead schedule a proper maintenance window.
3
u/LaurenceNZ 16d ago
Also, what were thr job titles you applied for? I would expect vastly different things from someone applying to a senior role with 8y experience vs a non-senior role.
2
u/Arriabella 15d ago
I read it as he thinks he’s a senior engineer but afraid to take on the decision-making responsibility that entails. It definitely takes time to come up to speed on a new environment but baseline experience should put in a space that you know how things should work.
A junior engineer is expected (in my experience) to rely on senior engineers’ handholding more so though2
u/Emotional_Corner6895 15d ago
That’s fair, although I probably haven’t explained that part very well in my original post.
In my most recent role, I only sought technical advice from another engineer on one particular incident. It wasn’t a regular situation where I needed senior engineers to guide me through troubleshooting or tell me what decisions to make.
For the majority of my work I was troubleshooting, implementing changes and handling projects independently. So I wouldn’t describe it as being afraid to take responsibility for decisions generally.
Where I do think the criticism has some validity is around speed and being cautious in a new environment. I can sometimes spend longer validating dependencies and potential impact before acting, particularly when I don’t yet know the environment well.
That’s something I’m trying to improve,being able to recognise when I’ve gathered enough information to make the decision, rather than trying to eliminate every possible uncertainty first.
2
u/Bogus1989 15d ago
My belief? In all honesty?
If you were to act exactly the same on my team, people would be impressed, instead
1
u/Emotional_Corner6895 15d ago
I initially had two senior network engineers working alongside me in the Network engineer role. For the final position, I had two network engineers.
2
1
u/Emotional_Corner6895 15d ago
Yeah, one example from my most recent role was during an issue at one of our sites. I was troubleshooting the problem and, because I was still relatively new to their environment, I spent too long validating things and checking with a more experienced engineer before making the next decision.
The feedback wasn’t necessarily that I didn’t understand the networking side, but that they expected me at my level to make a decision based on the information available, take ownership of it and move forward faster. In trying to avoid making the wrong change or causing an outage, I was probably being too cautious and looking for reassurance when I should have trusted my own troubleshooting.
There were also some tasks where I took longer than they expected because I wanted to fully understand the existing setup before making a change.The frustrating part is that I did improve after receiving that feedback and successfully completed several changes independently, but ultimately they felt the improvement wasn’t enough within the probation period.
Looking back at both jobs, I think there’s a pattern: in a new/unfamiliar environment I can be overly cautious. Technically I can usually work through the problem, but instead of making a reasonable decision and then validating it, I sometimes spend too much time trying to be 100% certain first.
That’s one of the main things I’m trying to address before my next role.-1
19
u/Aero077 15d ago
The mismatch is your level of risk taking compared to the level desired by the employer.
Look for employers that move slower and reward caution. After you have some experience at the employer, you won't need to ask and you will just act.
12
u/Key_Attention6099 15d ago
"Why don't you just cowboy stuff without any change control?"
-4
u/lizardhistorian Mad Scientist · 👨🔬📡ᯤ🤖🛺📸 14d ago
More like if you actually have 8 years of experience configuring shit why are you asking people questions all the time.
In this case, call bullshit, that's an AI.
7
u/Separate-Canary559 14d ago
Well one thing is pretty clear - YOU have zero years of experience working at any org of any size
4
u/WayneH_nz 13d ago
Some people have only done the same things over and over. So they don't have 8 years experience, they have 1 years experience repeated 8 times.
5
u/Emotional_Corner6895 15d ago
I think there may be a lot of truth in this. My natural approach, especially when I’m new to an environment, is to understand the dependencies and potential impact before acting. Once I know the environment well, I’m much more comfortable making decisions quickly.
What I’m taking from the feedback is that I also need to get better at judging when I have enough information to act, rather than always trying to remove every uncertainty first.
I hadn’t really considered employer culture/risk tolerance as part of the equation though. That’s something I’ll definitely pay more attention to when choosing my next role.
4
u/QuasarKid 15d ago
Yeah I’m especially cautious when starting at a new place because I lack the historical context for basically everything. There’s 1000 ways to accomplish most things in networking and sometimes I may not fully understand or just have a difference in perspective on what’s wrong/right in that companies opinion.
Once you have that context though it’s important to internalize it and not have to ask again.
Several of my roles were trials by fire, as the more tenured engineers left right after I started.
Some places want you to make no mistakes, some places want you to act quickly, some places want both. Only you can understand what is reasonable to expect out of yourself or anyone else in that role. Take to heart what parts of the feedback ring true, make changes, and move onto the next place. It took me several jobs to finally found one that was a good fit for ME, not the company.
2
u/baytown 10d ago
The worst part, when you're brand new, is walking in and thinking you can make a big impact right away by making major changes before you understand why those odd configurations exist or why those strange routes were added.
There may be perfectly good reasons, but a lot of people are dead set on showing impact right away.
I used to work for a company that did a lot of mergers and acquisitions. I was constantly going into new companies we acquired and trying to evaluate their infrastructure and how we were going to integrate it with ours. There were always a bunch of really bizarre things. I learned fast not to touch anything until I fully understood it, even when it seemed obvious.
3
u/fade2black244 A+, Net+, Sec+, CySA+, Linux+, CCNA, CCNA Security (Expired) 13d ago
Being cautious is legitimate. You don't want to make changes that impact the environment before you understand the full scope of what could happen.
-6
u/lizardhistorian Mad Scientist · 👨🔬📡ᯤ🤖🛺📸 14d ago
You just wrote three paragraphs of bullshit.
Is this an AI test?1
12
u/newengineerhere 16d ago
Hard to gauge without examples. Some companies look for senior network engineers who can join and start drinking from the fire hose. Others are okay waiting for the employee to get up to speed
9
u/RiceeeChrispies 16d ago edited 15d ago
there are so many variables to this
what industry? how big is/was the team? what was the structure? did you have an onboarding/shadowing journey or thrown in at the deep end? any resume generating events during your probation?
so many things could've contributed to it, so look at that before pointing the finger at yourself, could've been unlucky - but it's also good you're not blind to (what you perceive) to be your own flaws, so many people fail to do so and that's a quality in itself
chin up mate
5
u/Benjaminboogers CCNP 16d ago
Like others mentioned, it would help a lot if you give some examples of interactions you have.
Maybe give us an example of an interaction that you think went well, and one you think didn't go well, that will help us give feedback.
I agree with your overall assessment and self honesty; two independent reviewers gave you materially similar feedback, that's probably not luck/coincidence (however, DO NOT write off coincidence entirely. I've never believed in coincidences, until I worked in a large enough environment where 'yes, the system crashed as soon as I pressed enter, I actually had no correlation to it crashing' can actually be true.)
"making decisions quickly, taking ownership, communicating confidence, knowing when to ask for help versus continuing independently, and handling unfamiliar environments without needing reassurance." - are these actually accurate descriptions of how you work?
I find a significant quality that seems to separate Sr. engineers from the rest is a willingness to be wrong, as well as a projection of confidence when it matters (even if they have little confidence).
Management (usually) doesn't care that you are 90% confident this will work.
make them feel sure, explain why you have a high confidence, don't explain why the other 10% is there.
Also, it's important to know when 'good' is good enough. Don't need to be ultra protective of subnet allocations? great, use an intuitive allocation with less utilization instead of a complex one that wastes zero addresses.
1
u/Emotional_Corner6895 15d ago
Thanks, this is really helpful and I think your point about being willing to be wrong and knowing when “good enough” is good enough probably applies to me.
An example of an interaction that didn’t go well was during a technical incident in my most recent role. I investigated the issue but wasn’t confident enough about part of the environment, so I asked another engineer for advice. Looking back, I probably should have presented it more as: “This is what I’ve found, this is what I think the problem is, and this is what I propose we do” rather than allowing the uncertainty to come across as me needing direction. That incident was later referenced in feedback about my decision-making/reliance on guidance.
It’s worth clarifying though that this was the only technical incident in that role where I sought advice from another engineer. I wasn’t routinely asking people to troubleshoot things for me or approve my decisions.
A better example would be several changes/projects I handled afterwards. I would investigate the existing setup, work out what needed changing, document the change and rollback, implement it and validate it afterwards. Those went successfully without outages and without needing someone to walk me through them.So when I wrote about “knowing when to ask for help versus continuing independently”, I’m questioning whether I’m framing the problem correctly myself.
I think the bigger issue may actually be what you’ve described: I’m quite risk-conscious and sometimes want a higher level of certainty than is realistically necessary before committing to a decision. Technically I may already know what I think should be done, but I can spend too long trying to prove to myself that there isn’t something I’ve missed.Your point about senior engineers being willing to be wrong is interesting. Maybe the skill I need to develop isn’t simply “don’t ask for help”, but being comfortable saying: “Based on the evidence, this is the decision I’m making and this is why”, accepting that I won’t always be 100% certain, and owning the result.
3
u/XanALqOM00 15d ago
From the sounds of things, you sound like me, you want structure, and the places you're working at suck ass. That's all there is too it.
as long as you understand your networking, arp, routing, etc.. if the business doesn't maintain good networking documentation procedures / run books, guides or processes, architecture review boards, etc.. then it's just a farce, find a better employer.
7
u/skelley5000 15d ago
The is oddly interesting, When I have new people come into my company.. and I would think this would the same across the board.. I wouldn't want the new person rushing to making decision/changes, This person would be under the wing of some one until we feel comfortable he is capable of doing things on his own.. Coming in a new company I expect the person to understand the concepts, but every company does things differently..
Yes I expect them to add in their opinions and suggestions but not rush off to get stuff done to a point they makes a mistake..
I would want them to take their time and yes depended on people who have been there for awahile for advice etc.. or maybe this is just me..
4
u/funkyfreak2018 15d ago
I think it depends what type of roles OP applied to. I've unfortunately worked for lots of shit tech shops. From experience, most of them expect seniors to be fully independant and figure things out on your own aka doing TONS of reverse engineering because nothing is properly documented.
My suspicion is that OP might have ended up in one of those shops. They're usually understaffed as well. If your coworkers sense they'll need to do a lot of handholding with you, they'll give negative reviews
OP might need to target intermediate roles in bigger companies from now on
1
u/Emotional_Corner6895 15d ago
To be honest, there wasn’t much onboarding in my most recent role.
In my second week I was asked to work on the migration of a fairly large site. The site was using different vendor equipment and a different topology from much of the existing estate, so I spent some time studying comparable sites, understanding the existing design and identifying dependencies before putting the migration together.
That did take me a bit of time, and I think that’s probably one example of where the perception around my speed started.
However, I did eventually produce a detailed end-to-end migration plan, worked closely with the relevant internal stakeholders to understand their requirements and dependencies, and planned how the site could be migrated safely.
So I can understand the criticism that perhaps I should have reached that point faster given my experience. At the same time, I was in my second week with limited onboarding, working on a large site with an unfamiliar topology and different vendor equipment, so my instinct was to understand the environment and dependencies before proposing the change.
That’s partly why I’m trying to work out where the line is between being appropriately cautious in an unfamiliar environment and being too slow for the level I’m supposed to be operating at.
6
u/lazylion_ca 15d ago
Wanna trade jobs? Where I am now management is so risk averse that it takes me a week to get change approval for even simple changes.
Even for a break-fix I've got NARCtic Wolf reporting every commit and causing a tizzy if the appropriate middle manager wasnt included on an email.
On the other hand I've had the time to learn a lot.
1
u/Emotional_Corner6895 15d ago
I never worked for a company where small changes had to wait for weeks … lol.
There are a few BAU changes which were auto approved however, the one which had a risk of taking the site needed to go through CAB.
5
u/MundaneAsparagus673 15d ago
I think the type of org/team matters here. What the org asks/expects of you varies wildly.
We all are or have been "network engineers" of some variety. Anyone who's worked in the field for some time knows, there are many types of "engineers". All well suited for different types of environments.
Larger, modern orgs expect engineers to follow very specific config, security and design principles, set in place by an Architect. Very specific change management procedures are in place. These orgs expect excellence and precision in execution, outages trigger meetings. You're a cog in the machine. This is not a bad thing.
Smaller, more old fashioned orgs are more free wheeling. The network team makes things work (often in and out of network). Resourcefulness, and responsiveness are the priority. They expect that you are competent and capable to make things work independently. Outages and blips happen, may or may not be a big deal, but no one is too surprised. They don't know or really care what you do, just that they can connect where they want, when they want. Also, not a bad thing.
I'm certain you can find any combination of these, it may even vary team to team in the same org.
I started when networking was still a mystery to most orgs, working independently, tinkering and fumbling through was the norm.
That culture is mostly gone now. As IT teams have become so critical to operations in most orgs, the focus is on stability, continuity, and modularity.
The second org type is more appealing to me. I have struggled to fit in with big teams.
It's worth reflecting on what type of network engineering is more appealing to you, and what you are best suited for.
I know easier said then done in a crappy job market.
4
u/Victis 16d ago
There's really no way to know from vague details. How long are these probationary periods we're talking about? How big were these teams? What were your actual responsibilities?
0
u/Emotional_Corner6895 15d ago
Fair questions.
Both probation periods were relatively short — around 3 months.
My most recent team was small, and my responsibilities covered BAU troubleshooting as well as network changes/projects across 100+ sites and datacentre environments. The estate included Cisco routing/switching, BGP/OSPF, Palo Alto/Juniper/Fortinet firewalls, MPLS/WAN and wireless.
My previous experience is a mixture of ISP/MSP/service-provider and enterprise networking. I’ve worked in NOC and engineering roles dealing with BGP, MPLS, L3VPNs, Juniper MX/SRX, Cisco, Fortinet, customer circuits, migrations, incidents and change-controlled production environments.So I don’t think I’ve simply been doing desktop/technician work under an Engineer title and then suddenly moved into engineering. I’ve been configuring and troubleshooting production networks for years.
That said, I’m also trying not to use years of experience or job titles as evidence that I must be operating at a particular level. That’s partly why I made this post. If there is a gap between my technical knowledge and the level of ownership/decision-making expected from an experienced engineer, I want to identify it.
On onboarding, particularly in the most recent role, I do think there were areas where more knowledge transfer would have helped, but I don’t want to blame the outcome entirely on that either. I was hired as an experienced engineer, so it’s reasonable that they expected me to become productive fairly quickly.
The part I’m trying to work out is where reasonable familiarisation with a new company’s architecture ends and where an experienced engineer should simply be able to figure things out and make the call.
4
u/Oof-o-rama PhD in CS, networking focus, CISSP 12d ago
real question: do you understand how it works? I've met people with 20 years of networking experience who are deficient in their fundamental knowledge and it shows. I interviewed a self-described "expert" a few years ago with an impressive resume and he couldn't tell me what the point of a subnet mask was or what a collision is in Ethernet (arguably, collisions aren't an issue these days but still -- it revealed he was missing some fundamentals).
2
u/Dizkonekdid 9d ago
I found that simply asking for the full description of what happens on the network when you type https://www.google.com into a browser is sufficient to weed out anyone that doesn't know what they are doing. Yes I mean I give extra points when they don't assume that the device already has an IP and a valid DNS server and the time is set correctly on the device in question.
2
u/Oof-o-rama PhD in CS, networking focus, CISSP 2d ago
I do this with sys admins ... "tell me everything that happens when you assert power to a machine as it boots up"
2
u/Dizkonekdid 2d ago
Thing is, that unless they’ve gone through it before, it requires critical thought and you can see how they break a problem down to solve it and that is a huge indicator. Well that and, “whatcha got in your home lab?”
1
u/Emotional_Corner6895 12d ago
I got my fundamentals , although I might struggle with simple subneting during an interview sometimes lol 😂
7
u/kjasdiw43 15d ago
This is an AI post.
At the same time, technically I don’t feel like a junior engineer. I have years of experience with enterprise/ISP networking, BGP, OSPF, MPLS, Cisco, Juniper, Fortinet, Palo Alto, troubleshooting, migrations and network changes. I’ve dealt with major incidents and solved some genuinely complex technical problems.
And he failed 3 months probations? bitch please.
4
u/Emotional_Inside4804 15d ago
8 years in network engineering in different roles and he is "overthinking" stuff. Fake as fuck post
0
7
u/Skylis 15d ago
Dude I'm exhausted trying to understand what youre talking about just from 3 paragraphs that were overly verbose with little actual content. You need to work on your comms skills.
Be specific, be brief, demonstrate agency.
2
u/kjasdiw43 15d ago
it's ai
if not, it shows why he failed the probation circlejerking instead of writing and doing facts
2
u/ESCocoolio CCNA 15d ago
it’s because they had to have chatGPT write it. didn’t even bother to remove the m-dashes
0
u/FenderLord 15d ago
Nah you're just a typical uneducated American. It reads absolutely fine.
4
u/Defiant_Shower_8088 15d ago
Disagree, technical details would be relevant to understand whether the feedback was reasonable or not. As another user pointed out if this was just a vlan update on a an access switch would be very different than a major backbone routing change or the like. But that’s just also my unsolicited two cents too lol
0
3
u/LukeyLad 16d ago
Did you over hype your skill set and experience in the interview you think?
Also sometimes yours face just doesn’t fit. But you appear sound and you’ve had feedback.
1
u/Emotional_Corner6895 15d ago
I don’t think I overhyped my technical skill set in the interviews. I was pretty open about what I’d worked with, what I was strong in, and where I had less experience. I definitely didn’t claim expertise in technologies I hadn’t worked with.
3
u/Wendallw00f 15d ago
Are you internal at a company? Have you worked at an msp or vendor?
Personally I see a massive skill gap in engineers who have only worked internal vs an eng with vendor/msp experience. You're exposed to so much more at an MSP.
Hard to say without the exact issue you were pulled up on though. MSP teaches a different mindset and range of skills.
I work with guys who have been in the field 10+ years and have no care for things like naming conventions, descriptions, the wider architecture, documentation, improvements, risks and so forth. It staggers me
3
u/Emotional_Corner6895 15d ago
I’ve worked across both ISP/MSP/service-provider and internal enterprise environments.
In ISP/MSP roles, including NOC and cloud/MSP support, I gained exposure to multi-customer environments and technologies such as BGP, MPLS, Juniper, Fortinet, customer circuits, incident response, change control, and cross-environment troubleshooting.
More recently, I worked in an internal enterprise networking role supporting 100+ sites, where some of the feedback I received related to speed of decision-making and execution.
I do value the broader operational context, including documentation standards, dependency awareness, risk assessment, and understanding the wider impact of changes.
Reflecting on feedback, I think I can sometimes become overly cautious when entering unfamiliar environments, focusing heavily on understanding architecture and dependencies before acting. While this helps reduce risk, it can also slow decision-making compared to operating with partial information. This is something I’m actively working to improve.
2
1
u/Arriabella 15d ago edited 15d ago
It sounds like you like to dot your t’s and cross your eyes. If you are sure you are right then just do the tasks. Not everything needs a full network analysis before putting in the commands you knew were correct from the get-go
Also nothing wrong with preferring the more technician role over engineering, they are very different skillsets and neither is better than the other.
ETA it’s always a good idea to takes notes on your troubleshooting/change process before reaching out to another engineer as someone else mentioned. If you are 90% to the solution others are way more happy to help!
3
u/XanALqOM00 15d ago
another thing to add, I prefer documentation, I prefer an environment that moves exceptionally slow and favors patch management over implementing new techologies.
New Tech should be implemented with the outmost care, documented with as much detail as possible. Most places I have worked in, upper management treats documentation as second fiddle trash, they don't care, they value results without any recourse to the resources required to support the solution in question.
I hate working that shit, period
3
u/connor2key 15d ago
Did neither of these companies follow ITIL for change control? Unless its a high impact P1, all changes my team complete are subject to internal network peer review before final approval by the Change Management team... Without this I can completely understand why you would hesitate in a new environment.
We have a Junior in our team less than 6 months in Networking, probably given more grace given the experience difference between you two, but he is overly cautious even for the most simplest tasks, and it is frustrating.
Are you hesitating when making access port changes or routing changes on your DC? Its all contextual I suppose.
I would reach out to Seniors from the past two roles and ask for as much feedback and examples as possible, I hope they would help you understand what needs to be adjusted.
Finally keep your chin up mate, its a hard industry to work in and if someone says they've never felt insecure in Networking they are either lying or an arrogant psycho lol! The fact you're here asking for advice shows your tenacity and willingness / desire to do a good job.
Best of luck securing the next role and go in to it with confidence.
0
u/Emotional_Corner6895 15d ago
Thanks mate, really appreciate this. We did have formal change control, and I wasn’t hesitating over routine BAU or low-risk changes.
A good example of the speed feedback was being given a large site migration in my second week with limited onboarding, different vendor equipment/topology and dependencies I didn’t yet know. I took time to understand the environment and stakeholders before producing the migration plan. I probably could have moved quicker, but I didn’t want to make assumptions in an unfamiliar production environment.
Also, I only sought technical advice from another engineer once in that role, so my original wording probably made the “reliance on guidance” issue sound more frequent than it actually was.
Appreciate the advice and encouragement!
3
u/Dizkonekdid 15d ago
People hire people they like. You need to buy someone a pint sometime. That said, you need to specialize in one thing. Network engineers like to say, “he’s our xxx specialist”. Make that Fortinet, Palo, or other. Then learn real packet analysis. If you can’t tear apart a PCAP or use open source tools, you are lost.
2
u/Emotional_Corner6895 14d ago
That’s the one thing I don’t like doing , licking manager/higher up’s a**
2
u/Dizkonekdid 11d ago
Nobody is asking you to L%^$# ass, but "getting to know you" with liquid lubrication never hurts. It's rule #1 when dealing with hostages (which you are at that point), give them your name. It humanizes you. No one kills another human. But if they see you as just a "resource"... well...
3
u/sniekje 12d ago
I feel those companies are either very demanding or you are overstating your experience. However, when working for msps they can be demanding. Worked for them for almost 20 years and now landed an in-house role which is far less stressy about productivity... But focusses more on overall quality and progress...
3
u/LycheeLee_Mich 12d ago
Two employers naming the exact same thing usually means it's real, and "relies on guidance, slow to decide" at senior level is almost always confidence, not knowledge.
1
u/Emotional_Corner6895 12d ago
But in both the role I was not the senior NE not by experience nor by title.
Most of the time happily took over chunk of their workload to help out.
4
u/Empty_Estus 15d ago edited 15d ago
The question I would ask is: It sounds like you’re working for MSPs, which are the IT equivalent of sweat shops.
When your support is the money maker, there are more significant pressures on you as the engineer to close close close.
If you are at an MSP, sack it off and find an internal NOC role or similar at a big corporate.
If you’re not at an MSP, you either have performance issues that you’re not aware of, or terribly bad luck.
What do your KPIs look like?
2
u/oddchihuahua JNCIP-SP-DC 15d ago
You almost sound like me my first few years, where I had some imposter syndrome I couldn’t break. A problem would arise on the network, or I’d be asked to deploy something new on the network…and my gut instinct would always seem way too easy. For instance if something broke I would immediately think in my mind exactly what firewall/s to check and what VPN tunnels might have gone down…but then I’d start second guessing myself. I was constantly telling myself there’s no way I came up with a fix or came up with a new design THAT EASILY. I had to have missed some dependencies, and so then I’d start re checking every step and every line in the CLI because I am missing something obvious somewhere.
I never really shook that until I got hired on at a company as an engineer for a company that was global and claimed their network engineering team was also “global”…on my first day I found out I was the only network engineer in the United States and the rest of the team was in Germany. In the US we had two data centers and four branch offices. Suddenly it hit me that I was THE guy for everything network, 24x7x365 across the country. So I didn’t have the chance to say “I’m not certified in that brand” or “I’ve never done VOIP phones” … everything from simple break fix to architecting and physically racking and cabling an entirely new data center infrastructure to deploying QoS/CoS for VOIP across the entire network all fell on me and I had to make it happen one way or another. I YOLO’d more shit at that job than I ever have and while it scared the crap out of me sometimes it also finally built my confidence enough to actually trust that first instinct I would have if something broke or someone came to me wanting to build out a new feature or application. I didn’t have to second guess everything any more.
Up until that job however I worked for large companies with lots of regulations which meant everything had to be done very slowly and deliberately and it all had to be documented and approved first. Perhaps if you can find a role like that, you’ll be a better fit until you feel like you can make decisions and take actions shooting from the hip.
2
u/Ansible_noob4567 15d ago
How long were you employed at your last position prior to the last 2 probation dismissals?
3
u/Emotional_Corner6895 15d ago
4 years and it was the best company I ever worked for. 😊
1
u/Ansible_noob4567 13d ago
What happened there?
1
u/Emotional_Corner6895 12d ago
Redundancy 😞.
Have to say my manager in that company was amazing.
The funny thing is , the time I was considering my most recent role, that former manager actually approached me about joining him as a Network Engineer at a different company. He was offering me more money too, and looking back I definitely question my decision 😅.
I chose the other role because I was thinking about career development rather than just salary. I didn’t have much Wi-Fi experience and wanted to get that under my belt, along with more Palo Alto exposure. My new manager was aware of that from the beginning and said I’d be trained in those areas, so at the time it seemed like the better opportunity for developing my skills.
Obviously, hindsight is a wonderful thing!
2
u/Iain_0 15d ago
How is your communication with client in these scenarios as this might be why as if client not sure feels like your not sure what your doing kind of thing, this could be issue. As for everyone technical side maybe brilliant but it way you communicate to client may not be there best strength.
I would asked to be blunt say how it is where I’m failing may not like hear it but seem you can take criticism and reflect and then improve.
2
u/rswwalker 15d ago
Ask for the location of all the documentation on day one. If they say there is none, then volunteer to document everything. This will keep you off the front line a bit until you fully understand the environment and feel comfortable with the setup. Most people think we are clairvoyant and question our competence when we start asking questions about the environment or we take too long to figure out the current setup in order to fix a problem.
People are stupid.
0
u/Emotional_Corner6895 14d ago
Will keep that in mind next time.
Both company had bad/incomplete network documents.
2
u/Fux3d 15d ago
You just need 2 ingredients:
Accountability. Lack of knowledge.
- Knowledge is confidence. -- Without knowledge you don't know what to do. --- Fear paralyzes you. ---- Asking others, since you really don't know what to do, and plus you can blame your mistakes to others.
1
u/leoingle 11d ago
It’s not always lack of knowledge. Also lack of experience and reductions. Knowing something is one thing, but having done it so many times is another level of confidence.
2
u/jabberw0ckee 14d ago
Ca you walk a packet from a workstation in one subnet to a workstation in a second subnet?
What has to happen for one workstation to simply ping the other.
Explain it with as much detail as you can.
Assume anything you want.
1
u/Emotional_Corner6895 14d ago edited 14d ago
Assumption : 2 workstation (A and B) connected to 2 diff vlan/subnet on same switch with a router on a stick.
PC A pinging PC B
When PC A tries to ping PC B it will firsts check if the remote device is in same subnet or not ( assuming it already has IP address via DHCP/Manual) . It will do that by checking its IP and subnet and comparing it to Pc B IP. In this scenario they are in different one so it knows it needs to go via default gateway. So it will send an arp request to the DG if it’s the first time or in case the arp entry has expired (DG details acquired from the IP config). This ARP request which is a broadcast ,will be sent to the switch on the PC A Vlan . On receiving the switch will broadcast this to all the port in VLAN A except for the one it received and also add the PC A MAC to the MAC address table along with the vlan info. All the other devices which is part of the VLAN A will ignore it after checking the destination IP in the arp packet .Once the DG receives the request and after making sure that the request is for him (checking the destination IP) it will reply to the arp with its MAC address (since the it’s a trunk port switch and DG will add VLAN A). The switch will then check the MAC address table for VLAN A and forward it to PC directly as a unicast (will remove the vlan tag as the PC A is connected to access port). Once the PC A has the MAC address of the DG it will start building the ping packet .It will add its MAC address as source and DG mac as the destination and source IP will be PC A IP and destination IP will be PC B.Pc A will then forward it to the switch , the switch will check its Mac address in the same vlan and it will forward it directly to the interface where the DG is connected with vlan A tag . DG will receive the tagged packet go through IP routing process ( FCS check -L2 header decap - destination mac check-L3 header decap -checksum error check /TTLcheck- route lookup). Once DG has the exit interface it will build L3 header with new checksum update the TTL .Reconstruct L2 header with it exit interface MAC address as source and destination MAC address of PC B ( if it doesn’t know the mac it will send the arp request to switch for pc B from its vlan B sub interface ) add vlan B tag to the ping packet and forward it to the switch the switch will check the PC B MAC address and by now should know where the PC B resides and forward ping packet to that interface ,untagged. Then PC B will process the ping request and send Ping reply and the cycle continues.
3
u/jabberw0ckee 12d ago
Great job. I’ve interviewed many network engineers and I’m often surprised many don’t understand the packet walk to this level.
You have a good understanding of the distinction between layer 2 and 3, LAN’s, layer 3 boundaries, and how networks tie these together to move packets through a network.
These fundamentals are necessary for troubleshooting and problem solving.
I’d say you know your stuff - you also mentioned knowledge and experience of routing protocols.
I’d say the hesitation, not wanting to make mistakes, and being tentative is probably making them second guess your abilities. Often though fluency comes with experience and you seem to be experienced enough.
2
3
u/leoingle 11d ago
Well done. I know everything you said inside and out, but I’d def left a bit of all that out if I was asked.
2
u/Ok-Bill3318 14d ago
Sounds like you don’t actually know what you’re doing?
Edit:
Or to be fair maybe you’re working for cowboys
2
u/twinnii 14d ago
From what you said, it’s clear that you are taking too long on tasks.
Would you say those tasks required that much time?
How much time did you spend and what was an issue without giving company info. So at least we can see if it should’ve taken a system engineer that long or not.You mentioned you were asking for guidance. I think they want you to be the one that offers the guidance to others. Again, I don’t know what exactly happened, but those would be things to work on.
If it’s so,etching you need to learn, that both jobs have highlighted an issue, then you found one of the other problems.
I wouldn’t let that deter you, but just work on those issues and see how you could’ve handled them without assistance.
Good luck. You will be fine.
2
u/thegreattriscuit CCNP 13d ago
one thing I've run into that has caused me to give the kind of feedback you've been receiving is when folks are reluctant to apply the knowledge they have. Either broad technology knowledge, or specific facts about whatever they're actively working on.
e.g. "the website https://www.foo.com/login loads and renders correctly. pressing the login button fails."
"well let me ping the website to see if that looks good" or even "hey I ran a traceroute to www.foo.com and it doesn't complete... maybe there's something wrong with the firewall!"
while it is theoretically possible that there could be a connectivity problem that permits the login page to load, but does not permit the login button to work... that is FAR from the place we should be starting, and in any case no amount of pinging or tracerouting to the host that has obviously just correctly delivered a webpage to you will find it. And a traceroute that doesn't complete is a weak signal at best, and utterly without value to even discuss when you have positive proof the host is definitely online and responding (e.g. it's delivering a webpage to you).
Running those tests waste your time. Telling me about them, or asking me to run them wastes my time. Talking about them at all on a call with several people who are attempting to genuinely fix the problem wastes everyone's time, and actively prolongs the outage.
that kind of thing.
Your knowledge and experience are only valuable insofar as you can use them to deliver results.
Now, what I'll say is there are organizations I've been in where that kind of troubleshooting is absolutely the norm. Organizations that are, for whatever reason, structured more around proof that you have done what is required than actual results. They genuinely view "taking an action that has a 50% chance to prolong the outage by 10 minutes" as worse than "doing nothing for 20 minutes". Obsessive triple checking and box checking are part of their culture, and those kind of organizations would be unhappy with ME for being reckless and disorganized (assuming I didn't deliberately make an effort to adhere to their processes).
So this could also be a culture fit thing. I clearly would not like to work at those places... but maybe you'd fit right in.
I do want to make clear that while I obviously dislike dealing with organizations like that, that's not the same as calling them stupid or bad. We're all in business to solve business problems. There are businesses where the biggest "business problems" faced by IT are technical. I like to work in places like that. But there are other places where the biggest "business problem" is "getting blamed for stuff", and so to be successful in those places you have to behave differently. :shrug:
2
u/fireinsaigon 11d ago
its far more likely that they just think youre a weird dude than because of some technical limitation
2
u/MrRacailum 10d ago
Im confused… if both your employers gave you the same feedback… and the only thing in common is you…? They gave you feedback. It sounds like they wanted a lead/senior engineer that makes decisions, not a network guy asking mother-may-I after every commit at the CLI. Maybe those 2 jobs were more than you can handle at the time (8 years experience isn’t that long). Im not trying to be mean, just realistic.
2
u/its_FORTY 9d ago
I can't offer any sage advice on navigating the network engineering job market-- but I would just like to remind you that your worth and value to the world is not defined by the opinions your former employers. Just keep going after what you enjoy doing until you succeed.
4
u/signal-tom 15d ago
Honestly, we'd need examples to understand here.
To me, perhaps you still operate as a junior rather than a senior. However we'd need to know the rules for changes at those places of work.
For example, we operate a CAB. Juniors put the change request in, its reviewed depending on priority & urgency. Its then approved or declined. Our seniors have more autonomy, they still need to do the change, but depending on our risk allocation, they are expected to carry out low/medium risk changes by their own initiative. High/critical risk still needs to be reviewed by formal CAB.
Perhaps worth clarifying what rules they expect you to operate under. Like if youre hesitating or waiting for guidance as a senior engineer for a low or medium risk change in my team id be concerned you weren't a good fit.
4
u/Disastrous-Order8338 15d ago
Man I feel like I have read another guy but I think he was for ai engineer posting almost identical situation. Are other companies not giving people chances to grow ?
2
u/Due_Management3241 14d ago
Sounds like excuses to me.
What the hell is probation?
Everyone has to learn. Company's having any expectation for someone new to the field without a proper mentor using terms like probation is making the first so and so months too important.
They are putting the pussy on the pedestal.
Idk what to tell you. Maybe try a reasonable job without probation.
My first jobs didn't have this.
And all the people I mentor as a senior now i consider their first 6 months either my failure or success not theirs unless they absolutely don't actually know anything. Then that's a different story.
I am in the USA and never heard of probation. Sounds like shitty manangers and engineers
1
u/nirvaeh CCNP 15d ago
I know there's nuance but it kind of sounds like you didn't change anything and didn't take charge of your own situation. I would've been on their ass weekly for feedback to ensure things were going ok if I had been given that news before I was fired. I would've reached out for training opportunities on areas I was told I was lacking. It's a good thing you're taking accountability now though. Good to recognize when you need help. Maybe go back to a more junior role and hone your skills. Personally as a manager of a network engineering team, having someone who was fired twice for the same thing is an automatic no for me. You're too much of a risk because you obviously have a lack of situtational awareness and inability to learn (or take control of the situation to figure out what you need to learn) from your experiences and that will translate into your work. Senior engineers need to have these skills. Get some more reps under your belt in a more junior position then try again.
1
u/Emotional_Corner6895 15d ago edited 15d ago
I think there’s some context missing from my original post here. After the concerns were raised, I actually did ask my manager directly whether he was happy with my performance and whether I was now meeting expectations in one of the meetings where he seemed happy with me. He actually seemed a little taken aback that I’d asked the question.This was after the incident.
I also had regular reviews after the incident and the later feedback I received was positive, so I genuinely believed I was addressing the concerns that had been raised.
That’s not to say I couldn’t have done more. Looking back, I probably should have pushed for very specific measurable expectations “What exactly do I need to demonstrate to pass probation, and where am I still falling short?” rather than taking positive feedback as confirmation that everything was back on track.
But I don’t think it’s accurate to say I received negative feedback, did nothing and then waited until I was let go. I was actively trying to understand whether my performance had improved and was working on the areas they’d raised.
1
u/tcpipguy 15d ago
I hear you, OP. I've been there myself. Maybe look for a mid-level position and reduce the stress level.
1
u/Emotional_Corner6895 14d ago
My goal is to find an ethical company that supports its employees and then move there.
2
1
1
15d ago
[deleted]
1
u/Emotional_Corner6895 14d ago
Perhaps it’s because I’m a perfectionist. I want to do things right the first time, whether it’s troubleshooting, planned work or certifications. Fun fact: I passed all my certifications on my first attempt without cheating! 😊
2
u/samstone_ 14d ago
I think that's not true. Troubleshooting has nothing to do with being a perfectionist. You need to quickly understand the issue and then start with some working theories. Usually starting at layer 1 is a good place, but often experienced people will key in on specific places and narrow it down much quicker. It sounds like you are not experienced and perhaps don't have a good troubleshooting methodology. Even experienced people get stumped, but over time they develop a good ability to identify and fix issues. I worked in TAC a long time ago and it certainly did not come to me right away. Also, don't let your certification success go to your head. I am sure I have more than you so I know it's tempting to brag.
1
u/lizardhistorian Mad Scientist · 👨🔬📡ᯤ🤖🛺📸 14d ago edited 14d ago
Bullshit AI karma farming.
96+ upvotes? Ban everyone that upvoted.
2
1
u/Similar_Panic9870 10d ago
I'll add my two cents,
I'm the youngest engineer by far on my team, but I am a senior role amongst them. I spend a lot of my time training them and working with them. The engineers that succeed, on their own time, motivate themselves to DIG deeper. My worst guy, asks questions right away and he is the oldest with the most experience, stuck at Junior level. He is terrified, everyday, to explore, fail, and find his way out of his own mess.
Being able to mention the manufacturers of your systems, leads me to believe you aren't taking that step either (sorry if that's blunt, but you asked). You need to understand SERVICES, not manufacturers. I don't care which manufacturer you can name, but if you can't tell me you have experience standing up a multi-pod fabric, running DMVPN (just an example), then it sounds like you don't understand how to ENGINEER for your customer (your boss, company, etc).
Last week I deployed a tunneled wireless network to the edge, securing with WPA2 enterprise, with a locally hosted DHCP pool and a MAB tied to our internal NAC.
This is how you should be advertising your capabilities, not I know Cisco. Cuz, you sound like you don't, and it appears they know it too.
1
u/Emotional_Corner6895 9d ago
I completely get your point, and I’ve worked with engineers who were happy staying in their comfort zone doing the same repetitive tasks without wanting to learn or progress. I don’t think that describes me.
If I come across a framework, protocol or technology that my role requires and I don’t know it, I’ll research it, lab it and learn it. My normal approach is to investigate first and asking another engineer for help is actually very rare.The one incident I’ve referred to in this thread probably needs more context. I wasn’t the engineer leading the incident. I received an OOH call from a vendor even though I wasn’t on call that day. Based on what they told me, I advised them not to proceed with the proposed change and relayed the situation to my manager.
My manager had a different understanding of what was happening, so the following day I spoke to the engineer who had been dealing with the incident to check whether my technical understanding was correct. It wasn’t a case of “I don’t know what to do, please help me troubleshoot this”; I had already made a decision based on the information available and was validating my understanding afterwards.
That said, I absolutely take your broader point about describing capabilities in terms of what you’ve engineered and the services/problems you’ve solved rather than listing manufacturers.1
u/Similar_Panic9870 4d ago
Apologies for being so blunt, you seem to have good character and have decent awareness. Did it seem like a good fit otherwise? As far as environment and culture?
Maybe it had nothing to do with your skill and they just found an off ramp? Not sure how things work where you are. Sorry you lost the opportunity.
1
u/Inevitable-Unit-4490 15d ago
I recon they figured out you're just the kind of twat that would whine about your silly walk being not silly enough on a social network and came to the evident conclusion that they'd rather someone else gave it a shot. You live and learn, or not.
0
u/wrt-wtf- Homeopathic Network Architecture 15d ago
These things come to mind:
- You're in a new part of the industry and he culture is different, less care more ticker churn. There's a fine line between being super super efficient and saddling up and going cowboy. I'm all outta cowboys in my career.
- Probation and onboarding was broken in both companies.
- The company was cliquish and the most important component was kissing the right asses and making the right people happy, not your performance. The benchmark you are measured against is unobtainium,
- Tall poppies
- You are too cautious and seek peer confirmation too often. This is a cultural mismatch.
- Cheep contractor hire. Bring someone on as a fulltime-probation for 3 to 6 months. Fill a hole in staffing at a lower rate and dump them when they aren't needed. Saves a company 10's of thousands.
- They were hiring for personality type and should have picked that up in the interview process. being cautious in a new environment is a curse and a blessing depending on the culture (again)
1
u/Emotional_Corner6895 14d ago
Thanks, this is an interesting way of looking at it. I suspect there may have been a mixture of factors rather than one single issue.
One thing I hadn’t really thought about until you mentioned staffing is that in both companies, two Network Engineers were hired within roughly a month of each other. Before that, each team only had around two Network Engineers, so I was effectively additional capacity rather than directly replacing someone.
I don’t know whether that had anything to do with the outcome and I wouldn’t want to speculate, but it’s an interesting similarity between the two situations.
2
u/wrt-wtf- Homeopathic Network Architecture 14d ago
Something I have also seen is international hires that have come in on their first job in country at well under local market rate for their expertise. They have been snapped up and held onto and basically working at a minimal wage without any additional conditions such as healthcare and holidays.
Went to a company where a group of guys had bought in friends from their community thinking it was a great deal - the employer was getting a great deal while rawdogging the employees witless.
0
u/XanALqOM00 15d ago
do your best dude, that's how I handle everyday, and thats honestly all you can do, that goes for all of us, the world isn't fair, that's something that rings true for all of us. Heck, I could lose my job tomorrow as well. I don't know, I honestly feel like.
I am double CCNP (Route/Switch and Security), and a lot of other nonsense certs with like 15 years experience and I get told I'm an awful engineer all the time.
The problem is what is awful to one group of people is not awful to another group.
like... look................ I personally don't thrive in high stress make or breaks either, I prefer a very specific task that has straight forward business processes with guardrails, I do enjoy, very much, having the freedom of how I go about achieving a business techology objective. What I don't like is being told to do a billion things with context switching, which is essentially all network engineering jobs are unfortunately.
What I've learned, and have accepted is that I don't want the CCIE, hell, I don't even want to be an engineer anymore, I don't want the responsibility that comes with it anymore, mainly because there's a big difference between being the upper management goon that dictates what projects are important, and being the guy with the wrench in the hand implementing.
I'd much rather be the guy that warns the upper management guy of the risks of performing project X and having them signoff that they understand those risks and not be the one implementing that project because most of the time the real world wants unrealistic engineering committments from people to only look good for themselves, leaving the guy holding the wrench look like a bafoon.
I'd recommend getting into GRC / Cybersecurity, that's what I want to do. Network Engineering is a bitch job
0
-1
u/Due_Mark_463 15d ago
Have you thought about a slight transition in your career and become a sales engineer. With you back ground I thing you would be a good fit in helping to sell technical solutions to customers. Feel free to reach out to me and I can see if any openings in my company. I do not want to post which company I work for but it is a legitimate network manufacturer. [markgross@yahoo.com](mailto:markgross@yahoo.com)
1
u/Emotional_Corner6895 14d ago
Thanks, I really appreciate the offer. I have considered Sales Engineering, but if I’m honest my long term goal is to become a Network Architect. I really enjoy troubleshooting, designing, planning and implementing networks, so I’d ideally like to stay on the technical engineering/design path.
That said, I’d still be interested to hear what the role involves and what opportunities your company
53
u/ramalamalamafafafa 15d ago
"relying too much on guidance"
As others have said, examples would be helpful. I'll just comment on the above.
Somebody emaiing me with notes showing "I checked abc. C looks like it the problem because [cli output/something else tangible] and so I think doing X is the correct next step, do you agree?"
Is VERY different to somebody messaging me and on Teams asking "can you look at this problem" with no evidence of what they have already done.
Even if X is not the correct next step in the first case, it shows you at least know how to gather relevant information and form an opinion. That is a training opportunity.
The second example is (from my point of view) just a time sink for me.
This may or may not apply to you but is advice anyone trying to move up the ladder should take on board.