I hired a couple who posted they're seeking employment, and interviewed a few more than that.
2,306 karma · joined December 16, 2012
The problem is at this level, most orgs don't have anyone to really judge or contest competency, so they hire the salesmen rather than the doers and when they don't, they tend to cheap out and just get inexperienced people.
Logically it makes a bunch of sense, though.
Why rebuild yet another platform? Why is your central platform bad? Usually it's not self-service, sometimes it's because it's built in cumbersome ways, other times its because it actually enforces good standards on you rather than just giving app your apps admin.
It's difficult for the person who hires the core team to differentiate between those complaints, unless they themselves both have the technical competency and the empathy to really understand the problem. They usually don't.
Point being, done well, it's great, but most folks can't do it well.
In the 1-5 guide, I'd probabably rate myself a 99 or something silly. I feel like the equipment is capable of visualising, but I just don't know how to operate it.
However, I do have involuntary visualizations. My dreams are images, very unlike thought. And in the last 5 or so years I can recall 2 occasions where I was in a relaxed state and pictured things without really trying, so I know it's possible to have dream like images when awake.
My wife says she can just perfect recall stuff. I entirly believe she can visualise, but I believe she confuses what happened with what she can see. She also states she can visualise the apple, or pretty much anything else she wants.
Add in a fold, and some folks could probably live with a single device across all use-cases, and it'd simply be better because of not needed to sync files.
It might not be good, but not because the idea is bad.
Take for example a diet that causes gut problems, which then causes anxiety to manifest physically, which result in anti-depressant medication, which you guessed it, cause gut problems.
However, when a raise in mental-health issues correlate with a an inequality crisis, de-funding of mental health services, and lowering of national food standards ( UK, Brexit, Austerity ), maybe it's not so much that we can't sit in offices, but rather balance has simply been stripped for profit.
agile had a lot of promise, though is definitely biased towards working with external devs, but in practice, in my experience, is boils down to the DM and PM roles turning the team into a feature factory 9/10 times.
That said, it isn't really about agile, it's about the specific people, and how suddenly adopting some framework doesn't really change them or their incentives.
It's really good for a consultancy to churn through developers whilst billing hourly / daily, but less so if you want to build a product, or actual productivity.
That's not to say there's nothing good about agile, but when your average team consists of a Delivery Manager constantly applying pressure and Product Manager with no tech skills deciding what gets worked on, it's immediately obvious nothing actually changed.
Of course, this doesn't mean I've discovered 100% of the cheaters, just the obvious ones.
> Also, I'm curious: do you think having them discuss their solution in depth would have been a good countermeasure?
To some degree. But not everyone communicates as well as they code or vice versa, and then it comes to what you're trying to qualify.
However, counter point, I've had people forced on me through much of my career who just can't code for the most part, and despite being pretty reasonable about it ( it's part of the nature of the work I do ), I'm very rarely surprised by competency.
For north of $2m over your career, cheating probably is the smart thing to do, especially for a borderline candidate, as there's a fair amount of evidence that the prestige on your CV will make things easier going forward.
However, my problem with take homes was never that the candidate would cheat, but rather they'll probably spend way more time than the 2 hours allocated.
I'm actually less worried about the candidate doing that, than I'm worried that the interviewer bakes in a bunch of assumptions like having a machine setup to do the task, having the specific domain knowledge and experience, and then accidentally trolls the candidate with little to no avenue for feedback.
Further still, I get push back with folks citing self-prescribed medical conditions, but the same people generally display the same behaviours during the working day.
So other than contract to hire, which typically limits you to people with a job, I don't personally have a better way.
The reality is, fizz buzz got us 75% of the way there. It turns out when pressed, a lot of people can't write code. Yes, there's false positives, but there's also people brute focing their way through via copy & paste.
This doesn't manifest as a person who can't do any task, just as a person that's slow, delivers weird abstractions, and would take a lot of your time to get anything useful from.
But those people are also making those arguments, because, as you said, there's hundreds of thousands of dollars in it.
Lots of orgs fail to turn money into talent and then talent into products.
It just takes one bad hire at senior level and suddenly your cloud is a vmware install where all machines are boot off network disk, and contention makes the entire thing fall over.
https://docs.github.com/en/actions/deployment/security-harde...
You can do same with gitlab. Technically you don't need vault, you can auth direct to aws, azure, etc.
So what actually should happen here is your pipeline mints a JWT token with some near term expiry per run.
You send that token to vaults JWT endpoint, and it validates that it knows the issuer and the signature matches the provided keys.
When configuring the vault side, you can further validate the signed token data which will include things like the scm org, the repository name, the actor ( user who made the commit ), whether or not it's a PR, what branch it's against, whether the repository is private.
From there you can set roles within vault that allows different policy per risk, i.e. random PRs from the public shouldn't get deployment secrets.
Setup GitHub app. Install the arc helm charts. Install a buildkitd statefulset.
Update parans on build to use buildkitd.
That's not to say there aren't better caching strategies, but a really basic ephemeral setup is right there.
That's the thing about a framework of freedoms. In anarchy, the strong will subjugate the weak, and thus only the strong are free.
Thus if we want to protect your right to not be shot, we need to prohibit someones right to shoot you, and in some societies that extends to your right to bare arms with actual positive outcomes behind it.
The reality is, at some point, having repos that are hundreds of GB with hundreds of active PRs also has its own downsides that requires tooling and workflows to combat. Meanwhile, splitting it all up introduces integration problems.
It's definitely pick your poison, though specific requirements and circumstances make specific paths more or less potent.
If you drop a library for internal usage only and you want to change the contract, and the tests, library, and api are all in the same repo, you just change them in a single PR and that's done. This works because the single commit hash contains all information. It requires people put their code in the monorepo and hookup their tests, but assuming they do, you can build a reasonable degree of confidence on a green build.
Once you separate the library different repo, and let people consume that as something in their own repos, you need to do the versioning dance as you have no idea if their still is still working.
A lot of people go for the latter because it contextually allows them to ignore the rest of the stack, and there are some pros to doing this, but testing, deploying, versioning, etc, all become more difficult, and that's something struggle with.
Thus, unless you have a crap load of code / commits, monorepos arguably have more advantages than disadvantages.
Sure, your compiler, your hardware, or your distro might be compromised, but if you follow the chain all the way through you does indeed validate version X does result in SHA y, there's now less things were blindly trusting.
It also helps with things like rolling back to earlier versions when you don't still have the binary kicking around without having to revalidate the binary.
If you're not getting the same SHA on different hardware, weeks apart, even if it's good enough for you, it's not reproducible