Speed is a big deal for us too. The entire thing can be built from clean in ~3 minutes by GH action workers. We buy our developers threadripper workstations, so local rebuild times of the solution during typical development iterations are closer to 15 seconds. We are much more interested in developer ergonomics than with simulating prod environment.
I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.
This, a thousand times. Anything after 30 seconds is where you start to lose your focus, and your work output suffers for it.
I care mostly about cached build time. A clean build time of eg. 1h does not bother me.
Now I am/have been on both sides of this.
I happen to like take home for devs. I like it because it takes out some of the stress of interviewing. If done right. I have been advocating internally at my company for stripping down the take home test. Who wants to do a "this should take you 4-8 hours" test? Which nobody internally actually tried to do themselves in that timeframe. Nobody! Especially not if you have a job at the moment. And a family. But want to take advantage of the market and/or look for a better company.
What do I look for in a take home?
Not running code! I couldn't care less! I have never in my life run up a take home test someone sent in (backend). I look for code cleanliness, consistency, abstractions, DRY, WHY comments. If you send in something without any tests you are out. If you have a hundred tests to show 'you do tests', you are out. If you have 5 tests that are of awesome quality and show that you know what is worth testing and how to write tests that will survive a refactoring of the code and actually tell you that your refactoring didn't break anything I will hire you and pay you money to write a hundred of those tests when it actually matters. Maybe add a comment that you could write the same kind of tests for the rest of the code but your kid needed a good night song and the deadline for the test was up.
I was hired on such a take home. My code deliberately did not run. I called out to external services that I did not bother to include in the take home test because it asked to solve the problem and I knew they used microservices. And business wise those things should've been handled in those other microservices and not the one I was writing. I also left out the database. Not worth even an h2 in pom.xml. They happened to use gradle. They didn't care I used maven. Still love them for it. Had the best interview ever. Loved the pros and cons discussion with my interviewer. Awesome guy.
Now depending on what position you get hired for this might change. An architect position for example a whiteboarding session might be more appropriate. Just have a problem to solve (e.g. one of your own main use cases) and have them design it with you. Who cares if they come up with the same solution you did. It's about the discussion. The pros and cons. The general attitude towards solving the problem. If they admit they don't have the answer to something off hand but its a 'googleable thing' they've just never had to solve before, that's fine!
1) we want the time investment to be <4 hours
2) the test uses public APIs and is directly related to our work (crypto)
3) we had the team (mine) do the test themselves before making it official
4) we also are looking for things like tests, thoughtful architecture, etc. It's hard for a junior dev to fake well structured and organized code because it takes experience and thought to do it that way.
If I were interviewing I would much prefer a take home rather than an in person leetcode interview. I also don't mind in person pair programming (like help us fix the bug in this code or whatever).
It's tricky, because this can vary within one person across time. For example, in my area (DS), i think that the take-home gives the best signal for the actual work (as long as its well scoped).
But, as a parent of a small child, I'd much prefer to just do in-person tests/discussions as it takes less time away from my family.
So it's hard, and whatever you choose will lead to you missing good candidates.
Unfortunately, as in many areas, there's no silver bullet.
Saying that "monorepos are only good for large scale" is pure bullshit, and something that only someone very inexperienced would say.
I'm in a very small company (less than 10 devs) but we still use a monorepo, because we have a set of common libraries for all our products, and having a monorepo helps us update those libraries without breaking anything. On the other hand, some very large companies have tried and have failed.
Monorepos are just a tool. The implementation and the context matters more than anything else.
Monorepo forces the tough conversations. Maybe the organization should only use 1 language now. Maybe we should talk about code review policies and standardization of other processes since everyone is in the same bucket. Why can't everything just compile to 1 exe?
Another massive advantage with a monorepo if you use GitHub is that you now have 1 issue bucket that covers the entire enterprise. Linking issues to commits is super powerful when this technique covers 100% of your code and exists under 1 labeling scope.
You have to understand, many of us think microservices is a stupid idea, so the fact that the core of your argument is "monorepos make microservices difficult" is not an appealing argument.
If a monorepo puts a barrier in the way of turning everything into a microservice, then all the better, as far as I'm concerned.
Container based solutions become harder? Again… build your artifacts and deploy all the containers you want? What is so hard about this?
Meanwhile, with multi-repo you lose out on a whole host of opportunities to robustly track dependencies and keep things up to date.
Everything in software is about dependencies, and monorepos are playing double or nothing with dependencies.
The issue with Monorepos is that they can amplify bad decisions and tech debt. Any bad decisions are magnified across the organization. But they definitely don't make it easier or harder to make that initial bad decision.
The upside is that dependencies are just there and not hidden behind interfaces.
The downside is that a bad dependency cannot be abstracted behind a micro-service interface. Once it's out in the wild it can do crazy things.
not liking microservices myself but - if I did this wouldn't it mean that the code in version 19 was now removed from the code in version 18 and back in git history making it more difficult to figure out just where things went wrong on a difficult little edge case.
git bisect helps to easily identify hard to find but reproducible bugs. Since we try to have small PRs once you found the breaking commit it is usually easy enough to the find the bug. Murphy and exceptions obviously apply.
You trade simplicity of having everything in one place vs. ability to independently version pieces at the cost of more complex tooling and build systems required to test.
Usually there's some sweet spot, but the answer isn't obvious and one isn't clearly better.
We do not version our services in that sense. It's a monorepo after all.
We do have microservices.
We use kubernetes.
Deployment is a breeze. Only services with changes are actually deployed.
We do hourly deploys to production.
None of the issues you describe apply here and the monorepo works awesomely for us. This is a SaaS situation where all services making up that SaaS solution and that we host are in that monorepo.
YMMV if you are in a different situation such as having to ship versioned software for customers to self host/install for example. Our accompanying software that is usable in conjunction with the SaaS solution is not part of that Monorepo and each of those are versioned and deployed to various external marketplaces.
That is way different from providing v1 of your API and changes come out in v2 of the API while you also still provide v1 of the same API. You can (and we do) do that perfectly well with or without a monorepo. Mostly for the public API. Internal API's often don't need to do versioning and one can go with backwards compatible changes and/or rolling a change out over multiple commit deploy cycles.
Some of this will depend on your size I suppose. The larger the org, the more services etc. the more stable versioning I would suppose happening.
Which is why I said in my original comment this may work fine in a small environment, but it won’t scale well.
That said, we're not small either. In our niche, which you might recognize if I said more, we're the top solution customers choose (but I won't go into much more detail than that for obvious reasons).
Just know though, that there are different places out there. I surely am tempting Murphy right now. Please recognize my sacrifice.
My current place is rather good in this regard. People actually care. The Devs genuinely care about both their work environment and code base. We actively try to hire other people that care and not let in the ones that don't.
We do hire 'inexperienced' as well but that doesn't mean you gotta take bad dev experience. For example I have a really 'inexperienced' guy on my team. But we hire him anyway because he showed signs of 'caring' during the interview and coding challenge (take home - I know what you think. It's different than you think and I'd be happy to elaborate if you want to). He is awesome! I try as hard as I can to give him the space to be awesome and not let the 'bad parts' of the company (which exist even in awesome companies) reach and discourage him (and others like him).
We keep our builds fast, we spend a bunch of money on giving every dev a prod like environment. A monorepo.