Hm, out of six interviews I've had in Sweden only a single one did that kind of test. Norm might be an overstatement.
804 karma · joined August 21, 2012
[ my public key: https://keybase.io/jensrantil; my proof: https://keybase.io/jensrantil/sigs/lxsQ3_wfe5J1Akf75bO42UAhjVdv3TPY0WoT01wbMJA ]
1) memcached has excellent support for checking cache hit ratio. Just telnet to it and execute "stats". Most client libraries have support for the stats command, and there is a Prometheus exporter for memcached that works really well.
2) A problem I've seen with Redis is that it is _stateful_. While, "it's still not really any more complicated to install/maintain than memcached" is true for running it locally, I keep seeing over and over again how engineers
i) don't think about backup/restore at all.
ii) expect it to behave like a disk-backed database and don't consider it's limited to the amount of memory you have.
iii) don't consider that it (usually) is a secondary data store that can be out of sync with primary datastore (distributed commits are hard).
iv) don't consider that a proper Redis setup likely needs support for point-in-time recovery and the complexities around that and redundancy/failover.
While Redis is easy to setup as a cache and likely doesn't need the above, I keep seeing them organically grow into being used for other use cases where the above things are not in place, yielding very high operational risks sometimes not acknowledged anywhere.
> Memcached slabs once assigned never change their size.
This is incorrect. Modern versions of Memcached has support for this. See for example [1].
[1] https://www.loginradius.com/blog/async/memcach-memory-manage...
I'm _very_ excited to be a tiny part in helping humanity solve one of our biggest problems.
[1] https://techcrunch.com/2021/06/24/visa-to-acquire-open-banki...
Full disclosure: My employer is Tink.
> 1. We focus on being "no-maintenance", since our primary value prop to customers is "you won't have to spend eng resources on merge problems any more". This means: a one-click "set and forget" install, no additional config files to maintain or DSL to learn, unlike bors.
Bors was a breeze to set up and has been super stable and easy to upgrade. We used their Docker container and you need a PostgreSQL database.
> 2. We have all the security and access-control features you'd want (we're Soc2 compliant, offer on-prem etc). This is important since the product interacts with our customers' source code.
For a monorepo you can get really far using Github's CODEOWNERS file and requiring an approval in bors.toml.
> 3. We offer various customizations on merge workflows to help our customers optimize the exact parameters they care about (eg: developer wait time vs CI costs vs time to identity bad PRs in a batch, optimistic merge heuristics etc)
Nice! One issue we've seen is that a large backlog of PRs that needs to be merged, combined with a failing PR, is that bifurcations can easily build up a large backlog. We've looked at various different strategies to cope with that[1].
[1] https://forum.bors.tech/t/draft-rfc-support-building-batches...
Above said, I really think the _real_ solution to handling large backlogs really lies in speeding up the CI build, not adding even more complexity to handle a backlog. This includes adding caching à-la Earthly[2] et al., but also moving away from heavy integration/system tests etc.
Something that really helps me is coming prepared (including asking for expected outcome of meeting and an agenda - it's not too much to ask for - beforehand) and making sure the meeting sticks to the agenda. By doing so, I can prepare beforehand with notes, and I also make sure that we stick to what I've prepped for. Hope this helps!
The strongest arguments I hear for Jira is that "it can do everything" and "everyone else in the market are using it". Those are null arguments to me.
This is simply not true unless you drink cheap tea bags. Some good teas, for example green, should sit for only 10-20 seconds.
Work/life balance is not necessarily better outside of academia. In fact, my observation it might generally be worse.