That’s how I imagined it, kind of a hybrid of what I’ve seen called Product Marketing Manager and Product Analyst, but other replies and OpenAI job postings indicate maybe it’s a different role, more hands on building, getting from research to consumer product maybe?
What AWS services are you using currently and what drives your costs?
We’re a nonprofit with apps that see ~1000s of users a month, but mostly in the US. I think we see good savings using Google Cloud Run and scaling down when there’s less traffic. You could probably set up AWS Fargate similarly. Modern app frameworks start quickly so cold starts aren’t terrible. Docker containers are portable if you outgrow that kind of environment and want to shift to dedicated VMs or the other way to serverless in future. I would also look at fly.io.
Like you, “engineer’s engineer” was the phrase that came to mind for me too. Just really loved the craft, always happy to get into it and unpack a problem with you. Everything was tractable through code. So long as it was Java.
Like you, and hundreds of other Square engineers, I was asked to implement a circular buffer in my interview with him. I did it, not having the fortitude to decline, and I’m glad I did. I learned a thing or two, including that I would learn a hundred more things if I joined Square. What a great way to sell candidates.
I remember Bob kicking off the effort to get every Square engineer to come up with a pairing question and carry that culture forward when it no longer scaled for him and a handful of others to do it. I don’t think people thought it was reasonable. I do believe it worked!
I remember new folks asking earnest questions about why we had a monorepo and Bob replying that it was self-evident (a rare miss). But when I called him out on that he took the time to explain to me how it was all about being able to do global refactors across all our apps… something that only made sense when you were the kind of seasoned Java programmer who really wanted to refactor shared libraries on behalf of all teams at once. So glad he attracted more of you ;)
I remember working with Bob to update some of the Square visualizations that Mike Bostock of d3 fame had created. The “can do” attitude prevailed, even though Mike’s code was not documented, we were able to get it working and I believe we did truly novel work that day. Pretty sure (thanks Hindenburg) that code is still running.
I remember a lot of hiring bars, where not only was Bob responsible for scaling up the pair programming interviews, but he was actually really interested in the code people wrote, and in reviewing it with his colleagues. I later saw some flaws with that, but I’ve always respected the passion and the attention to detail.
As Cash scaled, before he left Square, I remember Bob went back into IC mode and was there, late nights and all, headphones on, cranking out the code. Pretty sure it was Minus the Bear on repeat for hours.
Last memory, I remember a surprising number of hugs and enthusiastic handshakes when things went well. Candidates closed. Features shipped. Fridays.
Just the raw exuberance. That’s why this hits so hard. RIP crazybob.
> the Department of Homelessness itself applies a multiplier of 2.89 to the PIT count to estimate how many individuals are homeless not just on one day but throughout the entire year.
The PIT number seems like the best single number to use. Unlike the one you quote, PIT is not influenced by the somewhate arbitrary choice of a year as a unit of measure. And even if you include people who are homeless for a single day over the entire year (who are, as the article mentions, also spending time in jail or the hospital, which get their own budget), the difference is less than 3x.
Square started with payments (the little reader that plugs into your phone) and now we do a whole lot more. Our team is focused on getting people signed up to Square, from account creation through identify verification, to discovery of the products and features that are a good fit for their business. There's a range of work: from highly polished front-end web development through highly available distributed systems and third-party vendor integrations. Interview process is a phone screen or two, then onsite, then offer.
The question is: what is your tolerance for (a) false negatives and (b) false positives?
Rephrasing (a): who are we passing on, are they in fact good potential employees, and what qualities do they have that our new hires might not?
Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why?
In my experience whiteboard coding sessions feel adversarial, like a trap or a test, and you're basically waiting for the candidate to have an epiphany moment. Either they know the problem, or they don't but they get lucky and hit the "right" answer.
Doing reviews of code samples (or even pair programming against a new problem) puts interviewer and candidate both on the same side of the problem and feels more collaborative - I want to believe this gets you a better sense of what someone would be like to work with, and fewer false positives and negatives.
If anyone has evidence or studies either way I'd love to read them.
in my experience, false positives in early ventures (research projects, startups, project partnerships, whatever) are the kiss of death. If you need a group of people to do work at high capacity, bringing someone who does not 'fit' in when the group is young will probably destroy it. existing high-capacity people will become angry, there is less fault tolerance in the quality of the work and the rate at which it has to be done, etc.
it is usually the case that it is better to have 2 workers who click and are highly productive than 5 workers where 1 is not productive. so in the early days, failing closed seems very valuable.
when you are larger, there could be a higher tolerance. you could afford to hire someone and fire them a few months later if they do not work out, because the work that they are doing for you immediately is not as critical. however, there is also a certain culture that comes along with this and if you want to avoid that culture it seems like you still want to 'think lean' and part of that thinking could be to keep the amount of productive people high.
and it might also not go well with your current group members to say "yes, that hire was bad and we'll terminate them next week" for the fifth, sixth time in a quarter ...
I agree this is the right question, but for the opposite argument. False positives in early stage ventures, in my experience, can be quickly and actively remedied. I've seen people fired less than two weeks after being hired without a substantial impact on the rest of the team or the product. If you can do this, you have a lot more freedom to take risks with new hires.
In a larger organization, if you hire someone, you're stuck with them in almost all cases. So be picky.
Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why?
Has someone suggested whiteboard proficiency is sufficient by itself?
The whiteboard is meant to filter out people who suck. "Add a cache to a JavaScript function" is a dumb question for reasons many others have pointed out. Joel's classic article[1] recommends these as examples:
• Write a function that determines if a string starts with an upper-case letter A-Z
• Write a function that determines the area of a circle given the radius
• Add up all the values in an array
Those are all trivial. You should be able to come up with another half-dozen if you sit and think for a bit. The language doesn't matter, and the syntax shouldn't matter (as compared to the semantics).
I hear lots of scare-stories of "great coders who choke on interviews," but I find it very hard to believe any kind of "great coder" can't add up the values in an array. I might ask "how do you find the median value in the array" just to see what they come up with. There isn't a right answer, but there are lots wrong answers.
Has someone suggested whiteboard proficiency is sufficient by itself?
Fair point, that is a straw man. I haven't experienced an all-whiteboard interview - there's always been more to it.
The whiteboard is meant to filter out people who suck.
I think that's what some interviewers have missed. They jump straight in at the deep end with difficult algorithmic puzzles, and don't ever do an easy one. I have experienced this.
They jump straight in at the deep end with difficult algorithmic puzzles, and don't ever do an easy one. I have experienced this
Yeah, I have hard algorithm questions I ask, but I don't open with them, and I know they are hard. I expect them to possibly fill the entire remaining time.
Also, for the hard question, it's not even about getting it "right": the one person I ever had get my hardest question right was flushed by other people in my process, and I've hired many people who never got close. I want to see how they try.
It is adversarial, because it's a gating mechanism.
Sure, I'll be happy to discuss deep issues with you - after you've shown me that you're proficient in basic CS. It used to be that you could screen that over the phone, but now that you can look up the answers on your phone, that's kind of hard :)
Assuming your whiteboard session is a good test of basic CS proficiency, the real question is "does basic CS proficiency correlate with effectiveness at the job?" - if you're like Google the answer is probably yes, and if so you only have to have tolerance for false negatives. Given enough applicants that's clearly less of a problem than false positives.
My other point is that some companies might find there are other qualities they're looking for that occur in the pool of people they pass on. That's what's really worth looking at, I think - all the while being careful not to mistake "good cultural fit" for "promotes long term monoculture".
I'm assuming in my answer that the interview happens at a shop that cares about CS proficiency. (Mine certainly does ;)
If I have a false positive (i.e. you seem to understand CS but don't fit the company), it's not like the CS question is all that's asked. It's the launch point for a deeper discussion. That means a false positive hopefully gets caught in that later stage, but deep CS knowledge is sine qua non.
If that skill (knowledge of CS) doesn't matter to your shop, then yes, you shouldn't use it for gating.
Anecdotal, but I interviewed for a position where they gave me a tab deliminated data set, and said, "Show us what you can do with this in X language". I had two days.
