svyatoslavpavl

The best interview I ever had, they handed me a small bug in their real codebase and we fixed it together. No whiteboard, no trick questions. It felt like a normal work day sitting next to a coworker, and that was a big reason I took the offer.

I try to do the same now when I interview people. Pick something that is actually broken, sit next to them, and see how we think through it together. You learn way more than you do from leetcode, and the person is not miserable the whole time.

One small thing that helps a lot: tell them up front it is fine to google stuff and ask me questions. Takes the pressure off, and it is a lot closer to how the job really works.

their front page still lists unix shell access and even national dialup. 36 years on and the product page barely needed to change

The protocol is still their stripped down XMPP dialect, yeah. I meant the server side: they rewrote most of the original ejabberd over the years, but it stayed Erlang.

Jitsi Meet still runs on XMPP, Prosody handles the signaling. WhatsApp also started life as a patched ejabberd.

hadn't thought of building forward like that. being able to test each slice before committing beats finding out after the rebase that half of them don't compile. thanks, stealing this

The bit that made this click for me: it works on any commit in history, not just HEAD. Mark the commit as edit in git rebase -i, then git reset HEAD^ to uncommit it while keeping the changes in the working tree, and rebuild the pieces from there.

git add -p is the real workhorse for the rebuild: s splits a hunk into smaller ones, and e lets you hand-edit the hunk when the boundary doesn't fall on clean line breaks. Stage a coherent slice, git commit, repeat until the tree is empty, then git rebase --continue. The rebase's only job is to drop you at the right spot; add -p does the actual splitting.