> Background: this is my first job out of college, and I joined the startup ~9 months ago, right when they launched (I'm engineer #2, before me, the founders ou

> Background: this is my first job out of college, and I joined the startup ~9 months ago, right when they launched (I'm engineer #2, before me, the founders outsourced the prototype to an offshore team). Generally, but never as a rule, purely non-technical founders and an outsourcing is a red flag. But again, that is never a rule, and there are plenty of good companies started by non-technical founders that later matured. Still, that does leave you with the question, of how they chose the CTO? > Right now, we have ~1200 registered user, with about 100 active users, and we gained about ~100 users/month. This is not a useful metric. How does this translate into revenue: for some kind of business software (e.g., optimization/recommendations for retailers provided as a service and based on subscription fees) this is great, for a destination site that is poor. Is this rate increasing or increasing? Now to the meat of your argument: "waterfall" -- why do you call it water fall? 1 hour standups _are_ a problem, but I could imagine a scenario where this might occur for a few days in a row (although never beyond that). "Deployment update every 4-5 weeks" -- depends on what goes into the update, although it's hard to imagine this being a normal stable-state rate for an early stage (or any Internet/SaaS) company; yet for a company providing something like a database a service, it could be fine (provided you're able to push quick fixes and UI updates faster). "I tried to write some unit tests, and I was asked to remove them" -- could be several things, the you wrote tests were not very good (or were not proper unit tests, e.g., if running these tests requires additional setup beyond what it takes to build and manually test the product, they're not really unit tests), or reluctance to embrace even minimal unit testing (which is, indeed, a red flag). Non-issues: "technology stack and job description" -- honestly I would worry less about this, unless they're literally using Perl CGI scripts, Java 1.4 and EJB 2.0 on an ancient version of a commercial database, but e.g., using Java (or even PHP) and a standard SQL database is a fairly sound (if boring) technical decision. My suggestion is this: find a position in a company known to be functional and well regarded as far as engineering goes (to paraphrase tlb, you need to work with people smarter than you that can give you quick feedback so that you will learn!). Then you'll learn what a proper standup meeting is like, how to write good unit tests, what a release cycle is like, etc... Don't worry about what your equity percentage is, what your employee number is, etc... you have plenty of time in your career for that. The result is that you'll have a good baseline to compare to and (as a result of shipping something that ends up being successful and used by others) greater confidence/ability to introduce change in a company. Andy Rachleff of Wealthfront has some advise along these lines too, although not oriented towards engineering: https://blog.wealthfront.com/hot-mid-size-silicon-valley-companies/ https://blog.wealthfront.com/hot-mid-size-silicon-valley-com...