This isn’t true; LiDAR points provide an intensity value that provides information about surface material and ambient environment. Further, this information is influenced by angle and distance.
Lane lines and road signs in particular typically use reflective paints that are very easy to detect in LiDAR, but beyond that, you can approximate material composition of a LiDAR scene pretty easily.
Another big point you’re missing is that LiDAR can provide control points to photometric sensor fusion systems. While there are also purely photo based control point matching systems, they’re much more complex and require nontrivial offline preprocessing.
Many people also don’t do well in high stakes problem solving situations even when not being watched.
I’m not suggesting OP is dumb, but if someone is setting hiring criteria and thinks they need X skillset judged by Y, I think there’s a good chance they’re directionally correct.
I get it, I’ve bombed interviews I was excited about and rationalized it anywhere and everywhere. Once I started hiring folks, my opinions evolved significantly.
How else do you hire someone out of a pool of people that are all knowledgeable and likable? A bad hire, even if they’re super smart and just the wrong fit, is worse than not hiring anyone at all.
If you climb the management ladder, you’ll likely be graded on your org’s hiring outcomes. If 10 people all seemed qualified, I’m going to burn down the risk as much as possible. If I’m wrong 1 time for this, but it not obviously wrong 9 others, I’ll call it a win.
For context: this is coming from tiny startups to billion dollar companies and different things in between.
What if there's solid evidence (e.g. visible work in open source) that all ten can code? The problem is not that coding interviews exist at all but that they're mandatory for all levels and roles. At L5+ coding isn't even the most important skill, so LC-style coding interviews introduce a risk of false negatives without providing any actually useful information. BTW those false negatives occur disproportionately for some demographics, and it only takes a single mention of "culture fit" to make one wonder if that's the whole point.
I dunno? I ended up not working at a company that fired thousands, was grievously injured by Apple flicking a switch that enabled sensible privacy defaults, squandered Carmack, and is losing to ultra conservative legacy institutions in an innovation driven space?
And according to Levels.FYI I'm making more than the average person with a comparable title at Meta, maybe because the same things that made Meta excited made me attractive to other employers without the random cargo cult filters...
But hey, maybe I'm just trying to convince that recruiter who definitely wasn't laid off.
I think these arguments often miss the “for who” both in the producer and consumer sense.
If you have a team or teams of engineers, having one or two people deal with all the dev-ops stuff makes a lot of problems go away.
But if you have a large C++ project for example, you probably need more than a couple people focusing on build and target dev-ops work, or at least a lot more of their time.
It’s a lot easier to get a frontend person to help out with the backend dev-ops than it is to hire a new C++ guru and wait a bunch of time to catch up on the nuances of your build systems/org/whatever.
Anecdotally, I see the people who balk at Node are usually enterprise Java devs, backend Python devs, or junior Go/Rust enthusiasts.
At the end of the day, all these languages can interoperate with all the others in a bunch of different ways, and an organization’s ability to engineer and maintain systems is mostly orthogonal to its choices of “driver” technologies.
Anecdotally, I've met a ton of people who balk at Node for backend stuff. I've been at two companies where it was actually prohibited.
> At the end of the day, all these languages can interoperate with all the others in a bunch of different ways, and an organization’s ability to engineer and maintain systems is mostly orthogonal to its choices of “driver” technologies.
I think people say that in an interest to keep the peace, but the assertion doesn't stand up to close scrutiny. Poor technological choices kill companies, or at the very least, make them perform more poorly. Choosing the right technology is a core skill for technology companies.
The problem is that each company is a goddamn unique snowflake. Company X has a bunch of front-end developers and spends most of their money on headcount. Company Y has a bunch of back-end developers and spends most of their money on infrastructure. The "best language for a project could be R, Python, Go, Rust, C++, TypeScript, C#, Java, or something else. Picking the wrong language can sometimes be outright disastrous compared to picking a good language. But most of the time, there's no clear "best" language.
Even though there's no clear "best" language, these people balking at Node may have a point.
This isn’t merely about tools. They’re one piece of a much larger puzzle. The fragmented chaos of the Node ecosystem arising from that aforementioned ephemerality ensures that eighteen months is roughly the duration before bitrot of dependencies is corrosive enough to have folks talking about rewrites. In four decades driving keyboards in various capacities, I’ve never seen any language experience dependency rot in production apps so rapidly as JavaScript and its offspring.
Aside: any shop operating under the assumption that devops is a function you assign to someone, has already failed devops 101.
I genuinely don’t believe you’re coming at this from a business stakeholder POV, which is fair for HN. But if you have to advocate for a devops org outside of some massive global scale or as a small % of revenue, you’re doing something wrong.
Unfortunately a proven playbook for struggling devops teams is to just fire all the devops and infra folks, which seems to help with platform stability, recruiting, and velocity year over year.
Your opening assumption is false. I start and run businesses.
Any reference to “devops team” is also automatically failing at devops. It’s not a job, a task, or a team. I don’t spare much time for folks encumbered by a silo mindset. It’s the antithesis of a service/product-team approach, and (to the actual point) does nothing to oppose the myopia I’m accusing the JS ecosystem of.
You could look at L2s as a sort of credit card system, and from a systems and technology POV there’s nothing inherently “scammy” about it. For web3 applications of any meaningful large scale, L2 solutions are necessary.
For better or worse, the L2 developer platforms that I assume you’re referring to are essentially low-code solutions to abstract away the actual systems software engineering aspect of web3 development. Are the low-code SaaS companies overvalued or “scammy”? I’m not suggesting they are or are not.
Well-staffed tech companies building web3 applications often build their own implicit L2 solutions because it’s just how you connect things in a distributed system with modern L1 blockchain constraints.
I think the person you're responding to was talking about Bitcoin L2 chains, probably more specifically the lightning network.
I actually agree with that about Bitcoin.
Web3 is generally done on EVM or cosmos chains, some of which are L2s (and some of which are loosely considered L2s). But most of them are still separate chains, so not L2s in the sense that the Lightning network is an L2. If you're looking at EVM chains, then L2s are certainly required to handle significant throughput, but the "lack of transparency" mentioned by GP isn't an issue with them.
Especially considering that it is being independently developed by three organisations as an open source protocol that offers complete self-hosting and doesn't require an intermediary during operation...
Basically it leads to hubs forming where lightning nodes with large amounts of funds are better able to facilitate transactions, and also benefit from that due to transaction fees.
This is as clear and succinct a statement as to why "web3" has nothing to offer as I have read.
Translation: we will rebuild existing financial institutions with a bunch of move-fast break-things poorly-regulated "difi" companies which will both intentionally and through ignorance recapitulate every flaw of the existing financial industry.
Purpose: as in the Celsius case, to intentionally exploit regulatory response time so as to extract money through opaque extra-legal and unethical exploits, intended to allow ourselves and chosen insiders to run off it, leaving deluded last-fools holding the bag.
There is literally no benefit to anyone except the VC backing the scam, who are using chaff and FOMO to farm rubes.
I think this has been going on for at least 2000 years…
It doesn’t matter if it’s crypto or gold, there will always be people manipulating financial systems, but that doesn’t mean any system is inherently good or bad.
> Well-staffed tech companies building web3 applications often build their own implicit L2 solutions because it’s just how you connect things in a distributed system with modern L1 blockchain constraints.
Sure. The banks do the exact same thing, which is what makes them so goddamn profitable to run. The problem is that the entire cryptocurrency space now has to choose between two destinies:
a. Default on the trustless model in order to continue scaling, passing the actual verification process to private validators who may or may not be scamming you.
b. Let every token lose it's value, allow the system to suffocate and continue pushing for airtight security until the bitter end.
Now, neither of those are attractive choices. I'll tell you what, though: I'd rather have a $20 bill than $20,000 of Monopoly money.
If it was a person, you shouldn’t have responded on a Sunday before a holiday. You’re at the bottom of their inbox now. Also, try to hold the questions for a live chat if you’re interested in the company.
It sounds like you really want to learn about roles at Chewy, why not just send another email or directly contact a recruiter on LinkedIn?
Interesting, looks like it’s using a combination of hardware, vehicle checks, LoRa (Helium?), ML, and good old fashioned Humans for verification.
If they can scale it globally and at high frequency for imagery, that’s a very novel justification of crypto IMO. Looks like the Costco version of https://www.mapillary.com/
You’re a curious person and see that the back door to a closed restaurant was left unlocked. You should let them know, but make sure you find out how big of a screw up the closing manager caused so s/he can be dealt with or the process fixed.
You open the door a little and peak inside and see the office door is open. “This can’t be,” you think as you walk into it.
You bet there’s a safe left unlocked and customer reservation left unprotected on the computer, “how irresponsible can these people be…”
If their security is this bad, you wonder what their food safety processes are.
It’s a slippery slope, and maybe well-intentioned, but that doesn’t change the fact that you’re not allowed to wander into this restaurant’s back door or be there when it’s closed, and now that you have, how do you prove you didn’t do anything malicious if the only evidence there is is of you in the restaurant when you’re not supposed to be?
Maybe you can make an appealing public good argument against criminal accusations based on your stellar clean record, but how do you protect yourself from civil suits, which they have every right to spin up if they have damages and can link you to them?
Please don't conflate physical invasion with violation of data privacy. Everyone downloaded a car, 3d printed it, and are now driving around happily in them. This argument is beyond tired.
The laws regarding computer intrusion are stricter than those governing real-world breaking and entering. Trying someone's door isn't a federal crime (though it'll absolutely get you arrested, even though that's the open protocol a doorknob advertises).
Even in SF/Bay Area, 400 isn’t as common as level.fyi would have you believe. You can’t (easily) trade equity appreciation or pre-liquid options for cash.
Yes, in SF there are companies that give a lot of liquid RSUs, but most engineers don’t work at those companies, even if a lot of engineers do.
Also, if you’ve been swinging and missing in a silo for 20 years without full time employment, you’re most likely not going to easily find a job that pays you 400+ without working full time at large companies first.
Lane lines and road signs in particular typically use reflective paints that are very easy to detect in LiDAR, but beyond that, you can approximate material composition of a LiDAR scene pretty easily.
Another big point you’re missing is that LiDAR can provide control points to photometric sensor fusion systems. While there are also purely photo based control point matching systems, they’re much more complex and require nontrivial offline preprocessing.