I am a quite good bad programmer

[caviv]

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

[ergonaught]

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.

[jimmywetnips]

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.

[anonym29]

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.

[majjgepolja]

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.

[itronitron]

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.

[andy_ppp]

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/

[AtlasBarfed]

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

[code_runner]

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.

[pojzon]

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.

[yieldcrv]

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

[tobilocker]

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.

[francisofascii]

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

[yurodivuie]

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.

[johnthuss]

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

[metric10]

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.

[tonyarkles]

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”

[soggybutter]

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

[mcv]

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.

[thomastjeffery]

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.

[caviv]

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

[herr_gurke]

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

[QuercusMax]

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

[isaachawley]

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

[marginalia_nu]

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.

[wincy]

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?

[badlucklottery]

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

[hernantz]

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

[RunSet]

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

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

[dehrmann]

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

[wruza]

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.

[caviv]

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.

[edding4500]

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.

[KittyCatCuddler]

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.

[ChrisMarshallNY]

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.

[karaterobot]

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.

[Rantenki]

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

[KronisLV]

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.

[jevgeni]

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.

[oliveroak]

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.

[lawn]

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

[kazinator]

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.

[nicoburns]

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

[borbulon]

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.

[nerdponx]

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.

[thomastjeffery]

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

[latexr]

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

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

[moomin]

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.

[oriolid]

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

[babarock]

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.

[twawaaay]

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.

[notjustanymike]

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

Say no more, you're hired.

[forgotpwd16]

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

[lazyllama]

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.

[jvanderbot]

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.

[oxff]

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.

[siliconsorcerer]

+100

[STLCajun]

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.

[agentultra]

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

[AlwaysRock]

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.

[jimmywetnips]

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.

[_tom_]

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

[ipaddr]

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

[dvh]

World needs more 1x programmers.

[Amorymeltzer]

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.

[dncornholio]

OP seems more of a 10x dude IMHO

[gryzzly]

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.

[strangescript]

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.

[z3]

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

[greybeardednyc]

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

[matt_s]

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.

[kinduff]

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/

[f0e4c2f7]

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.

[kevinfiol]

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.

[pcurve]

You are a good programmer. Period.

[taternuts]

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.

[twobitshifter]

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.

[Test0129]

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

[nicokeano]

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

[topaz0]

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

[yieldcrv]

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

[epgui]

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.

[_bax]

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

[al2o3cr]

    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.

[seti0Cha]

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?

[m3kw9]

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

[joshxyz]

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.

[giantg2]

I'm a quite bad bad programmer.

[katsura]

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.

[kevinfiol]

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

[anonym29]

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

[solarkraft]

Opinions are not objective.

[revskill]

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

[hardware2win]

Monads definitely

But category theory?