I am a quite good bad programmer | Hacker News Reader

I am a quite good bad programmer

152 pointscaviv152 comments

I find somethings actually strange. Per se, checking my quality as a developer with job interview questions I will receive a not so high grade. I would say between 5 to 7 out of 10. Not brilliant. But as a developer I think I am actually really good.

I never "studied" computer science in a regular way, but I am in the industry more than 20 years. I started as a hacker, reverse engineering, assembly code, moved to C and C++ and now web development in Node.JS, Go (golang) and Rust and Vanilla JS. Touched of course Python and Arduino and Raspberry PI.

I find it that my code and overall look as much better (if I can be a bit non modest for a second) than other developers even seniors.

- My code is highly readable with good comments and other can take over my code responsibility quite easily

- My code runs (and also complies) faster than other - I understands the usage of Hash / Map instead of searching arrays and many other small things that actually enhance the code performance

- I know how to KISS (Keep it stupid and simple) and so I am able to write complicated software because the basic is simple and separated so my feasible to comprehend

- I understands Object Oriented correctly and knows where to use it and how and when to avoid it

- I know not to search always the latest new shiny thing (library or framework) and use legacy software that actually do the job when needed without complications

- I understand how the computer works, from BIOS, BUS to OS (Linux and Windows internals)

- I have (again if I may say) good product skills and some UX guts which helps me manage things on my own

All of this together allowed me to build and sell already two startups. Develop and maintain easily many web sites and SaaS which creates me nice passive income (such as https://gematrix.org).

So am I a good or bad programmer? - Still I will score quite low in job interview questions ...

View on HN

Your list makes the case for being "good", but that doesn't matter.

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.

So I was building a side hustle right before I had to switch to job hunting due to illness. The side hustle is sooo enjoyable to me since I get to finally solve problems I've heard about tangentially but never got to work on in my day jobs.

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 what world would anyone implement their own matrix operations?

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

This isn't babbling at all, the sentiment in your 2nd paragraph is so accurate that you could drop the qualifiers "largely" and "probably" and it would become even more accurate.

And these are the people who post on LinkedIn as if their understanding of esoteric Leetcode string DP problems is essential for scaling Amazon and Google.

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.

I wonder how much the culture of standardized testing has contributed to this pattern. The idea that it's somehow unfair to test relevant skills and knowledge because previous exposure comes down to simple chance. That for a test to be "objective" it should only ask about abstract matters no one would ever reasonably encounter. It strikes me as sort of essentialist.

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?

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

This never occurred to me but it makes sense.

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.

Many of these young CEOs are really brilliant folks. They deserve to be given a fairly free rein.

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.

Maybe solo dev of niche product is a better alley for some?

It's the one I chose.

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.

It occurred to me just last week as I was reminiscing over some past interviews that while I have written a substantial amount of code, pseudocode, and algorithms it has never been while standing at a whiteboard.

For a recent interview I was asked to build an IOC dependency injection library in 2h and the task was made “deliberately” unclear according to the interviewer. So I spent 2 days researching IOC libraries, building some nice examples of how it should work to get a feel for the API, writing tests up front, writing the library and adding docs. Then I got an interview! Fantastic I thought, I passed the technical with my 100% tested IOC container that had a nice interface for injecting dependencies and even options for injecting singletons or new class instances with configurations passed into the constructor.

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/

"Build a custom IoC for an interview"

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.

I start a new gig Monday… my best interviews were with two big tech companies… one hired me and the other said I lacked “code fluency”, which I had never heard of in those words.

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.

This reminded me about obe interview I had a year ago related to environments management in IaC.

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.

Happens more often that you might think. Score high on tech, but very low on diplomacy / political awareness. Managers want staff to make them look good -- at all cost.

Similar experience last week

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

At a certain level we all should ditch companies for giving these monstrous coding challenges or they'll probably never learn. E.g. I think it's ridiculous to let people write code when applying to Senior Developer or even worse Software Architect positions. If you can't find out otherwise if the person is a fit or not you're doing it wrong.

Geez. Half our our candidates wouldn't even know what an DI libary is.

For better or worse, when I was interviewing developers I would give specifically vague requirements, since requirement gathering is a skill that I think (senior) developers must have. I don't think that's a useful thing to do in a take-home assignment, though, since you can't clarify requirements with your client in that situation. That said, I admit that I would also expect error handling to be addressed in any piece of software written for any purpose.

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.

>That said, I admit that I would also expect error handling to be addressed in any piece of software written for any purpose.

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.

> when I was interviewing developers I would give specifically vague requirements

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

The code had tests checking if errors threw under certain conditions... like I say it had error handling but we changed the way it worked during the interview so we needed to add some extra error conditions which we did and test coverage remained 100% so all paths in the code were tested.

> I understands the usage of Hash / Map instead of searching arrays and many other small things that actually enhance the code performance

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.

FWIW, actually, one thing I learned in practice that’s wasn’t highlighted in my Algorithms course: overhead (constant C) matters. You can feel good about yourself for choosing an algorithm that scales in O(lg n) time, but if your you ignore the cost of each operation (C) you might be slow.

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.

Also cache matters a lot. If n is small an array is always faster by a big margin.

a good example of this is Fibonacci heaps. on paper they're great, but they result in egregious pointer chasing, while radix heaps are less flexible but can be backed by a contiguous array.

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

I had an extraordinarily painful conversation with someone who had done pretty well in our DS class but didn’t have a ton of practical experience.

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”

I had an extraordinarily painful conversation with experience programmers when I pointed out that the values that the hash key relyed upon must not change, for the life of the hash map.

> ...when I pointed out that the values that the hash key relyed upon must not change, for the life of the hash map.

Now I'm wondering about something like:

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

You could probably have they key be a container object and allow changing its internal value, which would then communicate to the hash map that it belongs to, that it should do some internal changes:

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

That logic could take an internal hash map, remove the element by the old key and add it with the new key. So, to an outside user it would seem like you can change the keys.

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);

the nitpicker in me wants to say that the hash key can change (and it works if you rehash items whose key changed), but lookup by key will fail because the item will landed in the bucket of its original hash... but yes keys can't change if you want your values to be retrievable by key.

Is it nitpicking if we end up with fewer bugs as a result of the conversation? :)

that's the spirit!

> someone who had done pretty well in our DS

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

No, technically he's right. On paper, a hash map creates an index in an array-like structure from the key, but does not necessarily store the key in a retrievable way. The "Hash" in hashmap comes from the fact that the key is somehow hashed (an often irreversible procedure) to determine the memory location to store the value.

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.

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

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

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

Not to date myself too much but the course was taught in Eiffel :). On top of the theory, and on top of the practical details, there was also the fun of learning an obscure quirky programming language you were unlikely to ever use again.

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.

Collision-free hashes exist. They are just not used on practice to build hash maps, but if you use a 128 bits hash with homogeneous distribution, handling collisions is irrelevant.

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.

I never understood why a 'dictionary' (so called conveniently in python) is called a 'map' in c++ and yet, a 'hash' in ruby. On a side note, a map in ruby is an operation that actively maps one thing to another. So confusing. Finally reading what you just wrote makes the pieces of this puzzle to fall in place! Never had a data structures class.

According to https://stackoverflow.com/a/2884200 map and dictionary are just terms for the same data structure concept. On the other hand: there exist other backings for this data structure than hashing the key, such as binary trees (for example red-black trees or AVL trees).

The followup question is "Can you explain a strategy for resolving hash collisions?"

Depends on the use case, sometimes a list is more appropriate. On an old machine, Java 17 can iterate a list of 30 million strings looking for a match in around a half second. Just checked it in jshell. If the use case was that the map's keys could potentially change over the lifetime of the map or if the value's were not idempotent and if iterating 30 million items occurs fairly infrequently, then an ArrayList (in Java) might be the best choice.

Optimistically, you should definitely be able to assume this. In practice, though, I wouldn't. I've been in school with and interviewed many a college grad that had virtually no concept of how to effectively apply any of the data structures they "learned". It's definitely not a given

And yet there are plenty of developers who happily loop through an array a couple of times looking for an object with a specific key. In Javascript.

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

Reading through your post, I am noticing some trivial English mistakes that are common to non-native speakers.

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.

That is true. I am not a native English speaker. I should work on my English skill though.

In a moral sense, you shouldn't need to. Your English is functional enough to work with. It's not your fault if people make poor judgements about your ability based on your English skills.

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.

use grammerly

It's difficult for any of us to really tell how much truth is in every statement. For example readability - its difficult to asses it without looking at your code.

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

Maybe better to do mock interviews if you can? Lots of places won't give any feedback on no-hires for legal liability reasons.

Don't take seriously any feedback you get from an interview. Unless you already trust someone involved in the process.

You're "expected" to study for job interview questions. It's more a measure of willingness to jump through hoops than your competence. Developer interview questions in general has little to do with what you'll do as a developer, and what you're expected to know as a developer.

This is so weird. Aren’t you just selecting for obedience and unnecessary hoop jumping? It seems like this would also select the kind of engineers who aren’t willing to say “no, that’s a dumb approach, we shouldn’t do that, here’s an alternative”?

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?

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

> This is so weird. Aren’t you just selecting for obedience and unnecessary hoop jumping?

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.

Example: I work in medical devices, a regulated space. My job is 50% normal software engineering, and 50% dealing with BS regulations. It's part of the job. You can get annoyed at it, but it won't go away, and the job can be very fulfilling if you can get past the BS part.

How many devices do you see or design have implicit state in the software controlling them?

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

I work on software as a medical device, so I have no idea about hardware safety controls. I have to deal with change control boards and approval matrices for every new build we push, though.

> It seems like this would also select the kind of engineers who aren’t willing to say “no, that’s a dumb approach, we shouldn’t do that, here’s an alternative”?

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.

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

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

It's not that they have much choice once company grow in complexity beyond something that a small group of people can possibly handle.

There's only 24 hours in a day.

Well sure, but one would expect the founding team to do the early interviews, and then setup the process that's followed by later hires, no? Also, I would have thought that hiring would pretty much top priority. The employees make or break a company.

Business processes and traditions are not a source code. It always changes and evolves with people and millions other factors.

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

Tech interviews are optimised for big tech. Those devs won't care so much when you slap 3x total compensation on their ass.

> Aren’t you just selecting for obedience and unnecessary hoop jumping?

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

> obedience and unnecessary hoop jumping

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

> It's more a measure of willingness to jump through hoops than your competence.

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.

You're also biasing towards the type of person who is ok with either burning themselves out or skiving off work (or both) to get good at these types of interviews.

> I'd say it's more a measure of how well you can learn an arbitrary skill.

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.

Job interviews have a very questionable form of gatekeeping. But it is a very well documented form of gatekeeping. If you want to get good grades at job inteviews, you can practice how to pass that test... I do agree it doesn't reflect the quality of developer you are, but it is what it is...

> But it is a very well documented form of gatekeeping.

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

> Still I will score quite low in job interview questions ...

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

We OCR and parse a dynamic set of rows so it produces a stream of snapshots of ordered, mostly unique colored integers. Each snapshot has exactly N items, except when there is naturally less than N or parsing failed for some rows. A delay between two snapshots may be arbitrary, so assume that we can even miss few rows completely. Which algorithm or data structure would you use to find only (most likely) new black items? Optimize for less errors and duplicates.

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 agree. It is not that I am trying to ace code interviews - I am making enough income and I am not searching for another job. It is more a question of am I good enough or not? - Since I agree I am not good at algorithms (I think I quite fair in data structures) I can still create good software.

I applied for a job.

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.

I once got rejected from a job because "I didn't use some of the core features of Rails".

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

I guess I'm pretty bad.

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.

Sheesh, the software interview process is so messed up that it makes people wonder if they can actually do the job they already do.

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

It's worth mentioning that the world could use a few more grug-brain developers: https://grugbrain.dev/

It's always amusing to see that site, because clearly there is actual wisdom in it, behind the funny way of writing. I feel like we'd also benefit from a version that's written in a more regular style, to have some frank discussions about what's said.

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.

While not as profound as you, I think I'm a decent developer. The caveat being that I don't work in software development, but in a role that's on the business side with a mix of management, software engineering, a bit of maths and data engineering and analysis.

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.

I feel the same way. I hate interviewing because I usually need to study for stuff I won't use. I also didn't do CS in college and some times I feel like this is the missing point in my career.

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

Doing well at interviews has low correlation with being good at the job, simple as that.

I would say that even being demonstrably good at the job has an imperfect correlation with being productive on the job. Because people lose motivation and procrastinate.

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.

> Doing well at interviews has low correlation with being good at the job, simple as that.

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.

A kinder rephrasing of "companies are bad at interviewing" would be that finding out who is a good fit for a company (and vice versa) is a very difficult problem, more so given the resource constraints.

I went on an interview some years ago and was asked how I'd architect a certain situation with Models and Controllers. I spent some time discussing why that wasn't the right solution for what they were trying to do, and they said thanks but no thanks.

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.

I've handled interviews like this before by saying "normally I wouldn't use Models and Controllers for this task because X, but since you asked, I assume you just want me to demonstrate that I know what Models and Controllers are, and that's what I'll do".

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.

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

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

> I know how to KISS (Keep it stupid and simple)

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

I can tell you I’ve received feedback on take home coding tests of “Outstanding” and “Unreadable” on the same day. Some people are never going to like your code.

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.

Good to know. I have pretty high opinion of myself too.

I don't know if you're a good or bad programmer, but I'll tell you this about job interviews:

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 be good at everything? It is an unreasonable expectation. It is better to know a lot of stuff a little and some things very, very well.

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.

> My code is highly readable with good comments and other can take over my code responsibility quite easily

Say no more, you're hired.

Remarks like "my code is highly readable", "my code has good comments", "my code runs faster", "my code is simple and separable", ... mean nothing unless your code is read by someone else and compared to code written by another competitive programmer (YouTube and Udemy tutorials usually don't fall here).

I used to be like you. I stay on top of cpp con talks, I read Meyers and Andrescu's books and I had some fun side projects and I do fine at work, regular promotions, etc, but I did incredibly badly during interviews. I wasn't sure if it's some kind of IQ thing because I know people who can answer those CS questions without studying but I took the advice of some friends and I spent months grinding leetcode style questions. After a while something in my brain clicked and since then I've gotten a ton of job offers and worked at two FAANGs.

That "Something" is usually problem decomposition. Programming is very much a game of slicing a big problem into solve-able smaller problems, and leetcode is usually just a one-to-one mapping of description to some polynomial time algorithm from a textbook.

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.

System and sub-system decomposition is the "black art" IMO that can have so much impact, but be so hard to teach or even evaluate for optimal choices.

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

There's a difference between a PROGRAMMER and SOFTWARE ENGINEER. I know bad programmers that are good swes, and I know good programmers that are bad swes. Though the best is probably happy average.

+100

I'm the same way. 25 years in the industry, though I consider myself a jack of all trades. Went from Oracle development -> ASP Classic -> C# -> PHP -> NodeJS. I think I'm pretty good at getting what needs to be done, but I absolutely fail when doing tests. I know how to program, I just may not know all the terminology and what... and if I don't understand something, google is always a few clicks away. Keeps me scared of looking for new opportunities though.

A good number of people conducting interviews are never given any formal training. They may be biased against you before you even enter the room. Fortunately the demand for programmers is still good so take feedback from the interview process with a grain of salt.

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

Lots of folks are good at doing the job but bad at interviewing for jobs. Interview prep is a massive industry.

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.

And therein lies the problem that's been re-hashed 100s of times here. This biasis against people with families or people who are higher up who don't have time outside their jobs. A lot of friends who were jrs pulled weekend and late nights just cramming leetcode. It worked. But as a sr, who have tons of other things going on, with work and otherwise, there's just not enough time to do it.

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.

> Lots of folks are good at doing the job but bad at interviewing for jobs. Interview prep is a massive industry.

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

Someone who is good at interviewing should be a red flag then

World needs more 1x programmers.

Strong agree. I'm a big fan of https://1x.engineer and pretty much everything it lists. To pick a few:

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

OP seems more of a 10x dude IMHO

My fear is, I see many 0.5x programmers / workers who are active drag on products and teams. :-/ The problem with these workers are, the more you have these people on the team, it has a multiplying effect instead of additive in terms of productivity. 0.5x0.5x0.5 (not 0.5+0.5+0.5)

I would say it is a range from 0.1-1.0,10

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

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

If most of the team are actually 0.1s then a 1 will seem like a x10.

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.

if what u say is truth then you are undoubtedly a good programmer - pragmatic people who are thoughtful of others (users and maintainers) are clearly good.

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.

I have done countless technical interviews and I can already tell you how your interview is going to go based on your comments here. You are confusing programmer/developer/knowing DSL and being a good candidate. You might be a good problem solver as well, but details matter. You can't simply gloss over them. A crudely solved problem might as well be not solved at all.

>I started as a hacker, reverse engineering

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

As I read your post I recall having come to much of the same conclusions (also have a similar non traditional/institutional history - over 20yrs writing/building stuff).

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

Tech interview questions with leet code is the equivalent of standardized tests (SAT, ACT) for admissions to college/university. Neither are anything like what is required of you once you are accepted.

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

Wrote a comic about code interviews [0].

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 was going to comment something about how with modern tooling a lot of people (including me) can write working apps without being too advanced but from your description it sounds like you know quite a lot.

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.

I think something that is often forgotten is that there are highly productive programmers who have near-zero industry experience, or at least are not totally privy to "modern" engineering practices, and who mostly just program as a hobby (or in open-source).

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.

You are a good programmer. Period.

You're probably a very good programmer - strange that you're comparing your work against seniors; are you not a senior engineer yet with 20 years experience? You probably could be.

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.

I think you’ve grouped many things into a good/bad spectrum, but in reality we’re talking about different qualities of a programmer.

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

> All of this together allowed me to build and sell already two startups. Develop and maintain easily many web sites and SaaS which creates me nice passive income

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.

lol just want to add that KISS stands for 'Keep it simple, stupid'

That's also how I learned it, but I prefer the way OP wrote it. I think it's nice.

Your experience is very common

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

I don’t know about your programming skills, but one of the most important and difficult things about programming is communication, and the grammar probably isn’t helping.

You are better than many others. The same for me, but maybe it's not enough to became rich & famous.

    I understands Object Oriented correctly and knows
    where to use it and how and when to avoid it

Literally nobody "knows" this for every case, there's not a right answer: OO is a philosophy not an instruction manual. "Good programmers" accept there's ambiguity.

My interpretation of OP's comment was that they were saying something pretty similar to what you are saying. That is to say, knowing where to use it and how and when to avoid it is an acknowledgment of that ambiguity. Maybe you mean that nobody can claim to know where to use it? Also, why did you put good programmers in quotes. Do you not believe there is such a thing?

I’ve never got the job where they asked me to code some algorithm on the spot

vague question, depends on what metrics you want to measure yourself. effective on what, generating revenue? creating impact to the world? you can answer that.

I'm a quite bad bad programmer.

I wanted to give you a completely objective opinion, so I went from gematrix.org > www.c2kb.com > 9gagrss.xyz and based on that and your user name I found this: https://github.com/caviv/9gager

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 be fair, I write quite a bit of sloppy code when I program as a hobby, or if I'm trying to quickly hobble together something that just does what I need to do (and that includes random projects I throw up on Github).

Agree, this isn't conclusive. OP might have a lot to learn about security. Or maybe OP just didn't care in this case.

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.

The difference is that you don't create a whole post on HN just to humblebrag how good of a programmer you are.

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

But OP wasn't bragging about their 9gager project. Also, isn't it possible to be a good programmer but write bad code sometimes? Perhaps OP's best work just isn't on display.

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

The 9gager project is at the top of his site (https://www.c2kb.com/). It's definitely on display.

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

> The 9gager project is at the top of his site (https://www.c2kb.com/).

Oh, I didn't see that.

The danger is whenever anyone feels like asking others to check out there pretty good work, someone will inevitably find problems. It's just life and our limits as humans. What I have noted is the people that carry themselves as huge geniuses are the ones who make huge oversights. The best is someone quietly humble, doing awesome work, has depth when you ask them.

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.

Shhhh, you're making the jobs of pentesters harder! /s

Opinions are not objective.

I used it in this sense:

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

Not quite. Learn more about Monad and Category theory then i'm sure you're really a good programmer.

Monads definitely

But category theory?

Reply on news.ycombinator.com