jeffchao
Joined 3 years ago
Karma
20
Submissions
19
Member since
Feb 8
Recent submissions
Comment · 1 year ago
Comment · 1 year ago
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.
What you'll be doing:
- Shipping highly-scalable, customer-facing infrastructure end-to-end
- 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.
Comment · 2 years ago
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!
Comment · 2 years ago
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.
Comment · 2 years ago
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!
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
+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.
Comment · 3 years ago
As a user and collaborator of TACOS, agreed that it could open up opportunities. Though I echo trade-offs (as in other replies) that it could start a civil war that makes it difficult for end users and collaborators -- reminds me of Python2 -> 3, Presto/Trino, and many other stories. Pledging resources is a great approach.
Interesting to see where this integrates and how it will boost streaming at Cloudflare.