832 karma · joined January 11, 2022
My experience with Japanese people and some anectodes from a friend who worked at Nintendo is that bureaucracy, culture expectations that you shouldn't change jobs at all, and English ability are some of the strong limiting factors for Japanese rank and file employees to achieve high pay. It's a shame as Japan has so many smart people who are both down to earth and innovative.
This kind of judgement is incredibly unprofessional.
Their strong claims relative to the sample size and the quality of the experiment makes me doubt their level of motivation to do proper science. Just another flimsy paper used to pad resumes.
I don't feel this is fundamentally different from the categorization of finite simple groups, which is also combining many small theorems and proofs, yet more widely accepted.
A common chokepoint in an engineer's career development is challenging others' preconceived notion of what is important. Often this is with non-technical management, but unfortunately this is sometimes needed with technical peers too. It's politically convenient to just go with the flow and align oneself to the most visible metrics, but that way only a limited amount of bottom-up innovation can happen, and those can be critical to the business.
The best one can do is to establish the importance of the project before you do it, but I've seen important projects that were initially not supported by management, and only got traction when an IC did it anyway and demonstrated the value. Sometimes ICs were lucky that the impact was measurable and recognized, sometimes not so much and were deemed to have wasted precious company resources.
The world is not perfect and we often have to choose between taking a calculated risk or to conform. It's hard to get business processes 100% right, and not easy for a person to do things with guaranteed outcome, so we just have to live with it and try our best to navigate strategically.
You just did not approach this constructively. It would have been better if you asked first about how the impact was and could have be measured. Or at least responded more directly when they tried to explain the impact better. Instead of making and sticking to an assumption that the service wasn't useful.
It may well be that the person misunderstood their impact, but your arguments did not address that after the person came back with theirs. They could have been an edge case, that they are in an unfortunate situation in the human process of deciding rewards, where choosing and calculating metrics is itself subject to errors in judgment, and you tried to generalize your experiences to their corner of the world, which normally requires a stronger questioning.
The right attitude is to figure out processes that let people draw a line when to go to DevOps, and when to escalate to developers. Developers need to understand the costs they impose on devops and organizations need to make sure developers are empowered to fix their own issues, rather than to be constantly chased around to business requirements.
Developers ultimately answer to business priorities, and they don't necessarily own the business processes that demand their support. If developers are given ample resources to keep bugs out of systems, document operational expectstions and respond to incidents, then the developers can "own" the processes better. If not, it's a management problem that is just of the same nature as the usual SRE complaint that developers don't want to own anything at all.
Best bet for an ex-con is to bootstrap a crypto-native company anonymously, or a crypto trading firm. Given how Alameda went, more likely the former, but I suppose that's getting harder too.
Indeed, 95% of those things are mundane and tractable (maybe you have to be fast and careful), but the remaining 5% are challenges that can only be solved by specialized knowledge or some innovation.
If you hire someone good at solving mundane problems, they can contribute to the 95%. But if 95% of the company is hired like that, the pool of people you can draw on to do the remaining 5% is <5% (maybe more, if the company is lucky). There's a good chance that business is blocked by the remaining 5% because of the high uncertainty in delivery, fundamental to the nature of the problem.
Another approach is to hire, say 50% to do mundane work and 50% to do both mundane work and more special work. This costs more, but if done right it can make the company move faster, and have better chance to survive than any case of the former.
First of all, it's often (but not always) the case that people who can do special work can be trained to do the mundane things better. Second, having many people who can solve one-of-a-kind problems is especially important if for each project the 5% can depend on a different set of things; it's often also the case that solutions to the innovative work is closely related to experience dealing the more mundane parts, so this structure basically recognizes that innovation can come from rank and file rather than a specialized "ideas guy" that just flies by to solve problems. So what happens in certain small but profitable companies is that they try to find people who are happy to do dirty work, have a business mindset, but at the same time show signs of being innovative.
This is not to say I agree leetcoding is a good test. I think Google and Facebook don't test enough whether someone is capable of or interested in identifying technical priorities with a business mind. Although Google has some data to connect leetcode performance to job performance, I'm skeptical of their performance evaluation methods.
What it evolved into is a bit controversial, overall they seem to be a bunch of kids who don't know what to do with the power and money they had at one point, as they all came too easy.
SR is equivalent to blind feature engineering. If I put it like that, probably most people who've done a bit of data science would know how bad of an idea it is unless we can regularize it well and bound the search space based on prior knowledge.
Deep learning has the same theoretical problem and it's only overcome by its unreasonable empircal effectiveness on certain problems. And even then, nobody cares about its NP-hardness.
The computationally difficulty of something like SR is also deeply connected to its applicability. If you have data where it's easy to apply SR and trust it, it tends to be easy; to trust your ability more you probably want to add regularization based on the complexity of the final formula, and probably you'd have strong priors on a small set of functions that are applicable. Once you don't have this, and get to where the problem can be plausibly NP-hard, you're going to overfit and the technique is worthless.
There's a family of ML theoretical questions that are just very low value as they make very little progress in helping to understand important problems. This is one of them.
In fact you could turn your argument around to critize the article too, as they are based on the assumption that some of the assets should marked to zero, rather than examining empirically whether those assets could be either collateral or be used to pay the debt.