HN user
Obligatory Michael Lewis quote, from Boomerang (2011):
Yet another hedge fund manager explained Icelandic banking to me this way: you have a dog, and I have a cat. We agree that each is worth a billion dollars. You sell me the dog for a billion, and I sell you the cat for a billion. Now we are no longer pet owners but Icelandic banks, with a billion dollars in new assets.
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’s the GTM role referenced a couple of times in the post?
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.
Along these lines, Square’s incident response meme lives on as https://outage.party/
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.
A point in time count isn’t a good denominator to understand cost per person given an annual budget.
This article sheds some light: https://missionlocal.org/2019/07/in-san-francisco-we-obsess-...
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.
Square | Software Engineer | San Francisco | Full Time. ONSITE. VISA.
On Seller Experience we're looking for senior engineers, and an engineering manager, to join our Onboard Platform and Onboard Experience teams.
Technical Lead - https://www.smartrecruiters.com/Square/102775838
Engineering Manager - https://www.smartrecruiters.com/Square/102364474
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.
Apply through the links above or reach out to me directly if you prefer (carden@squareup.com). Feel free to reach out about other engineering roles from https://squareup.com/careers/jobs?role=Engineering or product roles from https://squareup.com/careers/jobs?role=Product+Management as well.
Here is the most accessible implementation I've seen https://depts.washington.edu/aimgroup/proj/dollar/ with tons of references and existing implementations.
Square employee here. Looks like a phishing scam to me, thanks for sharing it.
I don't work on that stuff myself, but you can forward the email to spoof@squareup.com and we'll do whatever we can to take care of it.
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".
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.
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.
There are other places that have published them already. e.g. see Appendix B in this report http://www.sfcta.org/images/stories/Planning/Shuttles/Final_... from http://www.sfcta.org/content/view/584/1/
The logger, spawner and cloudant coffeescript files are in the lib folder: https://github.com/heroku/vulcan/tree/master/server/lib
When the app is created it sets NODE_PATH=lib so the app can find those files without specifying the full path: https://github.com/heroku/vulcan/blob/master/lib/vulcan/cli....
The node.js buildpack has good instructions for how to upgrade it yourself if needed: https://github.com/heroku/heroku-buildpack-nodejs (and the buildpack docs are now public since Heroku's Cedar stack became the official default)