Cisco

Internships were enjoyable because I got to work on small but interesting projects in an easygoing environment. That said, compensation is very much below average compared to other tech companies in Silicon Valley.

Work/life balance is good. Rarely is anyone ever expected to work more than 40 hours per week. This might depend on your group though.

They are making a good effort to update their offices in San Jose from the old cubicle farms to the newer open-floor setups with free amenities (coffee, tea, espresso, snacks, etc.).

They do not skimp on developer machines and peripherals like monitors, headphones, etc.

• Very bureaucratic, with lots of reorgs and movement at the middle and upper levels (e.g., new directors, mid-level managers, upper-level managers).

• The pay is below average in comparison to other tech companies in the Bay Area. Promotions/raises seem to be few and far between. It will soon be my third year here, and all of my developer peers have also complained about slow growth within the company.

• Due to the bureaucratic nature of the company, communication among the many groups is slow and sporadic.

• It may be different for other groups, but there seems to be a general lack of expertise when it comes to software development best practices:

  • Everything is hacked together
  • Quantity of features and speed of development > quality and stability
  • There are no design/architecture discussions that include all of the developers. ("Design" of the product usually happens as informal conversations between mid-to-senior level developers, without including the newer/entry-level developers). These discussions are ad-hoc, informal, and often not even documented.
  • No standards followed for releases/deployment
  • Very little effort spent on documentation of anything
  • We are one of the many groups that tries to follow Agile/Scrum, but since we don't follow a lot of technical practices that actually make Agile work (e.g., unit tests, code reviews, decent documentation, reasonably-sized & well-defined user stories, etc.), it isn't working as it should. The end result is shoddy code and constantly accumulating technical debt.

• People in non-technical roles (middle managers and product owners) push for features and user stories without really knowing what they want. User stories are often a terse title and an empty description (no behavioral/functional specifications, no summary, no consideration for inter-dependencies among other user stories).

• Projects often lack clear direction. This point applies to my group and our project, but I think it might apply to other groups as well. There are many technical leaders in our group, but for our project, we lack a TRUE lead technical architect who:

1. has a clear vision of what the product should be like
2. plans architecture & development tasks for the group
3. mentors less experienced developers
4. maintains standards on code quality and development processes

Bottom line: If you're looking for a place to hone your technical skills and grow as a developer, look elsewhere. Some of the other reviewers who mentioned a culture of complacency absolutely hit the nail on the head. I have observed first-hand many times where our group has accepted mediocre work or shortcuts without hesitation "if it gets the job done," creating more technical debt. When developers ask for time to address technical debt, we are rebuffed by managers who claim that it is "good enough" and that we should focus on pumping out more features. If you stay here too long, your skills as a software developer will only continue to rust.

Invest in your developers and encourage them to have high standards. Maintain those standards yourself, and don't ever let politics or pressure from above compromise the quality of your product.

For each project, appoint a true technical leader that everyone can follow, and encourage senior developers to mentor less experienced developers.

Cultivate a culture of software craftsmanship by respecting software development best practices. Raise the difficulty of the hiring bar; don't hire blindly based on a person's pedigree, and evaluate each candidate based on their skills today, not what they accomplished many years ago.

The companies that Cisco acquired are mostly successful ones with talented engineers and development processes that work (otherwise they wouldn't show up on Cisco's radar). We should be working more closely with them and learning from each other.