This week: on CSRankings.org, “local-first software,” and some discussion of system design interviews. Otherwise, see all the CSCW papers I’m working through!
Why I don’t recommend CSRankings.org discusses the issues with the website csrankings.org (which attempts to rank academic CS departments). Those include the fact that it’s anti-interdisciplinary (counting only pure CS conferences), anti-progressive (counting only the most well-established conferences), and US-centric.
A common mistake in computer science is to take the easily computed answer as the correct answer to hard problems.We develop a new technology and then ask “Maybe this technology X can solve this problem Y.” What we don’t often ask enough is, “Is this a good solution to that problem? What have we lost by using the technological solution?”
Absolutely true.
Local-first software is an essay on the benefits of software that runs and stores data locally (on my computer), as opposed to, say, a server or the cloud. Local-first software means better data ownership. Local-first software means not being shut out when a service shuts down.
The authors lay out guidelines for how “modern” applications can embrace local-first principles, ultimately creating more robust, longer lasting software.
Some personal context: I’ve been looking into a local-first knowledge management and note-taking software. Notion and Roam Research both lack offline mode, and I feel hesitation subscribing to a service that will lock in my data and make migrating away challenging.
System design interviews: some takes on posture by Diego Ballona discusses the system design interview. He finds collaboration between interviewers and candidates to be helpful for assessing candidates. Some of the advice is standard: rephrase the objective, establish what is in scope, voice your assumptions. Other advice is more complex, like the entire section Touch on adjacencies of the problem, including operations, security and compliance, organizational management, and more.
tl;dr: I find the system design interview the most insightful technical interview of all because it covers objective and subjective criteria. For the subjective aspects, I like collaborating with the interviewers, going wide first and then deep into detail, talking about what can go wrong beyond software, and touching on adjacencies of the problem at hand.
I quite liked this. I appreciated that it went into more depth than the average blog post on interviewing. A lot of this advice is specific to the system design interview, which was a signal that the post was well written.