That is the room where all of the eng team worked, but certainly not how it looked on a normal day. If you look, you can spot three clusters of 4 desks around the edges of the room in this picture. There were ~10 clusters of similar size that scattered around a large open space.
The worst part about that room was not the open feeling, but rather the silver walls and ceiling
Sometime around 8-10 years ago, requiring company approval for secondary sales started becoming a popular restriction to put into ISO grants (prior to that, it was just right of first refusal on sales). It's largely unfavorable to employees, but it does prevent some pretty bad situations. The benefits of this restriction were explained to me as two major things:
1) By preventing secondary sales, the company can control the going price for the stock. This means when the company has an independent third party do a 409a valuation, they don't have to take into account high third party sales, which would push the 409a up. Not inflating the 409a is beneficial to employees that want to leave the company and exercise stock. It means their AMT tax hits won't be as bad.
2) It also means the company/board get to control who are investors in the company, and thus who has the ability to request to relevant internal company information (like financials).
Both of these points increase the power of the insiders over the power of all shareholders. It's very anti capitalistic, and I stand by calling these rules dirty.
Company is not supposed to control its share price. Company is supposed to be subjected to its shareholders.
I previously worked at Stripe. Mark's post mirrors my experience internally as a hiring manager, and as a candidate. But as you said, at scale things get harder; I'm sure the experience does vary and some percentage of people come out with experiences that don't match the ideal.
My own experience was that Stripe was able to take me from a prospect to a hire in less than 30 days. My interviews and calls were all on Friday, and I would hear back on Monday with results and schedule the next round for that very same week.
I work at a far larger company that scaled from a smaller company.
Most people do not show up to interviews late and the process is a 1hr phone screen + 1 day onsite + 30m decision meeting. From start to end, if the candidate was available, took about 1 week. That part is not a scaling issue, but a cultural issue where it's OK to be late or flake on interviews.
Given I had a job while interviewing, I was driving it as fast as I was comfortable. But the part that was important to me as a candidate is that I was getting feedback within 1 business day, and getting the next step scheduled for later that same week.
My last 2 jobs have been working on developer productivity for 100+ developer organizations. One is a monorepo, one is not. Neither really seems to result in less work, or a better experience. But I've found that your choice just dictates what type of problems you have to solve.
Monorepos are going to be mostly challenges around scaling the org in a single repo.
Polyrepos are going to be mostly challenges with coordination.
But the absolute worst thing to do is not commit to a course of action and have to solve both sets of challenges (eg: having one pretty big repo with 80% of your code, and then the other 20% in a series of smaller repos)
Jesus, this. Look, you're going to run into issues either way, because you're trying to solve a difficult problem.
It's like thinking OOP or functional programming is going to solve all your issues... I mean, in some limited cases they could, but realistically you're just smooshing the difficulties around and hopefully moving them to somewhere where you are more able to deal with them.
FWIW, I've worked in a many-repo org and it sucked worse than huge companies with monorepos and good tooling, but I'm not going to make some blanket statement because it depends on the specifics of your code/release process/developer familiarity etc.
Sounds reasonable. I'll have to add, though, that the underlying technology factors into this as well.
For example: If you're stuck with a TFS monorepo (you poor soul), you actually get to deal with both problems to some extent, since TFS doesn't enforce that you check out the intire repository at once.
This can have very "funny" situations because someone forgot to checkout new changes in some folder. OTOH, at least for releases, you can remedy this by using CI everywhere.
I was chatting with one of the developers on this project this morning and seeing how we could integrate it into one of our projects. He mentioned that a simple js bundle version is coming soon so that you can just include it and start playing without having to worry about npm.
If you have a car, or don't mind jumping on Caltrain for the ride down, you can go to Mountain View to the Computer History Museum: http://www.computerhistory.org/
I was there for a day and when the museum was about to close I realized I hadn't properly experienced the half of it and came back the next day to spend another day there. Hands down the best museum I've ever seen.
Among the things there are original Google servers, Apollo computers, Apple I, Lisa and a hundred more things I can barely remember that make me want to visit it for another two days just to refresh my memory.
So interesting that this comes up today. We were discussing this yesterday in relation to an upcoming project where we want to maintain some amount of data for visitors to a website, but don't necessarily need to retain data for the visitors that we see very few times.
A couple years ago at a company hackathon, I took this approach, and then just baked these same tools into the app directly.
Django middleware to turn on/off and collect & store the profile data, and then a developer interface to read the stored profiles and render in SVG using pydot.
First off. You can learn on anything, so get whatever guitar you feel most comfortable playing (comfortable playing is the utmost requirement here). You absolutely have to go to guitar stores and have the guitar in your hands and in your lap. If you can't play, make sure to take a friend that can, as they'll be able to tell you if the guitar is "meh" or not.
Spend as much as you comfortably can, but don't kill your bank account. If you can, $500-$1000 is a good range and you have lots of good-quality options in both electric and acoustic.
I'm totally biased on the electric/acoustic debate. I've played almost exclusively acoustic for 20 years, and obviously prefer them. So from here, I'll dive into acoustic specific stuff if you decide to go that way.
Size/Nut Considerations:
Two important things to pay attention to are the body shape/size (Dreadnaught/OM/000/00/ etc), and the width of the fingerboard at the nut. These are just some huge generalizations, but if you play a lot of fingerstyle, a OM/000 with a 1 3/4" nut may be what you're looking for. Whereas if you like playing bluegrass, you'd probably like a Dreadnaught with a 1 11/16" nut.
Woods:
In addition, pay attention to woods the guitar is made of. Spruce and Cedar are going to probably be the two most common top woods, and Rosewood and Mahogany are going to be the most common back woods. Make sure to play combinations of these woods and figure out what you like. Most importantly, if you are paying more than $500 for a guitar, make sure that the top, back, and sides of the guitar are made of solid wood (no HPL, carbon fibre, laminates, plastic, etc.) If you are spending less than 500, make sure you at least get a solid top on the guitar.
Suggestions:
In the 500-1000 range check out Loar, Recording King, Blueridge and Larrivee guitars. I've also heard good things about the Epiphone Masterbilt guitars. Some specific models to check out: Loar LH-250, Blueridge BR-140 (or BR-160), Recording King RD-310, Larrivee OM-03, Martin MMV (if you can find one), Martin 000-15 (or 00-15 or OM-15 or D-15),
In the 1000-2000 range Martin 18-series, Taylor 300 and 400 series, and Larrivee 5-series guitars are great choices. Some specific models to check out: Taylor 312/314, Martin OM-16GT. Martin OM-18 (or D-18)
The worst part about that room was not the open feeling, but rather the silver walls and ceiling