The book @intensivedata has got to be the most information-packed one I've read. Summary of all major DB storage techniques, explained in 35 pages in the book. Thread.
1. "Plain old" key-value store in a textfile 2. Indexing a key-value store (e.g. a CSV) with hash indexes (1/6)
3. Segmenting files as they grow via compaction 4. SSTables - sorted string tables (sentence of key-value pairs sorted by keys). 5. LSM-trees (Log-Structured Merge Tree) 6. B-trees: standard storage in many relational/non-relational databases (2/6)
6.1 B-tree reliability & optimization (write-ahead-logs, latches, copy-on-write) 6.2 B-trees vs LSM trees 7. Other indexing approaches: clustered indexes, covering indexes, fuzzy indexing, in-memory DBs (3/6)
8. OLTP (online transaction processing) & OLAP (online analytics processing) (3/X) 8.1 Data warehousing and ETL (extract, transform, load) 8.2 OLTP vs data warehousing 8.3 Star schemas / dimensional modeling (4/6)
9. Column-oriented storage
9.1. Compressing columns: bitmap encoding, vectorized processing 9.2 Importance of sort order. C-Store. 9.2 Writing to column storage: B-trees & LSM trees (hello again!) 10. Data cubes & materialized views (5/6)
This information (and explanations) are about 1/20th of the book.
I thought I knew data systems at decent detail. I keep learning new things, and having "aha" moments on concepts I used, but didn't know in detail, or their tradeoffs.
I've been helping a bootcamp grad frontend dev friend prepare for interviews - they worked as a jr dev for 2 years after the bootcamp. But were out of a job the past 6 months.
They just got an offer as a JS engineer!
Thread on 10 prep resources & job market observations.
1. Interviewing for frontend positions today is HARD. IMO the web is the most in-flux in terms of interviewing approaches between backend and mobile.
You get a huge variety of interviews. Some places dive into React hooks. Others ask vanilla JS. Others algorithms / DS.
18 things that companies with a good developer culture (mostly) have. A thread.
First, some basics. 1. Psychological safety & a blameless culture. You can be yourself without fear. 2. Fair compensation, roughly on par with the market. 3. Common-sense flexibility w working hours.
Next: clarity & collaboration 4. Understand the "why" before starting work. 5. A backlog that devs also contribute to. 6. Communicating directly with others, not through e.g. managers 7. Working with other disciplines (e.g. product, UX) 8. Celebrating that people take initiatives
Sustainable engineering culture 9. Functionally complete != production ready 10. Code reviews and testing are part of the everyday dev process. 11. CI and CD. 'nuff said. 12. Healthy oncall. Fixing poor oncall has priority over product work. 13. Internal open source model.
"Can you summarize this 200-page dev resume book in 7 tweets or less?"
Challenge accepted. Here we go.
1. Know what the goal of your resume is. This is what most people get wrong. It's not about your professional history. It's to get that next call with the recruiter/HM. (1/7)
2. Understand how the hiring pipeline works: who will read your resume, and what your competition is at smaller, vs larger companies.
Know that an employee referral *dramatically* increases your chances of passing the resume screen round. (2/7)
3. Use an easy-to-scan template. Recruiters do a quick scan, then a thorough scan (if they find key details in the quick scan). Make this "quick scan" as easy as possible.
I've been writing the ebook thetechresume.com on the side for a few months, and launched it 13 days ago.
In this 13 days it made $13,000, and $18K since I started, with more than 2,000 customers.
This is about 13x what I expected. Thread on how it got here.
It all started with COVID, layoffs happening across the tech industry, and me wondering how I can help. I offered to do a few resume reviews, being a hiring manager myself:
I thought I'll get a handful of responses. I got 300+. There was no way I could give thorough feedback on all of it. So I decided to scale myself: do in-depth review of the first 50, take notes, then send those compiled notes to others. Here's that PDF: thetechresume.com/samples/origin…
I’ll write about my (similar) take in more depth. But a few facts most people are surprised about, on what becoming an eng manager at Uber is/was like (thread):
1. It’s not a promotion, level or money wise. EM1 == Sr Eng comp wise. Sr EM == Staff Eng. Director == Sr Staff. And so on.
When I moved to management, my comp actually dropped: before I was at the “top” of Sr eng, but now closer to the bottom of EMs when it came to bonuses.
2. You don’t just “become” a manager. You *have* to go through an apprentice manager program and graduate. Graduating is ridiculously hard: as hard as manager promo. My case had 20 stakeholders giving feedback on me. Why this hard? To avoid making poor managers full-time EMs.
“Why do companies ask data structure&algorithm questions? It’s not like you’d use this day to day...”
At my past 3 companies - Skype/Microsoft, Skyscanner, Uber - I needed to use them to write some code, and *especially* to understand things. Here’s some examples. A thread.
At Skype, building Skype for Xbox One, the platform was missing a bunch of basic libraries. We built a navigation framework on top of WinJS that needed to keep track, and in some cases, traverse the DOM tree. #Trees, #DFS, #BFS
Also at Skype, one of the devs was obsessed with performance. For the contact list sorting, he built his own algo. I used the O(n) approach to tell him why this was silly. Then built a faster version. Then we benchmarked the built-in sort which was faster #sorting#facepalm