ramoneguru

100% agree with the "building for trust". The only problem is we tend to hire based solely on technical skill. I don't recall an interviewer ever asking me something like, "how do you build a team that values trust and what does trust mean to you?"

Even when I joined the team, we never discussed trust and what we can do to be a more trustworthy team. It was always centered around how can we be more efficient in our deliverables.

This is the video I usually reference: https://www.youtube.com/watch?v=kJdXjtSnZTI

180 minute pair programming call as well as a 60 minute tech screen? Even MAANG companies only do 2 technical rounds of "pair" programming. Why so much?

How does this stack up against something like what QuestDB offers?

I liked the points about bringing something early to the group and being comfortable with a half-baked ideas (provided it didn't take 2 weeks to write a couple of paragraphs for your design). Started off with some good insights, then pushed into the whole, "use FigJam, it worked for us"... Sucks, because it was shaping up to be a pretty good article, but instead we got an ad.

Nice work, did you start off by looking at any previously built canvas-like spreadsheets or was it straight to "virtualized custom canvas magic"?

I interviewed at a spreadsheet company (for a frontend role) and they asked, "how would you go about determining what cells need a border when a user clicks an individual cell, clicks a cell and selects multiple cells, clicks a cell next to an already selected cell." Fascinating problem and we talked about solutions for a little bit.

Noticed that you can't unselect a cell once it's selected? I'm on a Mac with Chrome (latest, no updates available).

Repo steps: 1. Select a few cells (⌘ + click) or an individual cell 2. Try unselecting (⌘ + click) those same cells clicked in #1 3. Cell is not unselected

Well… for testing purposes, of course.

Instead of pure code try seeing it as a book. If I read a book with a lot of spelling/grammar errors, a story that goes nowhere, characters that aren't interesting to me, plots that make no sense, etc..., then I'd tend to think of it as a not well written. Same with code, if variable names are obscure, function names don't match what they actually do, needless abstractions, nonexistent documentation, no tests, etc..., then I'd tend to think of it as a not well written project. Those aren't the only things I look for, but that's a start for me.

One could also argue, "why does it matter how it's written, it's not a book and it does what I need to do so that's fine." If it works and you don't have to do anything, great. If you have to troubleshoot it because it broke, then hopefully the code is structured in a way that lends itself to debugging. Otherwise, you might end up having a bad time.

For myself I'd say the lodash repo is well written. Would you agree/disagree?

Dave Chapelle - Bird Revelation.

I used to do shows for drug dealers that wanted to clean their money up. One time I did a real good set, and these motherf--kers called me into the back room. They gave me $25,000 in cash […] I jumped on the subway and started heading towards Brooklyn at one o’clock in the morning. Never been that terrified in my life. I’d never in my life had something that somebody else would want. I thought to myself, “Jesus Christ, if motherf--kers knew much money I had in this backpack, they’d kill me for it.” Then I thought: “Holy s00t, what if I had a pu--y on me all the time? That’s what women are dealing with.” […] If those same drug dealers gave me a pu--y and said, “Put it in your backpack and take it to Brooklyn,” I’d be like, “Ni--a, I can’t accept this.”