I am a quite good bad programmer

When I was a Junior dev one of the first lessons my boss taught me was to always always speak up if something looked off to me. Maybe I’d get an explanation and be enlightened or maybe I’d actually sniffed out a mistake or code smell. It always seemed like a win win.

But if the entire job is based on “here swallow this bullshit pill before you’re let in the door”, isn’t it going to be hard to get the devs who are allergic to bullshit?

I'd say it's more a measure of how well you can learn an arbitrary skill. They could change it to solving Sudoku puzzles, grading SAT essays, or wood carving and most of the same people who do well in leetcode interviews would pick up those skills and ace the interviews.

But you don't need arbitrary skills, you need solid development skills to do the job. So they're always going to miss out on people who aren't good at learning arbitrary skills but already have solid development skills. But many big companies seem alright with that tradeoff.

But category theory?

"Tell me your opinion of the emperor's apparel."

A given programmer might blaze through an interview task like a superstar, yet take two days to get started on it if it's an actual job assignment.

Everyone can put on their Gets Shit Done hat in an interview, in other words

That is why interviewers ask questions about previous job experiences and contact references.

That's true, but only because companies are bad at interviewing. It is possible to do much better than companies typically do at this. It's just a really hard skill to master, and involves more than just standardised testing.

>Copy/pastes code snippets from Stack Overflow, Glitch, Codepen, or wherever they find answers.

>Gives credit where credit is due.

>Spends time on things outside of engineering, like hobbies, friends, and family.

>Doesn't act surprised when someone doesn’t know something.

>Willing to admit when they're wrong, and aren't afraid to say "I don't know."

>Doesn't riddicule entire professions within engineering, especially not when in a position of leadership.

Me: “why don’t you just use a hash table here? That array you’re iterating through each time has like 200,000 entries”

Him: “I can’t. I need to be able to get both the key and the value and hash tables don’t store the key”

Me: “…sigh, school has failed us again”

For example:

1. When n is small, an array is almost always better. Arrays have very little overhead compared to even a hash map.

2. Algorithms with the same O() may still have significant differences at runtime and might be balanced differently between insert and search times. AVL trees take longer than Red Black trees to insert, but might be 1 level better in height. That means one less access. Useful for a routing table, for example.

So, in summary, if your looking at other people’s code and see lots of arrays don’t get too smug…n is usually small.

Knowing the theory doesn't mean people apply it in practice.

Some of these places expect your first draft of a weird abstract problem to be perfectly readable in a live coding environment. Without any pressure my first draft is feeling out the problem and then trimming everything up.

In any case I landed at my preferred company, which is very exciting.

The company added a take home project into the interview process retroactively

Said the task would take 2-4 hours

It took me days of research and development

And then I re-did the project in a few hours, simulating github commits to a new repo so they could see the time it took

They graded unknown things

Are you kidding me? The IoC research was probably good experience if you've never seen them before, but yeah you ran into the "easier to criticize than do".

I almost guarantee none of the people involved went through the same interview process where they had to code something for two days. This is how the hazing cycle begins, because everyone thinks "man I had it hard, and my hard experiences forged me, so I'll be really hard on the next round of people".

Dumb idea. That is a conscious thought bubbling up from subconscious "trauma" and humans for whatever reason replay / reinflict their repressed emotional damage on others. I believe this is because trauma makes you feel alone, and it makes a person feel less alone.

But anyway, so the organization hazes people, who then haze the next round even worse, who then haze the next round even more really bad worse.

This basically is what IT interviewing is after 20 years of collective downward spiral hazing.

The military generally has this figured out with basic training. Basic training is basically hazing to toughen up and desensitive normal humans into becoming soldiers. But the military seems to have a policy / training feedback loop that prevents the hazing from getting worse, and staying at the level of psychological impact that they get the desired result from.

Interview gauntlets have a desired result: filter out the chaff, get good candidates. As google itself shows, one of the progenitors (along with MIcrosoft) of the great interview hazing feedback loop, that it doesn't work. The end goal of "good employee/developer" isn't enhanced by the gauntlet/hazing. And yet everyone does worse and worse variants (look at Amazon: people hate working there, and the reputation of a horrible workplace IN IT, not just on the warehouse floor, is now ubiquitous in the industry).

Anyway, fuck our industry interviewing hazing. What a stupid bunch of apes we all are, interviewing in ostensibly a purely mathematical/technical domain has been reduced to a bunch of Lord of the Flies level dystopian human psychology.

Interviewing is a nightmare on both sides of the fence, though. There's a reason why it's a good idea to build up and leverage your network of coworkers.

The Senior Architect that interviewed me asked a question about correct infrastructure state management giving as an example their current infrastructure, giving me a hint that number of environments will grow expenentionally.

Ive shortly explained to him that the architecture they chose will be really hard to maintain when the numbers of environments grow past single digit numbers and a better approach would be to store the state per part of environment.

He got really mad at me for pointing that out (on the meeting were also other ppl) and tried to force me to chose the same approach as he did. I refused and proposed IMHO a better solution.

Long story short - did not get this job. So yes, sometimes ppl will dump you because you are overqualified and not only underqualified.

Being that cut and dry (read: binary) is a problem of its own; and it's probably the more important one to solve.

How they react to that is telling. I've had interviews where they say "great point, that's exactly the kind of thinking we need!" and other interviews where they take it as a challenge to their authority. The latter is of course a red flag and you should excuse yourself from any further interviews.