lethain

Sorry, I think that sentence was a bit unclear. What it meant to convey is that we had 200 daily active Facebook uniques, essentially that very few folks used FB to connect to Digg.

Thanks for the suggestion, we’re adding a clarifying note to the report’s timeline.

(Stripe infra lead here)

This was a focus in our after-action review. The nodes responded as healthy to active checks, while silently dropping updates on their replication lag, together this created the impression of a healthy node. The missing bit was verifying the absence of lag updates. (Which we have now.)

It's fun to see that deck since my first (software) job out college was working with that team (about a year after this slide), when only two of those four mentioned individuals remained on the team, but consequently I got the pretty rare/fun opportunity to write Erlang.

We had a major advantage for new technology rollout as we did "devops" (e.g. the ops team decided they did not have bandwidth to support us and we needed to launch), and were building greenfield technology (Y! BOSS) with relatively few integration points with existing Y! technology (except for Vespa which is similar to SOLR/ElasticSearch and some weird C++ libraries that were somehow mislabeled from "junky prototype" to "high technology" and were ported forward).

Years later, my sense is that the biggest initial stumbling block was getting the existing devs to have any interest in learning a new technology / way of doing things. I think we lacked some perspective there, and should have made a much larger effort to get the team excited and trained with the technology (in jobs since, I've never had a team who turns down technology training), and could have probably won our local team over if we'd been more intentional.

Ultimately though, the final stumbling block was Y! itself, which was very focused on keeping the number/diversity of technologies low. I think at the organizational level this is probably the right decision, so I can't really fault them for that. Ironically Node.js popped up just a year or so later as the great language hope to rescue Y!, and did manage to get significant traction, so if you wanted to study adoption, finding someone who could explain how they got Y!'s Node.js adoption going in the right direction would be pretty fascination.

As a hiring manager in SF, my anecdotal experience is that most large companies are still hiring at the same pace they were a year ago, but that capital and subsequently hiring has dried up for smaller companies.

For experienced developers/managers, things seem to be business as usual, but in particular the "top tier" companies generally are more focused on avoiding false positives than in reducing false negatives, so I see us as entering a slightly unpleasant period for non-traditional and entry-level candidates.

I think many and perhaps most poor estimates are caused by initial estimates being viewed as too high for the project, and instead of deciding the project isn't worth doing at its estimated cost, instead deciding the estimates must be wrong in order to align expected project value with expected project cost.

Perhaps in a twisted future where we estimate project cost before deciding which projects to take on, we might discover our estimates are much better.

A related pathology is trading technical debt for speed, every time, on every project. The debt will be paid.

Generally the advice is to breakout GPA by major courses and overall (e.g. 4.0 GPA in major, 3.43 overall).

I'm occasionally a hiring manager for engineers, and yes, it's very possible to get a job without a tech degree. Tech interviewing usually has four major steps: 1) sourcing candidates, 2) filtering resume candidates, 3) technical phone screen, 4) in-person interview.

For most companies, having a degree only matters in the first two phases, and ability/interviewability matters in the last two.

Experienced engineers avoid getting filtered out in the first two phases by working through their network, which allows them to skip those phases entirely. If you're trying to break in without any experience, it's much harder because you probably don't have a network and degrees are often used as a filter during candidate discovery and resume filtering (especially when the engineering manager is working with a recruiter).

My thought would be to proactively send your resume directly to a bunch of job postings, especially ones which go to a "jobs@$company.com". Anecdotally, I know I don't get many direct resumes these days, so I'd end up reading them, skipping any explicit filtering.

Starting up can be remarkably hard. As training for that process, I'd look at your current work situation as a test. There isn't an easy way to move up and the work is dull, but if you're looking to lead a new company or join a foundling company, you'll want to hone your skills at owning issues and solving them (did your entire ops team just quit? yes they did. Is your site crashing under load and you're the only one who is going to fix it? yes it is, and yes you are).

My advice: look at your current work situation and find a way to make it more interesting and work your situation to move up. It'll probably be hard, but learning to focus on overcoming problems rather than focusing on the obstacle is fundamental to being people successful when you're managing yourself. This is especially true for startups.