The most disappointing (not so sure about upsetting) rejection was from none other than Google.

I was ecstatic when Google respond to my application by inviting me to an interview. If I recall rightly I had two pre-interview screenings, two technical interviews, and about four interviews with people. The people were great and the HR person I was dealing with was open that the feedback was all good.

And then the rejection came! I called the HR guy and asked what happened. He said there’s a central group somewhere who approve all hiring and they decided I hadn’t worked for a “big enough” company in the past.

Yet - my potential colleagues and manager thought I could do the job, I passed the Google-scale technical tests … and then some faceless person somewhere says “meh” and that’s that.

It’s not like they didn’t have my resume that whole time, or the opportunity to ask any questions they wanted !

So that sucked.

Story time:

At a precious employer.
Hire shit-hot contractor.
No technical test at interview stage because he’s so shit-hot.
Is a uni lecturer.
PhD in mathematics.

Me: Shit, this guy must be good!

6 months later and a tragedy of errors and clearly misspent company funds later:

Manager: can you look at what x did and merge it into the product?

Me: Sure. *looks* *yells fuck very loudly*

*walks over to manager*

“Soooo... you know those 6 months and thousands and thousands you spent? It’s all for nought. There’s barely anything there, and none of it works.”

Manager: “Shit. What are we going to do? Can you fix it?”

Me: “To be honest, it would be quicker to just do it from scratch than try to work out what he’s done and failed to do.”

Manager: “Fuck. Ok. Go for it.”

I then had to build this entire new lot of systems, a workflow system, a user management and permissions system.

I got it done inside a month or so.

For context, we (the devs) knew something was afoot when the contractor couldn’t work out why his keyboard wasn’t working (it wasn’t plugged in), and he also *really* struggled to find his way around visual studio and git.

The moral of this tale? *always always* screen your candidates. Even if they seem amazing on paper.

He said make me an apk of this website ... lol

So my department is "integrating CI/CD"

Right now, there's a very anti-automation culture in the deployment process, and out of our many applications, almost none have automated testing. And my groups is the only one that uses feature branching - one of the few groups that uses branching at all beyond "master, dev"

So yeah... You could see how this is already ENTIRELY fucked from the very beginning.

First thing they want to do is add better support for a process... Which goes directly against CI/CD.

The process is that to deploy to production (even after it is manually approved by manager), someone in another department needs to press a button to manually deploy. This, as far as I can tell, is for business rule reasons rather than technical ones.

They want us to improve that (the system will stay exactly the same with some streamlined options for said button pressers)

I'm absolutely astounded at the way our management wants to do something but goes in exactly the opposite direction. It's like the found an article of what CI/CD was and then took notes on exactly what not to do.

Pet peeve #91847 - when your non technical manager routinely forwards you articles about technical subjects, usually written by non technical idiots, and says "please see if this is something we should be using".

Yeah, I get that your business manager friend has heard Blockchain is amazing, Rsocket is revolutionary, and everyone should now be using Kafka, but none of that makes any sense for our use case.

The clincher had to be telling me to look at AWS groundstation though. And no, we don't have anything to do with satellites...

Non-technical manager who been managing my team for years: "hey can you take a look at this log?"

*log is all PHP*

Us: "we're iOS devs, none of us know PHP"

Manager: "well why not?"

HOW DO YOU GET PAID MORE THAN US

Does anyone else find it strange that the stupidest people in the company are making all the decisions.

In order to be able to engineer software you have to understand everything that the product owner knows, the business analyst knows, the product manager knows + how to actually make the system both work in a reasonable time frame and be maintainable long-term.

But we're not the one making the decisions. The irony of it is something that I can't get beyond.

And when I do go out on a limb to point out a logical inconsistency to UX or product... They don't thank me for it they hate me for it and then 3 days later figure out that they should be doing it and quietly follow my suggestions.

Seriously is the goal here to create good software or to avoid stepping on everyone else's toes in the company who is overwhelmed by the complexity of the project.

I think companies based on a hierarchy of non-technical people controlling technical people, in the creation of software products are a dying breed.

When it comes to creating software products everyone in the hierarchy should be technically minded.

I've seriously been trying to come up with an alternative perspective here.

The executives of the company are completely out of touch and the only thing which looks like progress to them in a sprint review is something visual on the front end.

The technical architect, the product owner and the product manager all seem to be engaged in keeping the executives happy and managing their expectations. By means of obscuring the truth.

Imagine how much more cost-effective building a software product would be if the executives were engineers themselves.

I'm keen to do an experiment and build a company comprised of engineers only.

Obviously they need to have insight into the other roles. But none of these other roles are as complex as implementation itself.

So why exactly are we the slaves of these well-meaning under thinkers?

The following piece of advice will be for those aspiring for an IT service desk position:

When companies are looking to hire service desk agents, they're primarily looking for socially skilled people with strong communicative skills, rather than primarily technically skilled people. When I first joined the IT world, I went on different interviews for that position and across all of them there was one truth: all the interviewers were eyeballs-focused on my social and communication skills and a mere thin layer of technical skills was required (depending on how technical the service desk). In fact, I immediately got aggressively dismissed twice for two of those when I filled in a Myers-Briggs personality test according to my Sheldon-type personality (selfish, condescending etc). Conversely, when I applied for a new position and I faked that test into answering everything focused positively on the social aspect, I was an immediate top candidate.

Here's a definition from the ITIL Foundation course, chapter Service Management: Because of how lateral the function of the service desk has become today (not only used to solve technical issues, but also company-wide issues), the most important and valued skills when hiring a service desk agent are fully focused on empathy and soft skills and none of those are technical skills. This is because the service desk has people that are the front window of your company and thus you can't make social mistakes as to protect your company's reputation. That risk has to be minimized and you need the ideal people. The people who in fact solve the technical problems are behind a back-office and they are contacted by the service desk agents.

In the beginning, when I did my first service desk job, I also thought: "Oh, I'm going to have to convince them I'm this technical wizard". In the end I got hired for being able to explain technology in human language and because in the interview I successfully communicated and explained ideas to both the team manager and the CEO, not because I knew what goes on inside a computer. This is a very important distinction.
My friends have also been in service desk positions and ironically they were the most successful when they were empathetic slimeballs (saying: "of course, anything for you" while not meaning it, constantly making jokes), rather than people with integrity (those got fired for telling the customer they were wrong while being unfriendly).

I hope this helps.