At a start-up? How do you manage live/work balance? Are there any on-call duties? Thanks in advance.

In my very personal experience, many times startups are not full of the brightest engineers, especially if they are based in a major tech hub such as the Bay Area: most talented engineers these days, if location is not an issue, first try a shot at FAANG or similarly big companies where they can experience problems at massive scale and very high compensation.

Hence, many folks who end up accepting to work at a startup are less talented engineers (you're left with the "scraps" of the market), so if you're a high performing individual you might find that you really don't need to put that many hours in to be effective, as compared to your peers (and that's deeply depressing as well, and one of the reasons why I left startups for FAANG, other than compensation; talent is SO SO SO much better).

I speak for direct experience, I rode a startup train for a long time at a company that grew a lot, and rarely put in more than 40 hours a week into the job, while others were routinely putting 60+. And I kept being praised by the management and technical leadership.

The problem (lack of local talent due to big company competition) became severe enough that we had to bootstrap multiple remote teams in easily overlooked areas because the new local hires (San Francisco) were literally trashing the product due to poor development/testing.

I hear conflicting ideas about who's getting the most capable people, and I don't know what's true.

Maybe a decade ago, a knowledgeable colleague, speaking of one of the better-regarded FAANGs, told me, "First they hired the A students, then they hired the B students, now they're hiring the C students."

More recently, the sentiment I heard among CS-ish PhD students at one big university was that FAANGs (or, at least, particular ones) aren't seen as the cool places to go anymore, and people would rather do their own startups, or get professorships.

Personally, I'd consider most of the FAANGs (but not one-sided hire-hazing rituals). But technical cofounder, or working on a startup that's already funded, or a rare research lab position, is seeming more likely to be a good match.

In my 10 year career, I've done 2 startups in the Bay Area (both early, one I left after Series A, another one I left after Series C) and more recently Google, and I can say the level of talent doesn't even compare in my opinion: from my experience, the engineers were so bad quality that I was feeling depressed and wasting my time most of the time (and constantly saying to myself "am I just a jerk in thinking of everyone else as doing bad work?").

Typical thing, that really happened: a coworker at a startup ("senior engineer") had to do some calls to a very simple HTTP API from an embedded C++ component. She proceeded to hand craft her own HTTP requests and manually dispatch them to a manually instantiated connection using sockets, and then manually parsing HTTP responses (!!). I suggested to not spend time on such irrelevant code, I was ignored. Management didn't chime in.

She kept having problems and problems once that 100s-lines long thing hit production, as you can imagine (every software engineer should know that writing a network client from scratch is not easy!): finally I broke down, linked libcurl in the application, and in 2 hours and 30 lines of code I had the whole thing solidly working. And that's how I afforded working 40 hours a week instead of 60.

At Google, this would never happen.

At a Startup, especially one that's "long in the teeth", the senior engineering team are those that have been there the longest and have the largest institutional knowledge.

"Why are there 4 unique keys on this table named masterkey, masterkey2, mk1, mk4?"

Principle Engineer. "Well, the masterkey indicates which key this was mastered on, if you check the masterkey db, which is just "id, timestamp, masterid", this is required to comprehensively log the creation date of the row to maintain the db's audibility in case of SOC audit.

masterkey2, refers to the masterkey2 db, which contains "id, timestamp". Any change to the row requires an update to masterkey2, again for auditbility for last modification reason.

mk1, contains "id, userid". Which is the user that created the row.

Finally, mk4 refers to the new mk4link table, which is a LinkTable that links the main table to the mk4update table. mk4update is 'mk4id, username, timestamp, creator' and contains a list of any changes to the table and a flag indicating this is the creation date. Have you done a SOC compliance report before? No? Well, all of this is mandated by the SOC compliance, its kind of ugly, but it works and is absolutely required."

I get it, you've been at some bad startups and choose to generalize that experience. I can assure you I've worked in some large successful companies with building after building full of the dumbest people you've ever met.

This situation is common in acquisition/acquihire scenarios. The critical people end up leaving because they have the skills to move on or the new leadership above them becomes grating, and many other people end up being left behind. This leaves a piece of software/sub-organization that's making money but can't take it much further than where it was left when these people moved on. It is possible to not end up in this kind of situation but in my experience this was the most common reason why there was a whole floor of people without skills or leadership somehow staying on as a zombie.

Some developers use work as an excuse to try something new (or to do something different). This was probably someone who thought a problem was easier than they imagined. Hubris comes hand in hand with experience (seniority?).

These kinds of initiatives happen all the time in every company, including Google. A team lead generally would quash this in the interest of reliability/safety/etc, I think.

Interestingly, I have had the opposite experience. In a legit startup, at least one that is pre-significant revenue, when you are still looking for "market fit" (aka bleeding money), you don't have the time to reinvent the wheel. Its more like "Please god let there be some reasonably workable library already built for this so I can focus on the important stuff!"

Bigger companies IME, tend to be the ones that can afford to reinvent the wheel, and also tend to have the ~~arrogance~~ size to feel that they are a special enough snowflake to eschew something off the shelf and build something custom tailored exactly to their needs. They also have big enough budgets to be able to spare the manpower on it.

My experience has been largely in the financial space, maybe that is the key difference.

That's some incredible anecdata. ;)

I've worked at _very_ large multi-nationals where, in my anecdata, I've seen such hand-tuned monstrosities deployed.

> At Google, this would never happen.

At a startup, a flawed but functional deployment today is better than a perfect deployment tomorrow. I've never heard of a startup that was successful because it got software right in it's early stages.

Sure, that's generally true, but in his example the developer actually spent significantly more time and effort on their bad implementation. It was the worst of both worlds, flawed and tomorrow, so to speak.

I've seen people do things like this more than once, even talented people. They some how get an idea in their head and go way down a rabbit hole without stepping back and realizing it's the wrong design. I think that pattern is more possible in small companies because they are less likely to have their work reviewed often, do formal design sessions, or be pairing with another experienced engineer. I don't buy that things like this don't happen at FAANGs because they are just oh-so-much-better, I would guess it's mostly because they have more mature practices.

Right.. at Google, you have immense numbers of people work on entirely useless products that get canceled a year later.

I shouldn't reply, but oh well:

> people work on entirely useless products that get canceled a year later.

You just described 99% of startups :-)

I've worked at both (Google from 09-14, technical cofounder in 07-08 and again from 14-present, and also a financial software startup from 05-07) and my perception is that the kinds of problems you work on are very different.

At Google you do rigorous engineering, you're intensely data-driven, you have to work at massive scale, everything you touch is a distributed system (with all the skills and pitfalls that comes with working on that), and you'll often learn a lot of fundamental CS algorithms because you need to re-implement them to work across 1000s of machines rather than using a standard library built for a single address space.

As a founder, it's just one problem after another, rapid fire, and you might have 1-2 days to solve something that took 2 months at Google. You do a lot of hacky 80/20 solutions. You need to think big-picture on everything and understand how everything fits together. You solve a much wider variety of problems, but you don't really go into depth with anything. Rigorous engineering isn't really part of a founder's job description, and some people view that as being dumb or poorly trained, but you make up for that in speed, ambiguity, and breadth.

I'd say that when I joined Google in '09, the level of colleagues there was much higher than the general level of technical founder prowess in the Valley, and it remained that way for the whole time I was there. But the types of employees Google hired in '13 were very different from the types of employees hired in '09 (who themselves were very different from those hired in '02), and it wouldn't surprise me if starting in '15 or so the balance started shifting back towards startup founders. Honestly I think the best technical minds today are actually doing cryptocurrency "non-profits" (scare quotes because they're actually being paid by capital appreciation of their founder tokens) - I've been quite impressed by the algorithms being discovered by projects like Ethereum, OmiseGo, MakerDao, zCash, Monero, etc.

I've personally cut Google's interview process short several times now; I get far enough to seriously reconsider, and tell them I'm not interested.

> As a founder, it's just one problem after another, rapid fire, and you might have 1-2 days to solve something that took 2 months at Google. You do a lot of hacky 80/20 solutions. You need to think big-picture on everything and understand how everything fits together. You solve a much wider variety of problems, but you don't really go into depth with anything. Rigorous engineering isn't really part of a founder's job description, and some people view that as being dumb or poorly trained, but you make up for that in speed, ambiguity, and breadth.

This is why. While I sometimes yearn for a little more rigour, I certainly do not miss change reviews taking weeks and months at a time, and projects languishing while we attend endless meetings which seem designed to _undermine_ consensus rather than build it. I find the glacial process of large corporations to be utterly frustrating.

That's probably because you were talking to " CS-ish PhD students".

First of all, they're looking to validate the choice they made in lieu of becoming a millionaire. It helps them sleep at night to think Google or whatever isn't cool (maybe it isn't).

Second, they're interested and driven by different things.

Every single good/great practical software engineer I know from college is working at FAANG or a unicorn.

Good point: that sample was of people who chose to go to PhD programs rather than to (or stay in) a lucrative FAANG engineering position, so maybe not representative of people considering engineering tracks.

Interesting... i'm in a similar space where I found a decent startup, grinded for a year or two... and have pretty much been riding a gravy train ever since. In the midwest, making 100k in my late 20s and going full time remote soon. we got bought up by some corporate shmos as well so got a pretty penny in stock options

It's a startup, yes.

I work eight hours a day on average, and being that we have staff on most continents we don't really have a need to be on call. That said, I've had a handful of 3am emergencies over the course of the last few years.

I work in my garage; so I have no commute, and I no longer lose over two hours a day to commuting. That's meant I contribute far less to open source, which I did while on transit. However, I don't miss commuting at all and am thankful for the time recovered.

Balance is blissful. While my wife was on maternity leave for twelve months our girls were at home as well, and so my breaks consisted of spending time with my family. Now I walk them to daycare before work and listen to the rain on my roof while I work.

Thank you for your reply. This gives me more food for thought.

I am lead engineer at a start-up and my goal is to create a good work environment for our current and future devs. #1 enemy is the on-call, which should be resolved with customer support + some automation.

FWIW, we're a reasonably successful social application that's _heavy_ on real time networking; so there's always a large number of users active and our services are generally humming along at high throughput.

Lots of automated tests. A good community team. Code reviews. A _rigid_ feature-branch-and-test process. A _rigid_ closed beta->open beta->release process.

And we still have bugs. But things don't catch fire often, and when they do, it's usually not our fault. ;)

Sounds like what we want to achieve. Good to know it works for others.

One more question if you don't mind.

What is your vacation policy? Fixed amount + required to take or unlimited + take what you need? I am not a big fan of the latter, but not sure how it works for others.

Thanks.

AFAICT, unlimited. I just ask and they always say yes. Last year I took around 4 weeks of vacation _as well as_ 5 weeks of paternity leave.

I think it helps that they've never taken issue with my general performance; if I weren't satisfactory in my output then I probably would have some push back.

Eng at my startup (I'm a founder) can work a straight 40-45 hours per week, which translates into probably about 30h/week of heads-down coding, and be highly appreciated.

We rotate on-call duties, but seriously, if you're fighting fires all the time, it's because you're bad at computers. Get some discipline about writing code that doesn't blow up constantly, get good at blue-green deploys, do code review, run post-mortems, etc. Basically, exercise some professionalism.

We definitely have fires, but it's not a weekly event. Or monthly.

Now, not every company is going to be professional, but as a software engineer in this market, where you work is your choice. You can work at a startup building comparatively boring software (like mine!) that sells to enterprises, for founders who don't work 80 hour weeks, and have a good working environment. Or you can not. But now, perhaps more than any other time ever, the choice is yours.

Adding to the other responses here; in my experience many engineers at startups get sucked into the mindset of aggressive sprints and crunch time. This manifests as a failure to properly estimate project time. If you are working remote, managing your own hours, and properly estimating your tickets then there is no reason you can't have a very reasonable work/life balance.

There seems to be some kind of understanding that start-up means aways working overtime etc. AFAIK that is not often the case, but people can work quite normally in early-stage companies as well. And mostly it is the founders who are working hard and employees are not required to work the same way.

I've worked at mostly startups and I have had a normal work schedule except for maybe 1-2 days a year.

Yes, I agree. We have (trying to have) a similar culture. The overtime is not expected, but the problem is task/context switching, which got better (less).

I've worked at a startup that mandated no developers worked outside core hours (unless responding to an on-call issue, we all took turns on call).

It worked fine. The founders were fairly enlightened people, and well aware that we were in this for the long haul - success would take time and nobody could work long hours without the quality of the work suffering.

This wasn't the case for all staff, mind. There were definitely people in some roles who worked longer hours. Marketing and PR mostly.

Thanks, there is hope then! Something similar I see at my current work place. I always try to send the message it's a marathon and not a constant sprint.