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.
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?
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
Row Zero frontend dev here -- when architecting, we looked at some off-the-shelf canvas-based table tools, but ultimately rolled our engine for more control & flexibility with our growing feature set. We elected for canvas over DOM for perf among other reasons (eg DOM scrollbar virtualization is hard when MAX_ROW * ROW_HEIGHT exceeds the maximum allowed browser element height).
Great interview question. Tons of nuance to drawing borders on adjacent cells, how to handle varying thickness, etc. Once you start looking closely, you notice the pixel differences between how this gets handled by various spreadsheeting tools.
Thanks for the report! This one's already on my list actually (selection negation & unique selection deduping) -- look for a fix soon.
Congrats on releasing the product! What are you using instead of the native scroll event of a browser element? Are you listener to `onwheel` events? Have you find a way to keep scrolling momentun scroll-browser/cross-device or do you normalize the delta to +1/-1?
I am the creator of DataGridXL (https://datagridxl.com), an Excel-like data grid component and it uses native scrolling. However, the document/sheet height/width is indeed limited by max div dimensions. Does your spreadsheet have a max?
I don't remember looking at Glide, although it looks really nice & full-featured. I'll have to play around with it sometime. I do remember trying out https://www.npmjs.com/package/@deephaven/grid.
One pivotal feature that is difficult to map onto 3P tools is our data table UI, which is a separate scrollable grid that floats on top of the main sheet. That, combined with the complexity of formula selection, inserting buttons into cells (header dropdowns, filter, sort), led us to decide that rolling our own solution for full control was the right choice.
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?
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.”
While a good metaphor it still misses out easy identification. Women are often easily identifiable as such.
Take that $25000 and strap it to the front of your chest...
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