- Poor engineering practices. Even though it's a database company, most of the software is poor quality, buggy, feels rushed, poorly tested and inadequately architected. No code comments, no developer documentation, no agreement on code formatting and poor code-review culture. Expect to find an entire zoo of different programming languages and technologies added in random places for no reason. I'm not talking about legacy code, I'm talking about new code being written today, these are their current practices, it's not like a startup has existed for a long time... As a result, you predictably get constant firefighting on customer issues which detract from engineering being able to move forward, rinse and repeat. The end product is only really suitable for a very niche market where an unreliable database is somehow ok with a few high paying government customers.
- CI/build broken all the time. Race conditions in the build system etc. Instead of investigating root causes/fixing they just want to put it in a container and expect it'll magically fix itself somehow. Same reasoning applied to other things too, such as source control/code review ie they think you can just pour some money and buy github/bitbucket and it'll magically solve bad code review culture somehow. Each person in the company builds the software with their own personal scripts, in a different way than what's done in CI. If you try to fix anything you'll be labelled as a troublemaker, they have it how they like it.
- No/ineffective planning. Runaway projects which were originally planned to take weeks are still ongoing over a year afterwards. Other projects start randomly and are interrupted as the CEO mood changes. Projects flying under the radar actually get to continue so you're encouraged to be secretive about what you're working on. Random people assigned to random projects with no team structure or skill match, non-existent new-hire onboarding etc. Complete lack of planning doesn't make you agile... I have worked on multiple startups at a varying level of maturity but never experienced utter chaos like this.
- You'll be asked to work evenings and weekends, promised to be compensated in exchange and then just get the basic bonus you were entitled to anyway. I had salary adjustment negotiations which were then just forgotten about. I changed manager 3 times in less than a year.
- Favoritism and politics centered on Palo Alto headquarters. A few employees in the boys club get to write all cool new features, and they rush to do it quickly (and poorly) so no-one else is involved in planning or design initially. Teamwork is seen as a distraction and you're bothering by asking questions. Then inevitably the ship starts sinking and the entire company has to be pulled into the project in panic, to work on fixing their bugs for months afterwards. Impressive bug-to-person ratio. All important conversations around requirements and design decisions are done face-to-face in Palo Alto so no written trace/visibility of it is persisted on wiki/slack and no opportunity for feedback from people in other offices. If you're not in the Palo Alto office, then they'll just offload stuff that is either boring or low impact/importance to you.
- Negativity. Don't touch this, don't change that. You'll be told no, repeatedly. They'll tell you what not to do, constantly, and in a condescending/patronising way. You'll get asked to do things you already did, because they underestimate/distrust you so much. They'll downplay your effort and your achievements. You'll be treated like a junior/intern/offshore contractor, regardless of your passion, ability, interest, skills or experience. I had extremely long discussions spanning multiple days with some engineers entirely in disbelief/lack of trust on what I had accomplished until they try things for themselves, retrace your steps and find out oh you were right! Huge waste of time for the company.
