Verizon

1. Huge amount of holidays.
2. Good behavior of people (mostly).
3. Opportunity to learn the business of the telecom domain, which might be helpful in the future.
4. Very clear hierarchy, and you can reach anyone with a call or email.

1. Very chaotic environment, too many dependencies.

2. Everyone is involved in everything, and no one knows what to do exactly. That is why they spend most of their time fixing bugs.

3. Obsolete technologies. For .NET projects, they still use VS 2008 (can you believe it?). Even Microsoft has stopped supporting it.

4. Very old methodology and a long SDLC cycle, so the process is ultimately slow.

5. Nothing to learn technically (at least in wireline). Even good managers cannot help there.

6. Work-life balance for most of them sucks (again, wireline). I have seen people working for 13-14 hours daily, even on weekends, for a continuous six months and counting. Most people stay just because everyone else is staying; leaving early will make a bad impression.

7. Nothing extra if you work night shift for a regular project or extra hours (night shift allowance only for those who work daily).

8. They do not even know the meaning of resource management.

9. You will die but not get a response on mail or chat, even if something is important from other teams or sometimes from team members sitting in other locations.

10. No one will give fruitful training about the project when someone joins.

One most important thing I missed is that the coding standard is just pathetic. Actually, they do not follow any standard; they just write the code, with no description, no comments, and no code reviews. They keep on adding the same code just to avoid changing someone else's code.

Verizon is a mixture of service and product-based companies, and thus it is actually like a RAITA. They will advertise with their revenue and compare the salary with TCS and Infosys.

These all cons apply mostly for Wireline teams. Wireless is going well, so it might not be the case.

Start doing some quality coding so as to spend less time on bug fixing and use the resources wisely.