zmagg

How much prep did you do for the technical interviews?

I get asked this a lot so I thought I'd write it up to share. For context, I was interviewing for staff+ individual contributor roles at tech companies.

Technical Interviews

I was preparing to do some amount of live coding interviews, and some amount of pairing interviews.

Tech setup check-in

My friend Tom offered to do a pairing interview with me, which I also used to check my Zoom / screenshare setup. I screen shared from my 2019 XPS 13 for the pairing, but also had Zoom on an ipad for video/audio. I used Airpods for audio. This setup actually worked great, but it was nice to dial in some of the specifics--mic feedback from dialing in from two places, and just practice my schpiel about explaining what I was doing to the other person. Probably not useful for you unless you too, have Linux problems.

zmagg

Slidedeck

• SLIDES: https://speakerdeck.com/zmagg/fear-of-the-computer

Further Resources

• Carlos Bueno's Mature Optimization http://carlos.bueno.org/optimization/ . A primer on performance engineering practices that is well worth the PDF download. Later chapters talk extensively about instrumentation and how to do it.
• Allison Kaptur's blog post 'Love your bugs'. http://akaptur.com/blog/2017/11/12/love-your-bugs/ . There's a talk version somewhere, not sure about the link. The post is well worth reading to understand Kaptur's contextualization of Carol Dweck's growth mindset research for software engineers, but also Kaptur goes into detail about how awesome server side feature flags are for mitigating the risk of client side releases and changes.
• Dan McKinley's 'Iterative Products Club' talks extensively about the use of feature flags for product development. http://iterative.club/
• There's a lot of writing and resources about resilience in the face of failure, adapative operations practices

zmagg

How to become a supernode

at Etsy, over the course of a few years

Written for my friend Jared

People have identified me as a 'supernode', and I agree that one of the value-adds I bring to Etsy is knowing what's going on in the organization as a whole. This enables me to identify the right person to talk to about a certain problem, and sometimes manifests as me bringing two people together who are working on the same thing (or at cross-purposes) without realizing it.

I've found being a supernode emotionally valuable for feeling connected to the organization as a whole and what we are trying to accomplish. That being said, maintaining many relationships across the organization as a whole and understanding a high level view of what everybody is doing is not realistic in a 1000+ person org, and shouldn't be necessary to get things done in one. Part of the work I aimed to do on the Architecture Review working group, was to make finding the right people to talk to easier for people who did not ha

zmagg

kale salad -- green kale bought from church produce massaged with the olive oil from 24th st cheese company "californiaolivesandoil.com" did not massage long enough, says B. Decided late in the evening to add fried sliced garlic (yum, a nod to my favorite first kale salad in Toronto in the hippy Kensington neighborhood), and some browned bits from the pan after the scallops and bacon cooked and brighten it with some lemon juice.

also had some bacon snack bits. delicious. raw and cooked.

scallops seared a la kenji lopez alt. some wrapped with bacon were good in the sense that their leftover juices in the pan were good, less good in the sense that the scallops themselves appeared dried and tasted dry-er and stringy.

zmagg

1.24

• For the first meetup, please read through page 102 (So that's Chapters 1->4, reading the entirety of the Intro section and the first chapter in the STAMP section that introduces Levesen's model).
• Optionally, also take a look at question 3 in this PDF (shamelessly stolen from the syllabus for course Levesen teaches about systems safety).

2.14

TODO: Are we meeting on V-Day? Could bump to 2.8

• Read 103 -> 211 Chapters 5->7

zmagg

Morning: sneezing starting around 30 min after getting out of bed. No watery eyes
Slight watery eyes upon entering Embarcadero station from the BART.

Feeling fine during the day.

Afternoon: Immediate sneezing upon entering 1611. Very sniffly nose. Took some Allegra around 6pm. 

zmagg

Hey friends,

I'm looking for some advice.

Traditional web companies (Google, Twitter, Facebook) develop interesting infrastructure problems because they reach scaling challenges. Their current stack cannot support the amount of users they're seeing (one way or another), or their advanced feature set to support their product doesn't really work well in their stack, so they write more software to help handle these problems. This is cool! I like infrastructure problems!

I feel more and more at work that, even though we're growing still (ish), we're not growing so fast that we're running into scaling problems. There's no type of cluster at work that can't grow 10x or even 100x for some of them comfortably at this point (with a few caveats).* This makes it incredibly difficult to choose a new problem at work to work on, in my opinion. On top of this, we don't have great feedback loops with the product developers that develop on top of our stack. IMO this is because the stack is "good-ish enough" to ship featur

zmagg

Foundations of Programming
Multivariable Calculus
Data Structures
DiffEQ
Algorithms & Analysis
Discrete Math
Linear Algebra
Computer Organization (hardware class)
Operating Systems

zmagg

I consider myself reasonably OK at leaving projects without quitting, at Etsy. That's an important qualifier, as Etsy as an organization is very comfortable with diving deep to understand code and systems and co-debugging and generally what Julia would call, "becoming wizards together". Because of that, I've not found a lot of organizational pressure to stay on a project as the solo expert when you're ready to leave.

Some strategies I've used that have worked to wrap up work on a project and move onto a new one.

• Go on a vacation. One week is frequently sufficient. Create the bus factor for yourself. Observe the things you do leading up to being gone for a week: probably you're meeting with coworkers to sync knowledge, or writing more documentation, or possibly even presenting exceptionally gnarly part of the system that you worked on. You can preemptively do these things even if you don't go on vacation, but I find being entirely disconnected an important part of demonstrating your trust in other peo

zmagg

omg julia,

Today I learned something about the buffer pool in MySQL that made it seem less like performance black magic! So, before today I knew that the buffer pool was an in-memory cache for MySQL that let you do super fast lookups (especially PK lookups, but maybe only PK lookups (? uncertain on that one)), like, our PK lookups with the BP turned on take microseconds, and they did so even before we moved to SSDs for all our databases [1]. I didn't know ANYTHING about how the buffer pool worked though, other than like, "caching: it makes things faster".

So, today we were doing a routine schema change truncating some old tables. We did a TRUNCATE operations live with all the databases still in configuration serving live traffic [2], because a TRUNCATE essentially does a DROP/CREATE at the table level, instead of row by row (since MySQL 5.1, we're on 5.5), so it's usually reasonably high performance. TURNS OUT, it also does some really not-so-performant cache invalidation on the buffer pool! This