4 ms·

Throwaway for obvious reasons. I interviewed at signal a while back, and none of their recent mishaps surprise me. At first, they had me talk to Brian Acton on

Throwaway for obvious reasons. I interviewed at signal a while back, and none of their recent mishaps surprise me. At first, they had me talk to Brian Acton on the phone for about an hour, who seemed to think I was already getting an offer, and he was there to sell me on it. He was cool to talk to, so I didn't mind, but I was surprised at this level of confusion for a company that small. Next, I was given a lengthy take home project (which I was warned not to do in a language other than Java, because Moxie would reject candidates if they didn't pick a language he liked). After I finished it, they disappeared for a month. Apparently I passed. They said I was basically the only one out of 200 people they sent it to that did pass. I assumed this meant I would be getting an offer, but they then wanted me to do a full onsite. The "onsite" weirdly consisted of another take home, but shorter, and a live interview. After not hearing back again for a while, I got an email titled: "Hello from Signal!". Great! I opened it, excited: it was a rejection. I tried to get feedback on why I was rejected but never heard back. The best thing I can come up with: in the system design interview, as a solution to a postgres node being overloaded, I didn't come up with the solution of having a SPOF redis node with a full key scan every 10 minutes acting as an intermediate data store before transferring to postgres. I was told this is how they actually do things. Take this with a grain of salt, since I'm obviously still irked by the experience, but it's all true.

dijit 5y ago
> I didn't come up with the solution of having a SPOF redis node with a full key scan every 10 minutes acting as an intermediate data store before transferring to postgres. Obviously that is bad architecture smell. But if you didn't already know; redis supports high availability through "sentinel"[0]. [0]: https://medium.com/@amila922/redis-sentinel-high-availability-everything-you-need-to-know-from-dev-to-prod-complete-guide-deb198e70ea6#:~:text=Redis%20sentinel%20is%20the%20high,mode%20without%20any%20human%20intervention https://medium.com/@amila922/redis-sentinel-high-availabilit....
- zbentley 5y ago
  Sentinel smears the SPOF out into a redundant (but still memory-backed) system. Backups mitigate the risk of data loss further. AOF can also be used but may cancel out the performance gains. ...and none of those change the fundamental durability/performance tradeoff of the system, nor do they replace a proper scaling strategy for an RDBMS.
zbentley 5y ago
> SPOF redis node with a full key scan every 10 minutes acting as an intermediate data store before transferring to postgres On the one hand, oof. On the other hand, the number of massive software architectures on extremely well-known platforms held together by exactly that system (not an equivalent one, exactly Redis-in-front-of-RDBMS-with-cronjob-flush, no RDB backups, AOF, Sentinel or anything either) I've seen is also depressingly high.

dijit 5y ago

> I didn't come up with the solution of having a SPOF redis node with a full key scan every 10 minutes acting as an intermediate data store before transferring to postgres. Obviously that is bad architecture smell. But if you didn't already know; redis supports high availability through "sentinel"[0]. [0]: https://medium.com/@amila922/redis-sentinel-high-availability-everything-you-need-to-know-from-dev-to-prod-complete-guide-deb198e70ea6#:~:text=Redis%20sentinel%20is%20the%20high,mode%20without%20any%20human%20intervention https://medium.com/@amila922/redis-sentinel-high-availabilit....

zbentley 5y ago
Sentinel smears the SPOF out into a redundant (but still memory-backed) system. Backups mitigate the risk of data loss further. AOF can also be used but may cancel out the performance gains. ...and none of those change the fundamental durability/performance tradeoff of the system, nor do they replace a proper scaling strategy for an RDBMS.

zbentley 5y ago

> SPOF redis node with a full key scan every 10 minutes acting as an intermediate data store before transferring to postgres On the one hand, oof. On the other hand, the number of massive software architectures on extremely well-known platforms held together by exactly that system (not an equivalent one, exactly Redis-in-front-of-RDBMS-with-cronjob-flush, no RDB backups, AOF, Sentinel or anything either) I've seen is also depressingly high.