Ask HN: How to find team with mature testing+CI/CD processes?
After 13 years in the industry, my days of checking out the main branch to find that Billy Bob unknowingly broke the build yesterday are over.
As are my days of being excessively reliant on the Tribe Elders for application knowledge, and being afraid to update existing software to meet changing business needs.
These factors in my question are the best proxy for team skill level and conscientiousness that I can think of.
I aim to limit my job search to jobs with a high (quantifiable) level of automated testing and CI/CD maturity, but the only strategy that comes to mind is filtering for this during initial phone screens. And perhaps setting an Indeed email alert for just the right key words.
I have to think that the best and brightest minds on HN can come up with some much better strategies.
6 comments
[ 3.4 ms ] story [ 28.7 ms ] threadThis opinion might be excessively negative, but I’m coming off an experience where both the manager AND half of the devs on the team were on board, and we almost didn’t manage the needle in 2 years.
And I’ve read of others having to threaten to fire or actually fire team members to get the rest on board.
I will definitely check out SO Careers.
There's an obvious set of prerequisite here:
1. what's your code coverage?
2. what's the branching strategy like (this is a long winded way of asking: are PR branches built automatically?)
3. how frequently do you release?
I guess this could be your "smoke test", without a reasonable code coverage you cannot have the PRs build automatically or a frequent release schedule.
If you ask an HR person about the frequency and get anything less than "frequently" you're likely dealing with an org that doesn't have 1/2/3. It seems unlikely that something like this would make it into a job posting though.
It's not all that great though. I'd say that, since it's usually maintained by devops guys, it's not fully designed with developers in mind. For example, the deployment to a CI is usually unacceptably slow for at least one seeminlgy unfixable reason (or perhaps the devops don't care enough, because the slowness doesn't hurt them as much). So, in practice, the CI is only used to run the automated test suite before the final OK on the merge and before that, you're better off running and testing things manually.
Developer productivity is our priority and the CI system is the foundation of that. (In fact I just spent the entire weekend optimizing the frontend toolchain and development workflow after the lessons learned from onboarding our first hires.)
If you like Python, databases, DevOps, etc. and don’t mind working at an all-remote early startup, please apply! Leave a note in the cover letter section of the form that you saw this comment. :)
[0] https://www.notion.so/splitgraph/Splitgraph-is-Hiring-25b421...
(Job posting also includes more details about the stack.)