Google | Software Engineer | ONSITE (3-days a week, San Francisco) | Full-time | $136-200K + bonus + equity + benefits
We're looking for a mid-level engineer with an interest in building highly-scalable, customer-facing infrastructure that loves getting things done. This is a high-impact role where you'll own deliverables across all layers of our stack.
We're local to SF, in-office 3 days a week and build foundational networking infrastructure for Cloud Run, Vertex AI, and more. We work across a broad range of use cases such as stateless services, scheduled services, and cost-efficient AI inferencing.
- Building efficient service-to-service communication models
- Improving network infrastructure that handles millions of requests packets per second
This role could be a great fit if you:
- Love getting things done
- Enjoy building robust and efficient infrastructure
- Are eager to own and deliver end-to-end
- Are curious and view challenges from multiple perspectives
- Enjoy collaborating and communicating with technical and non-technical partners
What gives you an edge:
- Strong communication skills and ability to collaborate cross-functionally
- Experience shipping distributed systems infrastructure
- Experience writing modern C++ and domain expertise in networking
Link to generic posting: https://goo.gle/40J4t0c but please reach out directly via jeffrey<my last name> [at] <my company name> dot com and mention in the subject you came from HN.
Accessibility and universal design may be another important factor. I’ve recall that usage of “click here” makes it harder for screen reader users to tell what link they are trying to click on. I haven’t caught up with the tech in awhile, but such a small change/effort on my part has been ingrained into my link making!
This is very impressive, though an adjacent question — does anyone know roughly how much time and compute cost it takes to train something like the 405B? I would imagine with all the compute Meta has that the moat is incredibly large in terms of being able to train multiple 405B-level morels and compete.
Interestingly that’s less energy than the mass energy equivalent of one gram of matter or roughly 5 seconds worth of the worlds average energy consumption (according to wolfram alpha). Still an absolute insane amount of energy, as in about 5 million dollars at household electricity rates. Absolutely wild how much compute goes into this.
Saw the description on the README which shows median, fair, but there's a lot of nuance such as whether or not it's a new offer, location, and level. As a consumer of this info I'd usually try to understand comp against those extra dimensions. That said, great simple table though!
The two usual quotes are paraphrased as “ideas are dime a dozen” and “execution is king”, but the thinking I don’t see very often is “what is your unique insight?” aka what’s the differentiatior (and why does it matter)?
You’ll get asked this by VCs as means to evaluate the likelihood of a big win, if doing a VC-backed business. You’ll also be asked this by customers because people simply want the best option that meets their requirements and situation.
Then, if you’re a founder, you’ll likely hear “no” constantly when trying sell your product. This could be energy-draining. Especially if you’re pre-product/market-fit, having that unique insight is a great tool to remind and motivate you that you should keep executing on your idea.
Cool! It looks like you effectively do auto instrumentation. Have you found there to be interesting nuances between LLM providers? Tracing is great and trace aggrgegates (with context!) cross-vendor would be even more awesome.
Wow, where do I start? The APIs are not that similar, but we're trying to use the same set of semantic conventions for everyone so for example you'll always get the model version, or the temperature in the same attribute. Which kinda means it's identical cross-vendor, at least on the o11y side.
Probably the ecosystem and documentation. PaaS like Render, Fly, and even Heroku from back in the day offer addons/plugins/whatever that make the obvious choice out to be Postgres/MySQL. Then there's other tooling such as migration and various ORM adapters. Then there's a wealth of blogs, stack overflow q&a's, etc. And then Postgres/MySQL gets you quite far. Start with a single node -> scale the node -> add read replicas -> shard. Then, sharding becomes painful? Start looking at other data stores, remodeling your data, or eventing, etc.
Otel is great for avoiding vendor lock-in and the spec stability is a long time coming — great to see. Also good there’s architecture options aside from side car (there’s also proxy mode), which is nice for situations like deploying on a PaaS.
That said the main trouble I’ve had in the past is instability in the SDKs. Java one’s decent. Go, not so much, for example. Traditionally Otel has been awesome for tracing but not so much logs, events, and even metrics (obviously depending on your language).
Other than that, auto-instrumentation has been nice. We had this exact functionality when I worked on observability at Netflix and made starting up and maintaining microservices easy and really helped with adoption.
+1. Stale PRs, also communicate and welcome feature requests or bug fixes that may exist across SO and other channels -- TF-scoped, but perhaps even HCL (if possible) or HCL-adjacent libraries.
Interesting to see where this integrates and how it will boost streaming at Cloudflare.