The "usual" process in big tech is a recruiter call, 1-2 technical screening calls (sometimes an EM call), then the main series of 3-6 domain knowledge interviews are done over 1-2 days.
The latter are pretty grueling, especially when conducted on-site. Apple recommends you show up 1-2 hours ahead so you have enough time to get through security, for example.
That might be fine if they are offering incredible pay and conditions at a highly desirable company. But you get so many mid tier companies looking at Apple and Google and replicating their process without the pay or reason to put up with that process.
I just eject from the interview process when I hear it's going to be so many rounds because I know there will be another company that's just as good that will get it done with less.
A different floating point hack makes exp() easier to compute in hardware (and consequently tanh). You cast the input to an int and take the first 2 bits of what would be the mantissa. LUT[Index] and LUT[Index+1] from your 5-entry table are used to either lerp or poly approx. the function, with the remaining mantissa bits to help.
I'm not sure how to square that with the very well-studied result that areas with higher income tend to have better schools. Students from lower income brackets also do better than their income peers at schools in less affluent areas. And because local property taxes are a major funding source for schools, those are also the schools I'd expect to spend more because they have more.
Michigan notably does not fund schools through homeowner property taxes. I suspect that's probably the difference here and a reason we shouldn't use it as a representative example.
Could it be that people with higher incomes are a lot more likely to actually care about their kids getting a good education, and to put pressure on the school to that effect?
> And because local property taxes are a major funding source for schools, those are also the schools I'd expect to spend more because they have more.
It depends on the state. In Texas, property taxes from wealthier districts are redirected to poorer districts to ensure more equitable funding (search for "texas robin hood").
The result is that most public schools are funded about the same regardless of where they're located.
It's the same fundamental problem as view counters, something Google is famously good at solving. Eventually consistent solutions are well-understood, and wouldn't have these kinds of massive cost-overruns.
It seems hard to believe that a one-hour delay on such a counter is impossible to achieve, and one hour would reduce the risk from "catastrophic" to "serious problem" in most cases.
Also, if implementing a cap is a desired feature that justifies trade-offs to be made, then it is psosible to translate the budget cap (in terms of money) back into service-specific caps that are easier to keep consistent. Such as "autoscale this set of VMs" and "my budget cap is $1000/hour", with the VM type being priced at $10/hour, translated to "autoscale to at most 100 instances". That would need dev work (i.e. this feature being considered important) and would not respect the budget cap in a cross-service way automatically, but still it is another piece in the puzzle.
Eh, suddenly turning off all services in your account because you hit your cap is just as much a DoS type event - just of your services, not your wallet.
So? Many would prefer a DoS-type event over spending $WHATEVER_THEIR_HARD_CAP_IS. This is kinda the definition of a hard cap, so you would place it sufficiently high that DoSing your system is indeed preferable.
Also, doing this on a per-service basis doesn't seem that far-fetched to me, so you'd only kill that service and get at least some chance that the rest of your system remains usable.
Yeah, there's an implicit assumption was reasonability.
But a big part of the value in large clouds like GCP is the network's interconnectedness. Plus even if there was some global event that made communications impossible only for the billing service, I'd still expect charges to top out roughly proportional to the number of partitions as they each independently exceed the threshold. GCP only has 120ish zones.
It's more a problem they are incentivized to have. Open Router allows fixed wallets and doesn't run into the same problem, since it would be their money on the line if they let a user overspend their limits.
You need electronics and computers for cost-effective compliance with emissions requirements. Emissions limits have been one of the most positive government policies in my lifetime, saving millions of QALYs.
There's lots of other electronics in most modern vehicles, but the public manufacturer rationales for electronic lockdowns almost always point back to emissions concerns because they're so defensible. How do you separate them?
Perhaps this is naive, but I would imagine that farm equipment is a rounding error in terms of global emissions. Compare the number of tractors to the number of trucks...
I would have expected policy to be pragmatic here, with (relatively) relaxed emissions requirements, since an affordable and reliable food supply is in the national interest? Sounds like that's not the case
Emissions regimes are complicated, but US tractors fall into the much less restrictive off-road category. As a result, they're a disproportionately significant contributor to things like NOx. A long time ago the off-road category was >20%, and I'm sure that percentage has only grown as regulations have forced emissions reductions in onroad vehicles.
The vast majority of offroad equipment is not farm equipment but operates in urban environments. As NOx is an air pollution concern, there should be different regimes for rural areas versus urban areas. Construction equipment operating in urban areas is different from a tractor on a farm.
I'd imagine it depends what kind of emissions you're measuring? Are we talking air quality or climate change?
Two stroke engines are pretty terrible in terms of unburned hydrocarbons and are disgusting for local air quality, which is why I'm glad they're being phased out in many areas.
I'd expect these tractors with I6 diesel engines to run pretty efficiently. I'd bet that the CO2 emissions from tractors are tiny in comparison from the emissions from trucks, fertiliser, and transporting the food.
Lawnmowers are usually four-stroke, with two-stroke engines reserved for lighter tools like string trimmers and chainsaws.
I would still guess that lawnmowers produce more emissions overall, given that there are so many more mowers than tractors. But they get used less often than tractors, so who knows? Either way, I agree with your thinking process, that the most economical way to reduce overall emissions is to focus on what are actually producing the bulk of emissions.
I don't know how much better cars and trucks can get, and for mowers maybe electric is the answer. Mine is gas-powered, and I know it runs rich. I would love to come inside after mowing and not smell like fuel, so I'm in favor of better emissions controls on mowers.
For tools electric is the answer. To take a chainsaw, the battery needs to be replaced just as often as with refilling the fuel tank. And with newer batteries you might recharge the depleted one as fast as discharging a fresh one. Not sure, just an assumption.
my brother in Christ, electric chainsaws are garbage, have you ever used one? I tried one out to clear a huge 3 foot wide tree that fell on my property and yeah those things cannot hang with gas powered chainsaws in any way, shape, or form. No one is using electric chainsaws for cutting anything significant.
they may have a place in the distant future but in 2026, aint no way.
I haven't used a chainsaw in a few years, but the last time I did, electric ones with a cord were great. I switched from a proper Stihl chainsaw to a budget electric one with a cord, and despite it being smaller and sort of flimsy, it did cut like crazy, comparable to the gas chainsaw. And it didn't require ear protection, didn't annoy the neighbors and didn't make you smell like a chainsaw for two days.
I like the electric saw for limbing and felling small stuff because it's light and quiet but yeah for anything bigger than like 9" or extended work it's not the tool for the job.
These are regulations, not laws, and can be changed fairly easily. E.g the EPA recently changed the rules requiring NOx sensors and power downs, which were the most failure prone components of the system, while still mandating the actual equipment that scrubs NOx.
There's no particular reason why a mechanical device needs computers for emissions, as the emissions removing components can still be attached and managed via simpler means. All emissions removing components are effectively physical devices, whether you are talking about carbon filters or PCV valves or particulate filters or the urea fluids that are added to the fuel. None of them requires complex software in order to function. There is no reason why you need to buy an official John Deere branded emissions component that is software locked to tractor and costs 10x the price of third party components that do the same thing.
Also, there is a large room to maneuver between "I want a sensor with some circuitry in it" and "the entire tractor is a proprietary computer with locked down parts". The right to repair movement is not about removing tech, but removing unnecessary proprietary tech that is designed to prevent owners of devices from repairing those devices themselves or with third party components.
defeat devices aren't even complicated (they just fake the sensor data to ECU to get what owner needs). Locking down is pointless. Most people are not tuning their cars.
IF we wanted to do it properly, I'd imagine we'd have zero mandatory locks on ECU, just a little closed down black box with sensor installed in relatively tamper-proof way (of course there will always be one, the target is for 90% of people to not bother), logging away and maybe sending check engine light if it detects wrong AFR for too long.
Then you just check that on yearly MOT + any signs of tampering. Then owner is free to tune the engine as they want, provided the exhaust is still within the norms for most of the time.
What would you be accomplishing by trying to control end user behavior like that? As a manufacturer, there are certain standards your machine must meet when it leaves your factory. After that, a whole separate set of standards applies to users--e.g. EPA rules about emissions equipment tampering. As a manufacturer, though, you don't need to attempt enforcement. Leave that to the government, it's their job. Locked down, proprietary hardware and software doesn't ultimately achieve enforcement, it just makes tampering more difficult at the cost of serviceability. This is a dumb trade.
It's to contain the regulation into little box that controls the emission, rather than span it to entire system making it harder to repair. Then the EPA can have its "proof" the vehicle emissions are fine without compromising entire system for repairs.
I think you're asking for something magical, like when politicians go on TV and demand safe cryptosystems with government backdoors. Any time you try to do engineering work to hinder users from using devices they own it's a really bad time. That's the purview of law enforcement, not engineering.
Mandate common interfaces and open hardware. I shouldn't have to buy a $10k dongle to sniff codes. I certainly shouldn't have to buy a different one for each manufacturer.
The legislation has to be robust. No dice if the dongle is generic and $20 like OBD2 in cars, but that on top of that there's a per-manufacturer set of codes that only licensed dealers have access to the software to read those special codes.
The situation today is at least better than it used to be before OBDII. I much prefer using a scanner to get codes then having to count flashing lights. And back then you'd still have to pay a lot for the manufacturer's code reader. The only advantage was the ROM was small enough to disassemble and reflash with new features. I would not want to do that on a car made in 2026.
Most of the codes on a large tractor are j1939. You still want the manufacture database because it often says 'x sensor voltage out of range - check the wiring harness in some not obvious location'
How do you define "electronics" and "computers"? Is a general-purpose computer running Java in the same category as a microcontroller running a tight loop with lookup tables for fuel and spark?
The problem: Once you have a microcontroller running a tight loop with lookup tables for fuel and spark, it's very tempting to make it run a tight loop with lookup tables for fuel, spark, and time since license renewal - and there's no outward difference between the two microcontrollers until one of them stops working. This is where regulations can help: if a manufacturer is afraid of a zillion dollar fine, they won't do that, even if the chance of getting caught is low.
While I agree in principle, we went two or more decades with cars powered by microcontrollers, and I don't recall any manufacturers trying to charge for licenses until more recently. There is something fundamentally different about the economy we are now in, I suspect.
I think the difference is that in the past, companies expected to be punished for obviously evil behavior, but now, they know they can go very far. Toyota got punished for stuck accelerators. Would they get punished for the same thing today? Tesla had stuck accelerators and we all forgot about it.
They're still pushing the boundary today. The Ring Superbowl ad where they announced they're watching you (but they said "your dog") 24/7 apparently got a lot of people to quit Ring, and you know they're crunching the numbers to see if the retention rate is worth the extra surveillance collection.
They charge for the diagnostic systems. Bigly. For example, Mercedes-Benz's Star Diagnostic System (SDS) is necessary for a variety of repairs and diagnostic procedures. There are varying degrees of workarounds and alternatives but none of them work quite right, or for every model/year/variant. It's not just the embedded system, it's also the interface to it. That's where the really ugly rent seeking crops up. And that's precisely why a tractor with no computers is attractive--not because the embedded software might try to ransom itself (although that's a reasonable fear) but because some horrible rent seeking corporate functionary will do their utmost to cheat you (or your mechanic) out of as much money as possible when it comes time to do any maintenance or diagnostic testing. No computers means that little bastard can fuck right off.
It goes the other way as well. Usage data isn't equivalent to asking users either. A solid percentage of bad decisions in tech can be traced to someone, somewhere forgetting that distinction and trusting usage data that says it's it's okay to remove <very important feature> because it's infrequently used.
This. If I'm forced to use a feature I hate because it's the only way to do something, the "ground truth" reflects that I like that feature. It doesn't tell the whole story.
Most metrics teams are reasonably competent and are aware of that. Excepting "growth hackers"
I haven't been in a single metrics discussion where we didn't talk about what we're actually measuring, if it reflects what we want to measure, and how to counterbalance metrics sufficiently so we don't build yet another growthhacking disaster.
Doesn't mean that metrics are perfect - they are in fact aggravatingly imprecise - but the ground truth is usually somewhat better than "you clicked it, musta liked it!"
Yeah, it's not a good discussion without concrete examples.
One: Building a good UX involves guesswork and experiments. You don't know what will be best for most users until you try something. You will often be wrong, and you rarely find the global maximum on the first try.
This applies to major features but also the most trivial UI details like whether users understand that this label can be clicked or that this button exists.
Two: Like all software, you're in a constant battle to avoid encumbering the system with things you don't actually need, like leaving around UI components that people don't use. Yet you don't want to become so terse with the UI that people find it confusing.
Three: I ran a popular cryptocurrency-related service where people constantly complained about there being no 2FA. I built it and polished a UX flow to both hint at the feature and make it easy to set up. A few months later I saw that only a few people enabled it.
Was it broken? No. It just turns out that people didn't really want to use 2FA.
The point being that you can be super wrong about usage patterns even after talking to users.
Finally: It's easy to think about companies we don't like and telemetry that's too snitchy. I don't want Microslop phoning home each app I open.
But if we only focus on the worst cases, we miss out on the more reasonable cases where thoughtful developers collect minimal data in an earnest effort to make the UX better for everyone.
> You don't know what will be best for most users until you try something.
That's because you don't understand your users. If you did, you wouldn't need to spy on them.
> you rarely find the global maximum on the first try
One never finds the "global maximum" with telemetry, at best a local sort-of maximum. To find what's best, you need understanding, which you never get from telemetry. Telemetry tells you what was done, not why or what was in the people's mind when it was done.
I'm not terribly familiar with graph databases, but perhaps someone who is can explain the advantage of this awfully complicated seeming design. There's gremlin, cypher, yjs, and zod, all of which I understand are different languages for different problems.
What's the advantage of using all these different things in one system? You can do all of this in datalog. You get strong eventual consistency naturally. LLMs know how to write it. It's type safe. JS implementations exist [0].
Gremlin-like API gives end to end type safety if you're querying the database from TypeScript. This was the original motivation for the library.
Zod/Valibot/ArkType/Standard Schema support because you need a way to define your schema and this allows for that at runtime and compile time.
Y.js as a backing store because I needed to support offline sync, branching/forking, and I use Y.js for collaborative editing in my product, so I needed to be able to store the various CRDT types as properties within the graph. e.g. you can have a `description` property on your vertices or edges that is backed by a Y.Text or Y.XmlElement
Cypher because until the arrival of codemode it wasn't feasible to have LLMs write queries using the Gremlin-like API and LLMs already know Cypher.
Most of all though, this was an experiment that ended up being useful.
The advantage for property graph databases using Cypher query language is that the queries for things like "show me all systems connected to this system by links greater than 10Gbps up to n hops away" are vastly easier to write and faster to complete compared to SQL and relational databases. Cypher lets you easily search for arbitrary graph patters and the result is also a graph, not a denormalized table.
Parent commenter was asking compare to datalog (not SQL) which eats recursive graph transitions like this for lunch, making the queries very elegant to read ... while still staying relational.
I'm personally of the opinion that "graph databases" should be relational databases; the relational model can subsume "graph" queries, but for all the reasons Codd laid out back in the 60s... network (aka connected graph) databases cannot do the latter.
Let the query planner figure out the connectivity story, not a hardcoded data model.
% 1. Base case: Directly connected systems (1 hop) with bandwidth > 10
fast_path(StartSys, EndSys, 1) :-
link(StartSys, EndSys, Bandwidth),
Bandwidth > 10.
% 2. Recursive case: N-hop connections via an intermediate system
fast_path(StartSys, EndSys, Hops) :-
fast_path(StartSys, IntermediateSys, PrevHops),
link(IntermediateSys, EndSys, Bandwidth),
Bandwidth > 10,
Hops = PrevHops + 1.
% 3. The Query: Find all systems connected to 'System_A' within 5 hops
?- fast_path('System_A', TargetSystem, Hops), Hops <= 5.
or in RelationalAI's "Rel" language, such as I remember it, this is AI assisted it could be wrong:
// 1. Base case: Directly connected systems (1 hop)
def fast_path(start_sys, end_sys, hops) =
exists(bw: link(start_sys, end_sys, bw) and bw > 10 and hops = 1)
// 2. Recursive case: Traverse to the next system
def fast_path(start_sys, end_sys, hops) =
exists(mid_sys, prev_hops, bw:
fast_path(start_sys, mid_sys, prev_hops) and
link(mid_sys, end_sys, bw) and bw > 10 and hops = prev_hops + 1)
// 3. The Query: Select targets connected to "System_A" within 5 hops
def output(target_sys, hops) =
fast_path("System_A", target_sys, hops) and hops <= 5
That said, modern SQL can do this just fine, just... much harder to read.
WITH RECURSIVE fast_path AS (
-- 1. Base case: Directly connected systems from our starting node
SELECT
start_sys,
end_sys,
1 AS hops
FROM link
WHERE start_sys = 'System_A' AND bandwidth > 10
UNION ALL
-- 2. Recursive case: Traverse to the next system
SELECT
fp.start_sys,
l.end_sys,
fp.hops + 1
FROM fast_path fp
JOIN link l ON fp.end_sys = l.start_sys
WHERE l.bandwidth > 10 AND fp.hops < 5
)
-- 3. The Query: Select the generated graph paths
SELECT * FROM fast_path;
>I'm personally of the opinion that "graph databases" should be relational databases; the relational model can subsume "graph" queries
The MIT team which is also part of the team that proposed GraphQL already kind of solved this problem using D4M [1].
Essentially D4M is able to universally represent relational, graph, spreadsheet and matrices using the mathematic technique of associative algebra, they even wrote an entire book on the subject [2].
It's beyond me why they didn't push forward for D4M but instead propose a limited GraphQL. It seems that they're restricting the D4M capability and focusing on query language like GraphQL, perhaps due to the industry demand and bias.
Heck the same team also proposed TabulaROSA, a new database OS as the more efficient alternative for conventional file-system based OS like Unix/Linux [3].
[1] D4M: Dynamic Distributed Dimensional Data Model:
> the relational model can subsume "graph" queries, but for all the reasons Codd laid out back in the 60s... network (aka connected graph) databases cannot do the latter.
Except network databases have little in common with graph databases...they're much more closely related to hierarchical databases.
I would say that Graph databases are now a strict superset of relational databases, not the other way around. In a graph database a node's named edge can naturally point to a node of any type or having any property schema. Doing this in a relational model requires one of several approaches that could only be classified as fighting against the model (or torturing it, as my PI liked to say).
JOINS make these kinds of queries get slower as the number of hops gets larger. And property graph databases have the big advantage of not having to mutilate their query results to fit into a flat table. A path query returns a path object of connected nodes. Property graphs are superior for applications with deep, variable-length connections, such as social networks, recommendation engines, fraud detection, and IT network mapping. Property graph databases work well with object oriented programming where objects map to nodes very well.
RelationalAI's model is very cool but it is cloud only software.
It'd going to get slower as the number of hops get bigger regardless of whether you accomplish that via relational join or pointer traversal. And doing it the former gives great opportunity for optimization during execution through vectorization or more appropriate index data structure usage.
Modern computers are also much more efficient at batch / vector processing than they are pointer hops. By either CPU or GPU, the whole system is much more tuned for working with data as sets / tensors rather than "hopping" through the data via pointer.
How you materialize your results for processing is your own business. The advantage of the relational model is its consistent throughout; the source data, the manipulation format for the operators, and the output are all relations. You can visualize it as "flat table" but that's an unimaginative visualization. You can just as easily twist that into a nested hierarchical structure in an object oriented language if you're so unfortunate as to be stuck working that way.
A "table" is only a visualization of the data, not the "form" the data actually takes and it's unfortunate that SQL chose this word.
It's better to conceive of a relation as a series of facts or propositions about the world. Each "row" is a statement. When read that way, it's a lot more elegant.
Neo4j-style index-free adjacency gives you O(1) per-hop neighbor lookup per node; cost is proportional to the subgraph actually visited. A k-way self-join on a relational edge table has to produce and filter intermediate tuples at each join step, and intermediate result size can blow up multiplicatively even if the final result is small. A k-way self-join on a relational edge table has to produce and filter intermediate tuples at each join step, and intermediate result size can blow up multiplicatively even if the final result is small. For deep traversals with selective endpoints, the relational plan's intermediate materialization is exactly the problem native graph engines were built to avoid.
You can just as easily see nodes and edges in a property graph as propositions about the world. The nice thing is that you can model relationships between entities as first class entities. nodes have the implicit property of being non-fungible.
Do you know of any relational database that returns a query result as normalized tables the way neo4j returns a sub-graph?
Honestly, I won't convince you, so I'll leave you to the pleasure of your pointer chasing, L1 cache misses, multiplicative blowups, and fixed / inflexibly structured taxonomies.
In practice if you index the right properties and have the right relationships in Neo4j then queries are very fast. And neo4j doesn't have taxonomies. You might be thinking of RDF. One of the best things about Neo4j compared to relational databases is the lack of a rigid schema.
I don't believe any AV software out there attempts to solve the trolley problem. It's just not relevant and moreover, actually illegal to have that code in some situations.
You can't get into a trolley situation without driving unsafely for the conditions first, so companies focus on preventing that earlier issue.
Very cool! I meant more hands on diy fab, like how I make my own pcbs. It seems farming out my designs to be produced (hdl->chip) at reasonable one-off costs is a plausible avenue now, which is exciting as well. I've probably been exposed to too many toxic chemicals already anyways and should readjust my bucketlist plans...
The latter are pretty grueling, especially when conducted on-site. Apple recommends you show up 1-2 hours ahead so you have enough time to get through security, for example.
reply