I was going off this for popularity: https://stackoverflow.blog/2023/01/26/comparing-tag-trends-w...
4,408 karma · joined July 4, 2015
No. Designing a system that is always up and running and can process small amounts of data constantly is a completely different problem from designing a system that runs occasionally with a lot of data. For one thing, your output formats are usually different in the latter case (maybe you're creating a PDF for example). Also the high availability requirement just makes things different at the design level.
Finally, the author claims it's not hard to switch between batch and streaming. With a large volume of preexisting data, this is just not true. For example, if you make a REST API call for each document in a DB, it can take days or months to load that. If batching together documents isn't a possibility, how do you move data between stores easily? (This data movement is often required when switching between batch and streaming.)
It's certainly true that LinkedIn is the go to for white collar professionals seeking to make their resumes visible passively to recruiters. But isn't life still easier with LinkedIn than in the before times, when recruiters would dig deep to get folks' phone numbers and then have to call each of those people individually? (I think the modern equivalent would be email addresses.)
It's true that LinkedIn makes recruiting much easier to scale to a mass market. And it's also true that it has a monopoly on that scaling for professional employees. But is it fair to call them an economic termite when it's still possible to do sourcing in an admittedly clunky and old fashioned way? Just because they have a monopoly on scaled recruiting doesn't mean that they hold all the cards the way Linde (also in the profile) would in the gas market. This is particularly borne out by the existence of Indeed or Stack Overflow as options for posting your resume for recruiting.
The most impactful thing I delivered at my previous company was a script that moved all of our team's data from a self-hosted db to something on company cloud that was a lot more stable. The script itself wasn't very complicated (essentially just mongodump and mongorestore), but it made a big impact on ensuring that our team's dataset search tool would continue to be accessible to regulatory compliance folks. In turn, the regulatory people could use the tool to protect the company from getting fined under CCPA, etc.
It made a pretty big impression on me that something incredibly simple like that could make as much financial impact in expectation as that script did. Now when I mentor interns and newer, more junior people, I always tell that story as an example of how high impact can be surprisingly uncomplicated.
In general, I prefer the approach of writing out the entire solution at one go, and trusting that bugs will be easy to fix at the end if the code is clean enough to understand what is happening at every step. This is in part because there usually isn't enough time in interviews for running tests at every crux moment. However, I think our current virtual environment may make it easier to test for (and to utilize) these types of programming best practices, since instead of writing code on the whiteboard, candidates and companies can use one of the interview interfaces that allows running code as you write it.
Can someone help me understand why this is a good thing? By the arguments presented by other commenters, it seems to me that a) these hallmarks can be duplicated by someone else and b) by only running operations with said hallmarks, the intelligence agencies might miss other vulnerabilities.
I was just wondering which APIs did you prioritize to appear here? Was there a scoring process?