Cisco taught me a lot but mostly about what I won’t accept in a workplace. Now I'm at the point where I'm looking and I’m interviewing companies just as hard as they’re interviewing me. Life’s too short to land somewhere that drains you just because you needed a job.
16 replies (most recent on top)
TL;DR
Its because of decades of VP/SrDIR/DIR parasites hiring and promoting wrong people and putting blame on existing employees saying people didn't have the skills.
When you realize that the "existing employees" were hired by the same "VP/SrDIR/DIR parasites" you'll understand how your statement disproves itself.
If you do you should used to this situation. And the higher your grade the less accountability you carry.
Asking because people need to talk about the root cause of this situation. Its because of decades of VP/SrDIR/DIR parasites hiring and promoting wrong people and putting blame on existing employees saying people didn't have the skills.
why? skill set outdated ? how did these people get in Cisco without skills? hiring people with no/wrong skills ?
Some junior high school to undergraduate level classes beyond Cisco's code bases with very tiny examples from far longer lists of problems:
Intro to programming: No programming skills in C (see the output of static analysis.) Basics like functional decomposition, refactoring, reducing coupling, increasing cohesion, etc... weren't part of the Cisco mindset. Multi-thousand line spaghetti functions riddled with gotos which didn't fully work after more than a decade of bug fixing were part of the Cisco mindset, something that some of us learned how to at least minimize in BASIC in high school using subroutines in the 1970s.
Intro to data structures: no data structure skills (look at all the system crashes due to the fact there was no way to delete elements of many data structures so they were put on side lists hoping that all the unlinking will magically happen before it's put back in use again.) It's the tip of the iceberg but at a month a pop to isolate many of theses bugs it adds up fast, particularly when each has to be found and fixed independently on a large number of branches. Since the damage is so deep they are often "resolved" by making stuff stay on the side list longer because a true fix requires rewriting far more code than Cisco will tolerate.
Intro to computational theory: endless scaling problems due to the facts that they both don't know the Pigeonhole principle and can't be taught, Cisco also created many examples of the halting problem. Why one would use an O(n) algorithm rather than an O(n to the 8th) algorithm for large data sets is another missing skill at Cisco.
Introduction to software engineering: I've never done true waterfall anywhere but the basic process which usually involved feedback loops even in Agile is having some idea WHAT one is trying to do (requirements,) an abstract idea of HOW one will do it (design) and from above the ability to IMPLEMENT that design (coding.) It's also the first course many will have where they have to work in teams which is hard to teach and many never grasp, seeking jobs where they can hide in a corner or WFH in isolation.
Hardware has far better raw skills but they've designed chips, boards and backplanes without sufficient requirements and sometimes all three had to go through at least one redesign cycle for each mistake made.
These are all rooted in knowledge people should have had before graduating college. Doing engineering in the large with an assortment of hardware and software teams requires many more layers of many different kinds of skills and experiences to know not only what will and won't work in the first release but how to look forward far enough to know how the system might evolve and to avoid early mistakes that could make it impossible to move forward without reworking the hardware and software at a cost sometimes greater than the initial development. Beyond this one needs a lot of domain knowledge in the business segments and one needs to communicate in all directions both inside and outside the company. The irony is these last skills which come naturally to great marketing and sales people elude most otherwise bright engineers.
How do they get hired? The same way people get into other companies. Friendships, unjustified awe of degrees, titles or previous employers, poor interviewer skills, etc... The reality is you rarely know if someone who looks good on paper is going to be a fit until they've had time to fully integrate.
How do they stay? Cisco isn't really doing much development so the lack of development skills doesn't really matter which is why Cisco doesn't have the short average tenure of 1-2 years like the top tech companies. Cisco's dashboard driven metrics reward many bad behaviors which is why you'll hear of people who were actually good but didn't play the games getting laid off.
"why? skill set outdated ? how did these people get in Cisco without skills? hiring people with no/wrong skills ? "
Are you really working for Cisco ? If you do you should used to this situation. And the higher your grade the less accountability you carry.
failed miserably because its people didn't have the skills
why? skill set outdated ? how did these people get in Cisco without skills? hiring people with no/wrong skills ?
what most people are really looking for - greenfield dev where you actually get to make some decisions...is long gone and is just the domain of weekend side projects now
Wanting greenfield and being able to do greenfield are two different things. Cisco has attempted a number of development efforts that failed miserably because its people didn't have the skills which is why Cisco has to keep acquiring.
That's a perfect approach, what you won't put up with. And don't settle for the first things. Cisco has paid healthy sums to be published in best places to work, with no real intention of developing, supporting or rewarding great people. The system that works is totally different than what FrannieMomma and HR team wants to tout.
If you are being promised new development you want to seek assurance that work is actually real. Most of the time it's a datasheet on what the company wishes it had done with the legacy death march you'll actually be ground into.
this is the most important point
most rewrite/greenfield dev is just daydreaming now...and if it does happen, as a recent hire, you'll just be typing on behalf of the old timer who got there before you and locked in their right to actually make decisions
what most people are really looking for - greenfield dev where you actually get to make some decisions...is long gone and is just the domain of weekend side projects now
Since everyone here including OP is hand waving, let's put a few ideas on the table:
- If you are being promised new development you want to seek assurance that work is actually real. Most of the time it's a datasheet on what the company wishes it had done with the legacy death march you'll actually be ground into.
- Really push people on how they learn and how that knowledge is shared with their teams. This isn't just program information and configuration management, it's learning in the far larger sense both inside and outside work.
- Determine if the company does effective postmortems. If you've taken on a real challenge no matter how good you are you'll have some sense at the end of ways the work could have been done better. People who don't think in these terms keep repeating the same mistakes.
- Get some insight as to how both worker bees and managers identify when things are going wrong and how they correct course. Too many companies that spout nonsense like "we only hire the top 10%" assume they know all that can be known and will never do this. No sane company would allow a one month performance improvement program to go on for years checking in far more fragile code which is 13 times slower than that which it was meant to improve, but Cisco did!
- Ask if you have responsibility for your work. If the company allows you to sc--w up then passes off the work of fixing it to other people you'll never learn to do better. I went back and checked on some of the most significant bits I did at Cisco and noticed after years there were no changes indicating the functionality, performance and reliability were sufficient that it didn't need to be reworked, but if it did I should be the one eating my own dog food and if the mistake had some subtlety that might trip up others I should share what I learned.
It's not about avoiding work, it's about doing work effectively. I've seen teams of merely "good" people do great things and I've seen teams of "great" people fail in unimaginable ways. Cisco rewards that unimaginable failure and after years and decades of this you'll only be employable by other failing legacy companies.
Let us know when you land a job in 2026
@bp Maybe if you don’t work in TAC, where everyone Cisco employee dumps you under the bus and barks at you like a dog, then sure it’s chill.
I’m trying to get out into a more chill position
than Cisco? if you want more chill than the most slack company in tech, I recommend bagging groceries
I’m trying to get out into a more chill position, pay cut be damned. So tired of dealing with Cisco employees than the customers who bought Cisco products themselves.
What do you plan to refuse to tolerate that you can determine in an interview?
Cisco is full of imposters who don’t care about the company and its value. “They” were brought up in a society of lies and that’s why “they” are great at it. Lie, lie, lie. Put them in a corner by themselves and see how quick “they” fold.