> While these checks could also be handled by unit tests, most scientists generally just end up with their own weird set of ad hoc test outputs and print statements. It’s ugly, and not infallible, but it tends to work well given the intensive nature of our result-testing behaviour and community cross-checking.
The sense in which this statement is plainly wrong is actually addressed in the original article:
> Regressions like that are common when working on a complex piece of software, which is why industrial software-engineering teams write automated regression tests.
This is the whole point. You can only run your "ad hoc" print-statement-based tests once off, which is why such "tests" are useless for finding regressions.
There's a bias on HN to compare working-from-home with the commuter experience _in the Bay Area_, and conclude working from home is better. For many of us in places like New York, living in the city and going to the office is much more preferable lifestyle than working from home in a random place.
I live in New York, have a reasonable commute (20-30 mins each way), and vastly prefer working from home. The commute is only one factor in my preference and I can't really decide whether saving time outweighs what used to be a dedicated time slot for reading non-work stuff.
100% percent my experience too. In the last 3 months I've been on-site at 3 of the FAANG companies. Not a single interviewer brought up the large personal projects I've done and which are given decent space on my resume; my weeks of leetcoding was definitely far far far more beneficial for getting a job.
sometimes feels very sad about this since one's value should be reflected by the awesome projects he has done. I think it's just laziness of the FAANG companies. If the interviewer is well prepared and keeps digging the resume, then he should know the candidate is good or not. But by leetcoding, it's simpler for them, just keep asking the repeated questions.
From my personal experience, a company wants a "yes man", someone who will do as they command. From their perspective, if you can't pass (or refuse!) the coding challenge, you're already in the red flag zone. That's just how it is.
The funny thing is that a single fairly large personal project will develop your engineering skills 42 times that of the hundred something leetcode problems you solved for your FAANG interviews.
One teaches deep long term critical thinking. The other short term critical thinking. You won't see any small short sighted systems out in the real world.
I think that if your hobby projects will be important for many people: i.e. you develop something with the importance npm, or Ruby on Rails, or Vue.js, FAANG companies will make you offers without asking you leetcode kind of questions.
This is not true. Not so many people can set up popular and awesome projects like npm or vue.js. These are top level programers. But for other people you can not say they are not good enough to be qualified.
I read that the guy who invented Homebrew still had to go through the leetcode interview at Google (which they failed) so I'm not sure if they ever waive the interview requirements?
I'm on a H-1B visa, which sounds like the same visa your co-worker is on.
H-1Bs are permitted to change jobs, and if they are laid off from their current job they have 60 days to find new employment before having to leave the United States. Even if they have to leave, they can continue to job hunt remotely (really hard, I know) and if they get an offer they can return to the US on the same H-1B (no lottery). In NYC at least, medium to large employers are very happy to process the H-1B transfer paperwork because good engineers are in such high demand.
If your co-worker is as good as you claim he is, he should start looking for a new position. It's not as hard as many people think it is on this status. The main thing is to get beyond the mentality that you're beholden to your original sponsor - you aren't.
You also need to find an employer that understands how trivial it is to file a petition for a worker who already has an H1B. It is cheaper than paying a recruiter and the success rate of getting the candidate is much higher.
> While these checks could also be handled by unit tests, most scientists generally just end up with their own weird set of ad hoc test outputs and print statements. It’s ugly, and not infallible, but it tends to work well given the intensive nature of our result-testing behaviour and community cross-checking.
The sense in which this statement is plainly wrong is actually addressed in the original article:
> Regressions like that are common when working on a complex piece of software, which is why industrial software-engineering teams write automated regression tests.
This is the whole point. You can only run your "ad hoc" print-statement-based tests once off, which is why such "tests" are useless for finding regressions.