mkarazin

The platform team you describe sounds more like DevOps ("upgrades, CI + CD, ....").

The platform teams I've seen at scale are more focused on providing APIs and services for a business domain. Such as, you can have a platform team for KYC/KYB that develops integrations to document verification providers, and then have stream aligned teams that sit on top of that platform and use it in a product to onboard users. Or in payments, a platform team can manage all of the underlying banking integrations, and then a product team can use these APIs to develop a product that lets users pay for things online. I once managed a platform team that managed the internal ledger for a virtual wallet/venmo type company. There weren't many product features there, but they had to deal with scaling our transaction processing capacity, ensuring idempotency of money transfers, and providing an easy to use API for product teams to integrate with. For more academic/research minded software engineers, it's an awesome team to be on.

The engineering manager role doesn't appear to be on the website. Can you point me in the direction of a job description?

You probably are well aware, but security wise that's a huge issue. If it's a hobby app, okay, but anything with actual users should separate keys. The main concern would be that dev keys are not considered secure and anyone with access to the dev key could then impersonate any other user of the production application.

> I’ve found it a real struggle to get our team to adopt writing tests.

I find this hard to believe. Do others CTOs / team leads find this to be the case?

I've been a CTO of two small startups with 3-7 developers. We've had resistance to tests at some points (myself included). We've solved it fairly simply. All pull requests (PRs) require tests. PRs are rejected immediately without tests. If a PR doesn't have tests and it is critical to get in, we open a new ticket to track adding tests. It isn't fool proof, but it does result in a high degree of test coverage.

And once developers understand how and where to write tests, they usually see the benefit quickly and want to write more tests.

Article mentions the driver was hanging out in the sleeper cab. Long term them may be able to sleep or completely tune out in the back, but for now it was a stunt. I bet there were clear instructions on the driver's behavior. The article mentioned a "police cruiser in tow", but from pictures its not clear where or what function they played. For all we know, the police ensured no one came within 200ft in front or back, and the driver was told to take the wheel as soon as a car violated this zone. This is all hypothetical... but you can see how with coordinated effort they can set the scenario for safety.

Or you could stay in a shared AirBnB.

NYC is tough and expensive in many ways. Seems like they are trying to tackle affordable housing and consequently may also need to look at affordable hotel stays. I remember when I used to do field work in NYC, often for days at a time, and I would drive every day from Philadelphia, my home at the time. Awake at 4am and out the door to avoid getting stuck in traffic and then back down to Philadelphia at 7pm.

A good recruiting experience in my opinion indicates a well run business at many levels. It's a key differentiator, especially for lower level staff. Much akin to how someone treats wait staff, how recruiters and employees treat potential employees shows a lot about their character and organization. I'm somewhat suprised the simple requirements AirBnB uses (such as providing feedback promptly) are not more widespread.

How does this affect advertisements and click rates? Often times I am presented with two results which are correct - one promoted (ad) and one search result. If I click the promoted one I am contributing to the advertisement's click through metrics. If more people are using google as their navigation aid, is the ad value still as important? Could facebook or other top services be paying $$$ in advertisement fees simply because people don't want to add ".com" to their query?

Righting a project requires figuring out what the root of the problem is. A stakeholder demanding an unfeasible requirement may seem like the problem, but it could be deeper such as beaurocratic reasons or not having the tools / resources to pursue the right requirement. In the end you need to reset these issues to enable yourself to take a different path than the death march.

A recent project of mine was put on hold due to changing requirements and lack of focus. we waited for the client to bring the right people to the table. Then we redrafted all governing documents and got them reapproved, sometimes by new individuals. We made sure from the restart we had a feasible project with well defined goals.