The "job interview questions" are largely popularized by people who do not understand hiring, and probably don't understand much of anything else, with a cargo cult mindless copy/paste of practices that don't actually apply to them.

There is a niche of a niche of a niche of roles where deep specialized knowledge is actually a baseline requirement in order to be successful in the role. 99% of the other roles filled by human beings who write software don't require anything close to it, but the companies delight in wasting everyone's time anyway.

Most of the very best programmers I've ever known bomb these idiotic interviews and the companies (and their customers) lose because of it.

A fine place for me to stop babbling.

I also don't mind leetcode, strictly as a way to learn esoteric algorithms that don't show up in 99% of crud engineering. It's also a fun game. aka facebook quizes for nerds.

But you can't just do the 75 blind questions and be done. You have to scope out the questions that a company is known for asking and commit those to memory, since everyone else is doing it. Last night I had to re-learn matrix operations and memorize how to do them for a company. I loved linear algebra, ...back in the day.

And I just had to laugh last night at the absurdity. "In what world would anyone implement their own matrix operations? Why the fuck am I being judged on coding in a shitty web ide and ability to sight read code like im at some fucking nerd recital? I should be able to use an ide with a debugger dammit"

Instead of just following my passion and intense desire to build my project, which incidentaly should be the same skills a good hire should have, I have to pull myself away from "real" engineering, in order to focus on gaming the test like I was taking the SATs again.

In any world where their matrices are "special" -- big, small, scattered across the internet, high read/write ratio, informationally independent columns with 0.01% error tolerable, poorly conditioned, blockwise sparse, used as a sub-component in differentiating anything hairy (like a function of eigenvalues), ....

You can often get halfway decent results stringing together existing matrix primitives, but throw in a 50 clock cycle latency budget, a $5k per-job compute budget, or all sorts of other constraints and you're just as likely to find >>10x performance that you left lying on the table (assuming your matrices are at all special, which is common but not at all guaranteed in arbitrary domains).

They may not quite understand their development or deployment environment but their knowledge of writing segment tree as a single dimension array in 15 minute is somehow essential to scaling the internal CRUD app these people end up working on.

Now everyone being interviewed by this person has to know by heart or magically derive on spot how to find minimum steps to obtain maximum length palindrome subsequence of even length from a string consisting of lower case letters, because apparently it's the gist of all computer science knowledge a developer will need.

It also seems sort of contradictory... if experience in the field is one of the most important criteria, why are they implicitly avoiding testing for that?

That's easy. No one wants to hire "olds."

Since companies are now run by twenty-something CEOs, no one wants to hire people that make the CEO uncomfortable.

It really is that simple. Basic bigotry. In my experience, many companies don't even try to hide it. Recruiters are awful.

I just learned that if I see a binary tree problem, the company is just yanking my chain. It's not worth trying.

I’m in my late 30s. Not too far from being older than many tech CEOs and I have seen plenty of BS I could call out.

I have a family, mortgage, and am not “wowed” by some slick CEO.

However, there's a big difference between brilliance, and good judgment.

Good judgment comes from experience. Experience comes from bad judgment.

When a CEO makes a mistake, there's usually only one strike, and you're out (we won't talk about Steve Jobs, though -that SOB had nine lives). When lower-level managers make mistakes, it's often recoverable.

Until recently, it was fairly common for corporations to be run by folks (usually men, but that's another issue) in their fifties.

These folks had no problems considering older folks on their merits (which often included price). If they discriminated against older folks, it was usually because they didn't want to pay for something. It wasn't really personal (but that doesn't make it any less reprehensible). Younger folks, on the other hand, bring in the younger generation's resentment against their elders, so it is personal.

Many folks think that only younger folks are creative. I'd not argue that youth doesn't have a great deal of creative energy; mostly because they haven't encountered limitations, imposed by things like the laws of physics.

Creativity, however, does not equal results. What SpaceX has done with reusable boosters, is awesome. I do not know the details, but I'll bet the team that developed it was not just a bunch of enthusiastic kids. I'll lay odds there's a lot of well-coiffed grey pompadours in that team.

IBM is in hot water, because they adopted a "cargo cult" mentality, that, if they hired enough younger folks (and got rid of their "olds"), they'd magically transform into a startup unicorn.

I don't think that strategy has actually worked out too well.

Works for me, but I have different ambitions from most folks in the industry.

I've never really wanted to be rich. It would be nice, but it's never been a need.

I do, however, have skills that could make other people rich. They have been so fixated on my gray hair, though, that they never even realized that.

Now I went through with them some extra things in the interview and fixed some things about the code and handled some things a bit better. After this investment of time I was told I didn’t handle errors well enough in this 100% coverage tested example code of a library. This in my opinion was not true or even discussed in the interview, error handling was certainly not specifically mentioned in the assignment.

Anyway to address your point, I don’t think you should necessarily believe what other people say about you in job interviews; there are various types of interviewer but mostly the feedback is post rationalisation of “that’s not how I would have done it” even if your solution solves the problem perfectly. For this reason I’ve decided unless I can’t afford to feed myself I will avoid doing at home coding exercises that are deliberately vague in the future.

If you want to get better at in person/under pressure coding exercises I highly recommend taking on Advent of Code [1] one year, these are the opposite of the vague problem specified above as there is an exact and clear right answer to collect each star.

[1] https://adventofcode.com/

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.

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 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.

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

I always view assignments and live coding in interviews as a startup that has runway of an hour or two. Would error handling help this startup survive another day? No. But properly covering the main use case - may in fact be.

It's fair to want the candidate to mention the edge cases and tests for it in the end verbally, there I agree. But expecting 120% performance giving out vaguely formulated problems with extreme time constraints and the pressure of an interview to me seems almost delusional.

I did this for a while and realized that it typically panicked the people we were interviewing, especially if they were on the junior/mid side of things and as a result, gave lower-quality answers.

> I would also expect error handling to be addressed in any piece of software written for any purpose

I guess it depends on what people are hiring for but in the long list of things I need out of that person, this ends up lower on the list

I would consider this an assumed skill for any developer with a college degree. It’s basically the point of the entire Data Structures class, which is a degree requirement.

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.

weirdly, in all my recent algorithm work, only the big-O has mattered (or it's all just NP-hard or even EXPTIME.)

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”

Now I'm wondering about something like:

  MutableHashMap<MutableKey<T1>, Value<T2>>

  Entry<MutableKey<String>, Value<SomeEntity>> entry = mutableHashMap.getEntryByKey("myKey");
  entry.setKey("myNewKey");

The only problem would be that depending on the language you're using, you wouldn't change the objects directly, but would use those containers and it would essentially just be some boilerplate around a regular hash map. For example, Java has MutableInt and similar classes, which here would be hooked up to the MutableHashMap that they belong to.

Then again, I can't come up with many cases where something like that would be nice to have, since if you want to "change" a key, you can just do the following manually:

  var ourValue = myHashMap.get("myKey");
  myHashMap.remove("myKey");
  myHashMap.put("myNewKey", ourValue);

> 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”

How could he do well in the data structures class? This is the definition of a hash map or hashed dictionary, so this is basic knowledge of data structures that is taught in this class and central to know to even have a chance of passing the exam.

In practice it's not the case, but very technically from a purely theoretical standpoint, I think he's right.

EDIT: untrue on any finite sized array, due to collisions. See below, and sorry for the brain fart!

> There's no theoretical way for a hash map to work without storing the key - the reason for that is hash collisions in presence of which you do need to run equality comparison with stored keys otherwise you would overwrite data just because of hash clashes.

There's a ton of material in a Data Structures course. I'm sure the point about storing the key was mentioned at some point, but it's not the focus when talking about different hashing strategies etc. For people with a bunch of experience (e.g. I'd been writing Perl for years before this, so being able to iterate across a hash and get (k,v) pairs was obvious) it's a detail that is already there in your brain, but if the DS course is your first exposure to a hash map, it's a detail that can easily get lost in the huge forest of other brand new things to learn.

My experience differs: It is the common situation that the theory is taught in the lecture, and then each week you have to do quite some exercises to implement all the newly learned data structures in code (lots of work to do each week :-) ). So, if you forgot such a "detail", the code to write for next week simply won't work - 0 points.

This way, it is rather unlikely that you will forget such a "detail" in the forest of new things to learn. This statement in particular holds for students who had done pretty well in DS as the one you are talking about.

I loved it all and had a great time. Lots of people really did not.

> So, if you forgot such a “detail”…

Sure, very true in the short term. Next semester though? That code doesn’t matter and most people don’t have flawless long term memory.

Besides, just because you are storing the keys, it doesn't mean it is viable to retrieve them. On the collision aware maps you see on CS, iterating through the keys is extremely inefficient.

The OP's description is clearly somebody that has learned the theory, but don't have any practical knowledge.

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

It's worth knowing that while you have successfully articulated everything, some people will still see your mistakes as red flags for future communication. Some might even assume that you will be making trivial code mistakes, too; despite there being no evidence of that.

That kind of prejudice is common, and difficult to confront.

There is no real need for you to improve your English skills: your writing isn't ambiguous or missing anything. Even so, it's worth recognizing the social dynamic that is likely to happen, and how that affects you.

Unfortunately, we can't expect all the people we work with to overcome their prejudices, so it's probably still useful for you to improve your English skills.

It's nothing personal, but many developers tend to think about their skills higher than they are in reality.

What i can suggest you, is to ask for feedback after interviews. You will get more specifics there

EDIT: I forgot to actually add a verb in the first sentence and some punctation

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?

Maybe that’s what they want, namely a self selection of devs who will be happy and okay inside an org that is filled with bullshit.

Mostly it selects for people who can turn this on when needed, which honestly is a critical skill. Sometimes life is just bullshit, either you're a person who makes that easier for everyone or you're a person who makes that harder for everyone. But an inability to get past it is a red flag.

(if it is not explcitly defined, and there is state based behaviour, it is by definition then implicit)

At the moment I'm trying to overcome the inertia on this issue in the general process/industry sector with child standards from IEC 61508 - 61511 and 62061.

I am guesssing you apply the medical standards IEC 60601?

Or at design of devices at component level then IEC 61508?

Interested to know how it fits in to the overall Functional Safety approach.

This is exactly the reason why any big enough company is eventually going to s*hit

And why founding team doesn’t stay long in a successful startup.

Doesn't the founding team get to determine the hiring practices?

One of the factors — it’s too risky for a big company not to hire based on obedience.

Let's be real, that's exactly what most mid+ companies are looking for.

This is what makes you successful in some large organizations, unfortunately.

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.

Time is finite. You can learn to write better programs, or grind Leetcode. Leetcode interviews favor the one who can put enough time on the latter.

A better explaination is it's a chain reaction. People who know only to Leetcode enter the industry, and ask only Leetcode questions.

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

> I never "studied" computer science in a regular way,

You never really mentioned algorithms, and your only mention of data structures was "usage of [hash tables] instead of searching arrays and many other small things that actually enhance the code performance."

While you don't need them all the time, a good understanding of common data structures and algorithms will make you a better engineer, and I suspect this is the weakness they're seeing.

This is a common example of a real-world programming. Algos and DS’s make you a better engineer in vitro, but whether they do that in situ is an open question.

As a personal anecdote, I helped businesses to calculate and automate things for 15 years and only once had to use something “advanced” like makeshift BFS (it was a production planning system in a plastics factory that could pick up from any state of shops and inventories and tell which positions/qtys to order to meet the plan). All other algo/data magic is usually behind RDBMS and other well-tested systems.

I don’t think it is worth anyones time to learn to pattern-detect and/or implement these things, except when it is a literal job description. Just being aware that they exist and having some programmer-level intelligence for search is enough, imo.

I did a coding assignment.

I was asked to read two xml files, one with data, one with operations, and perform the operations on the data.

The task was deliberately unclear and suggested to not use third party software.

So I did the thing and wrote an xml parser.

I documented my decisions in design etc.

Later I found out that one could have used any third party XML reader package.

I was declined for other reasons but when asking for feedback on my code, all I got was: You did not check for divisions by zero.

I am still wondering what skill they actually wanted to test with the coding assignment.

Which is correct, since I didn't use rails, I used Sinatra.

Lots of folks, that I know aren't especially good (because I've looked at their work), take great joy in telling me how bad I am, which they seem to know, without looking at any of my work, so I guess I'm just terrible.

That's one reason I don't bother being competitive. "Good" is in the eye of the beholder.

If someone comments their code, that can be "good," for some, and "bad," for others.

If someone adds extensive, nested error handling, that's "good," for some, and "bad," for others.

And so on...

Usually, both sides have quite valid points.

I just do things the way that I do them. Seems to work.

WFM, YMMV.

"Huh, maybe I don't know how to program. I thought I'd been programming functioning applications professsionally all this time, but despite all evidence to the contrary, maybe not!"

The problem is with the interview process, not you. More broadly, the problem is with the industry and its incentives, not you.

If I had to put my finger on it, I'd say it's the need to scale everything, including human processes like finding new team members. Nobody doubts that spending a lot of time really getting to know a programmer's strengths and weaknesses would be better, but we'd have to sacrifice a lot of throughput in the hiring process, and god forbid we do that.

For example:

> 80/20 solution say "80 want with 20 code" solution maybe not have all bell-whistle that project manager want, maybe a little ugly, but work and deliver most value, and keep demon complexity spirit at bay for most part to extent

In some cases, shipping "good enough" solutions won't work when you have a specification with acceptance criteria laid out and QA will be stalwart in their efforts to check every single one of those. Thus, things won't be "done" until everything really is in place, which depends on the work environment.

A few years ago I was applying to a well-known consulting firm, a role in data analytics. I got rejected due to "not knowing SQL" (which at that point I've used professionally for 8 years) and they hired someone else. A few months later, the same company made me an offer for another team in a more business driven role. I've ended up as a lead solution architect for a pretty involved WASM-based product with them and managing the guy they hired instead of me before. The guy couldn't code a for-loop in Python and I ended up doing all the engineering work for him until we could offboard him.

Moral of the story: perceptions, culture, and internal team politics might play a way bigger role in seeing your value as an engineer than we might acknowledge.

Some companies have a more straight forward interview process. Try to stay away from big companies. There are startups paying very well.

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.

Now to be fair to them, I was asked to do a certain task and I failed to do that task. It's pretty cut and dry.

But I also walked away glad they turned me down, because if they're going to try and force me to do something a specific way when that way is inefficient, or troublesome or just plain not the best answer, then I wouldn't really want to be working there anyway.

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.

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

KISS is “keep it simple, stupid”: https://en.wikipedia.org/wiki/KISS_principle

With that said, coding interviews are a skill and like any skill it can be learnt. Keep going, read Cracking The Coding Interview, practice leetcode and make notes of every question you feel you answered badly and make sure the next person who asks it gets a better answer.

I've given dozens of interviews over the past 3 years. I'm fairly certain everyone got out of the interview with me feeling like they did very poorly, when in fact a lot of people were doing well. All of the people I ended up hiring told me "I was sure I completely failed your interview".

You don't know what interviewers are looking for, so don't make assumptions. I'm almost never looking for a "correct" answer. I'm always looking for your behavior and attitude when answering those questions. My definition of a good programmer is someone who understands that it's a team sports, who values clear communication and who knows how to read the doc on their own. You may or may not have implemented your own lisp in your spare time, but this is secondary.

If you ask me to review the quality of your code, I'll spend more time reading your commit messages and variable names, than you realize. It's as important as the choice of algorithm and data structure.

Other interviewers value other things. There's no one thing.

TLDR: You don't know how well you did in interviews, it's very likely you're better than you think.

Do you have to get every job? You do not. You just need to find one that suits you and where you will be successful, and everything else is meaningless. But don't completely reject the feedback -- try to understand what is causing you to be unsuccessful in interview to get better at it and hopefully improve your chances of getting the job you want.

Interview questions (and I say this being an interviewer and having interviewed thousands of candidates) do not tell if you are a good programmer though they can tell if you are a bad one. Even then, one has to recognise that selection of questions is going to shape the definition of what good and bad is.

There is also no single definition of a good and bad developer is. Different types of jobs require different types of people. I have hired for positions where I needed a dull, ambitionless person that can take boring tasks day after day without complaint. If I saw a candidate with even a hint of ambition I would immediately tell them no because there was no way they would stay on the job for long.

My advices:

- Find your niche, find what you are good at AND gives you joy or at least satisfaction that you know you can be doing well and have others at least potentially recognise you for this.

- Know your limits. Do not try to get hired over your abilities unless you do it with intention of stressing yourself to get better in the end (know why you are doing it).

- Set up a periodic review of what you are doing, what is not going well and what you can do to be better at your job.

I, myself, found that I am perfectionist and able to write perfect code, fast, reliable, but with the downside that it takes forever to get anything done.

I decided early on that I will be working on projects that benefit from being perfectionist and that I will immediately reject any project where there just isn't any business case of polishing your code. So no websites, no UIs, no startups, etc. I am working on backends for critical corporate systems.

Say no more, you're hired.

It's a game of quick matching (what polynomial time alg comes close to solving this), then quick coding (how do I translate the input to something that alg can solve). Do that over and over and you're an excellent interviewee.

When I was a boy, practitioners of such things were called Systems Analysts, and may well have never coded.

There are great websites where you can practice technical interview questions. Leetcode, etc. When I'm getting ready for interviews I keep a practice journal and build a deck of flashcards. I use the practice journal to categorize the problems I work on, how long it took me, how many times I've practiced that problem, notes on my solutions, etc. I try to cover the 5 most common solution types: _depth first search_, _breadth first search_, _binary search_, _two pointers_, and _dynamic programming_. Review the most common data structures and their look up times. And I use the flashcards to test my reading comprehension: I put the problem description on the card and the answer is which algorithm should be used to solve it.

This gets me through 90% of interview exercises. Occasionally you get hit with a smart aleck who will try to blind-side you with an optimization problem after a hard dynamic algorithm. It's good to have some breadth in your knowledge of special data structures like heaps, k-d trees, and the like but I wouldn't waste too much time on them unless you know ahead of time that the company you really, really want to work for is likely to ask these sorts of questions. I try to book those companies for the end of a round so that I have time to warm up before I get to the ones I really want (and need to practice harder for).

Like with any skill, practice helps. It sounds like you dont really care that you dont do exceptionally well at interview. But if you wanted to improve that skill you could focus some time on it.

Think of another skill you only use once every year or two. You are not going to be fantastic at it. I've played a lot of basketball in my life but only play in games ever year or two when I happen to be with folks who have a regular game. Now I'm in pretty decent shape so in general I do okay but the actual skills of playing basketball are rusty so I'm going to be a 5-7 out of 10. If I played basketball everyday I would probably be a 7-8 out of ten.

The same goes for interviewing. You are coding regularly so you have some of the prerequisites for doing well in interviews but without practicing typical interview type questions you will not excel at them. If you did 100 interviews over the next year I'm sure you would start to see patterns, improve on your weaknesses, and be closer to a 10 than a 5. It's a skill you have to work on outside of just coding if you want to be a great interviewee.

The problem I think is that although there's harm done to the company in losing out on good engineers, the cost isn't attributable to individuals in the hiring chain. That cost is difused over time to everyone else and there's no accoutability. The next best alternative, the ones who could jump through the hoops will tend to be just as any other on average.

I think I have a pretty good sense of who the legitimate good vs bad engineers are. I'm always checking up on people we've denied or people I thought were bad but was overruled on. I'm not perfect but I have a better record than the teams in general. But that's because I have a vested interest in making the team good. The hr people, they don't really care since their incentives are just to get people funelling into the roles, and they have so many applicants that they have to rely on ai to auto filter, which is shit at finding real quality.

Good football players train for games, do well in games, and are hireable as long as they do well in their primary activity: playing and winning games. Good engineers CANNOT be hired unless they do training in a totally tangential direction, unless their job is literally algorithms all day working on a kernel team or something.

Thanks to interview prep, lots of people are good at interviewing, and terrible at their jobs.

>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.

Companies need those 10xdevs because they are bloated with dead weight.

But office politics make it very hard to cut that dead weight.

Anyway, I've worked with plenty of people who can get stuff done, and I've been able to get stuff done myself sometimes. However, it's all relative and if I'd been at Xerox Parc in the 70s I'd have been a 0.001 for sure.

this is the bizarre thing - these are qualities that actually make a good product developer, but many companies pretend that they are hiring people who will be coming up with new algorithms and not just make db records when someone clicks or submits a form.

this is the key point which makes you good. you always think as a hacker and that's why you write good code.

I went as far as to enroll in an interview prep course to try and “freshen” up for an attempt to move from my current role/comp to a faang.

The trainer was an ex google guy who had done a ton of interviews over the years so I took the opportunity to ask him… why?

Why is the knowledge of how to implement an esoteric algorithm that I would almost never have a need to use for the job/role relevant. Why is memorization of these implementations so critical? I get why it’s useful to understand the high level ideas/approaches but why do we need to be able to recite their implementations like the gospel?

After much prodding he admitted that it ultimately boils down to the companies using these practices trying to find an “unbiased” means of measuring a candidate. People tend to be terrible judges of character so having some standard questions and expected solutions gives the company at least some hope of providing a way to interview and hire at scale and reduce bias (slightly).

I get it now, there are (were?) so many applicants and so many interviewers that they had no time (or confidence) to try and get to know the applicants and their specific skills or what values they could add. They basically decided to punt and choose people who take the time to learn the gospel - these folks would either end up being good developers/engineers or more commonly getting put on review and fired - but they showed they had the capable to learn whatever might be needed.

I get it, I do, ultimately decided that I’m too old for the politics of the process (and that’s kinda by design) and I’d be better served ghosting comps that require this sort of thing going forward.

- just a grey bearded dev

I'd take people that have initiative, want to learn and are coach-able over someone that can excel at taking tests.

Code interviews are broken. I judge a company's software development maturity based on their interview process. I've been the owner of such processes, and I've made the mistake of applying non-related coding exercises, but I've also had success revisiting these with new approaches.

There's no formula for all companies, but the best kind of interview process, in my opinion, is to match the developer skills and personality with what you already have in-house, and with the kind of problems your tech team is facing.

[0]: https://badecaf.com/5/

I don't think you have to take the label "bad programmer" because you don't ace job interviews. Those are contrived games anyway, if you practice you can learn to ace them but from your position it doesn't sound nessecary.

I'll also throw out that it's not binary in the other direction either.

There is always more to learn and as long as it's still fun I find that reading one more technical book usually does add value somewhere I wasn't expecting.

That being said, the standards that define what a "good" programmer is are not well defined, and everyone has a different idea of what it means. It is also possible to be a "terrible" programmer and still manage to sell two startups.

Also, don't be so down on yourself regarding interview questions. If you spent a month or two just practicing these types of questions in your free time you'd be surprised how you'd do on some of the interviews you would normally bomb out.

* Productivity * Simplifying Complexity * Design * Knowledge * Documentation * …

Are all different things and it’s possible to be skilled at one and not another. Someone can be great at design but slow at getting the simplest things done, another may know a computer inside and out, but write zero documentation.

A successful entrepreneur, perhaps, but not necessarily a good programmer.

There's really nothing wrong with being dead average. The interview process is backwards in this industry anyway. No need to worry. It sounds like you're doing fine.

Take home projects are much better for me than interview problems, but take home projects are unnecessarily complex and time consuming. But at least I can open source them and put them and make it look like I do side projects

One thing, I think, you should be really careful about is how you handle user inputs, e.g. this line: https://github.com/caviv/9gager/blob/20ccaaf649af525fc7a0c1d...

I validated this on the live site as well, and it was really easy to insert any kind of HTML through the `channel` param. This is called XSS or Cross-Site Scripting.

Also, you seem to regularly commit code that includes database connection information (I hope it is not active anymore, or at least not reachable from the outside internet), e.g.: https://github.com/caviv/9gager/commit/bcc0b91eb8638835c1557...

Now, to be clear, this doesn't necessarily make you a bad programmer per se. But in my eyes, your claims of being "actually really good" seem to be over the top, and what I see is that you still have a lot to learn about the web and especially about security.

To offer some constructive criticism, "Hassle" being misspelled as "hassel" in the readme, to me, would raise the question of the quality of English written communication created by the author.

This code is a disaster and the opposite of what OP describes. A clear case of Dunning–Kruger.

Trying to give the benefit of the doubt, but I generally don't think one toy Github project is conclusive evidence of anything, really.

> Trying to give the benefit of the doubt

Why? Even if he's actually a really good programmer like he claims, it's a massive display of hubris. We should encourage humbleness.

Oh, I didn't see that.

I am sure if you were in the dev field for years without a degree then you'd get tired of being second guessed for not having that piece of paper from a college.

> In everyday life, your objective opinion is the one that sets aside your subjective preferences or feelings about something and instead assesses it based on facts and reality. [0]

[0] https://www.dictionary.com/e/subjective-vs-objective/

But category theory?