borramakot's comments

I've wondered for a while- are there heuristics on the income a steamer can make per viewer-hour?

Edit: I'd googled this before, but apparently I found the right way to ask: this site says from 1c to $1/hour/viewer. https://wallethacks.com/how-much-do-twitch-streamers-make/#:....

Depending on your definition of cheap, fab access might be pretty cheap right now for old technology nodes, which have totally reasonable performance if you have an architectural advantage.

This article suggests mask tapeout costs are under $1 million in older nodes, sometimes well under. If you have an architectural advantage in a problem domain with tens of millions or more in costs, a simple ASIC can be very worthwhile. That architectural advantage might be hard to find, especially when problem domains aren't fixed for long periods of time (e.g. how many ML accelerators only really work well for dense convolutions?), but I suspect too few companies are making custom chips, rather than too many.

https://www.electronicdesign.com/technologies/embedded-revol...

I don't know much about genomics, but I think there are at least FPGA based accelerators in production, for example, Illumina's DRAGEN.

https://www.illumina.com/products/by-type/informatics-produc...

I've done a startup, a couple of midsize companies (~4k engineers), and AWS. Just my 2c, a lot of the advice I'm seeing here applies more to the midsize companies than at least my corner of AWS.

In my Amazon experience:

* Some very high level project requirements would come from above (e.g. after this date, internal technology X is being deprecated, so you should have a really good reason to put out a project with X).

* Otherwise, decisions were mostly made at a low level, documented, debated with the wider team for an hour, then implemented. This was a little more structured than at the startup, but most of it was that documentation and debate happened before implementation, rather than after implementation at the startup.

* Project managers were somewhat active with the team, but a lot of the features we worked on came from the engineers watching what was used, forum requests, or customer requests through other channels (e.g. conferences).

* There was a focus on getting products out quickly, but tech debt/tests/reliability was a much bigger focus than anywhere else I've been.

* The team was fairly small, and encouraged to make heavy use of other team's internal tooling/native AWS tools for anything that didn't really need to be custom. Interactions with those teams was pretty straightforward and mostly supportive- "We're using your service to do Y, and would like to do Z too, but that doesn't seem possible without some tweaks to your API/service, is that something you can put in the backlog to investigate?"

* An individual team could be quick to change, but the organization as a whole has a lot of cultural momentum in the way things are done, and it's not clear who to talk to to make recommendations. For example, at the startup, I could go to the CEO and express concerns about the newly restrictive information security policy. At Amazon, I'm probably not going to email Jeff Bezos and suggest six-pagers be made available in advance of meetings.

* Transferring teams in Amazon is mostly extremely easy

* Conversely, Conway's law applies hard in AWS- it didn't seem straightforward to offer products or features that weren't obviously under one team's purview without forming a new team.

All the offer's I've gotten have been pretty solidly in the bell curve of what levels.fyi indicated.

Is this a criticism of the ARM chips, or of the TPU's bfloat format?

I've not read Popper directly, so I'd be interested in his actual argument on this.

But, I wonder if you can describe H1 as being a stronger hypothesis than H2 by virtue of withstanding more and higher quality attempts to disprove it?

I found the hash table lecture really interesting, somewhat practical, and it made me sound really smart when I got the inevitable hash table questions during interviews.

Is there data on what tech companies programmers (either generally or new grads) most want to work for? It feels like it used to be Google by a lot, but even outside the HN bubble, I get the sense Google has taken some reputation hit.

They say later that

> When a feedback instrument surveys eight colleagues about your business acumen, your score of 3.79 is far greater a distortion than if it simply surveyed one person about you—the 3.79 number is all noise, no signal.

Which implies to me that they believe there is signal there, but that it goes away when aggregated?

> Adding up all the inaccurate redness ratings—“gray,” “pretty gray,” “whitish gray,” “muddy brown,” and so on—and averaging them leads us further away both from learning anything reliable about the individuals’ personal experiences of the rose and from the actual truth of how red our rose really is.

I don't understand this comment. How does averaging noisy signal, even systematically noisy signal, result in something that is noisier than any individual signal? I would have assumed the average would converge on (real signal + systematic error).

Yeah, there was certainly a discontinuity when it went from "turn the tree into code" and "turn it into code in a faster language" to "build a virtual machine with random opcodes". I think it's just the nomenclature change that was jarring- characterising it as random switched dispatch was more intuitive.

How does a data provider prevent someone from copying the data from their S3 bucket into a new one, then cancelling the subscription and owning the data forever?

I get the sense that those numbers might include the value of stock increasing, but that's the only site that's had numbers within 10% of the offers I actually got after negotiation.

Reportedly, it's an insanely large (whole wafer) single chip. But, then, why is it listed with a size that's not commensurate with that?

Is that for S3, or EBS?

I like the idea of multiple tracks a lot, but I think you need to be hiring at sufficient scale that each track has a fairly high rate of interviews, which makes it hard to support tracks that aren't commonly chosen.

If you don't had that scale, uncommon tracks will be full of interviewers who are out of practice for your question, and poorly calibrated to evaluate the candidate.

Also, some companies might not want to allow any of these methods, since they each have their own tradeoffs/blind spots.

It wasn't literally a ban, but it was at least a serious impediment to their operating in the way they want to operate. The TX legislature overturned Austin's regulations with superseding, much more Uber/Lyft friendly regulations, and they are back now.

Strangely, the announcement that AWS is making their own machine learning inference chip got flagged and removed.

https://aws.amazon.com/machine-learning/inferentia/

That seems reasonable, but the compensation ranges I've been seeing aren't 0.9-1.1 x a reference salary, they seem to range from 0.3x (crappy consulting) -3x (HFT) the compensation of a mid-range FAANG position. With that kind of variation, it's very possible that compensation differences could overwhelm a normal sized difference in culture quality.