from Hacker News

I am a quite good bad programmer

by caviv on 11/3/22, 12:40 PM with 152 comments

• by ergonaught on 11/3/22, 3:13 PM

  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.

• by andy_ppp on 11/3/22, 1:50 PM

  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/

• by johnthuss on 11/3/22, 1:39 PM

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

• by thomastjeffery on 11/3/22, 2:19 PM

  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.

• by herr_gurke on 11/3/22, 12:53 PM

  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

• by marginalia_nu on 11/3/22, 1:05 PM

  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.

• by hernantz on 11/3/22, 1:17 PM

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

• by dehrmann on 11/3/22, 3:47 PM

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

• by edding4500 on 11/3/22, 3:25 PM

  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.

• by ChrisMarshallNY on 11/3/22, 3:18 PM

  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.

• by karaterobot on 11/3/22, 3:41 PM

  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.

• by Rantenki on 11/3/22, 3:09 PM

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

• by jevgeni on 11/3/22, 1:23 PM

  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.

• by oliveroak on 11/3/22, 1:39 PM

  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.

• by lawn on 11/3/22, 1:19 PM

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

• by borbulon on 11/3/22, 2:18 PM

  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.

• by latexr on 11/3/22, 2:19 PM

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

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

• by moomin on 11/3/22, 2:37 PM

  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.

• by oriolid on 11/3/22, 2:00 PM

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

• by babarock on 11/3/22, 2:09 PM

  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.

• by twawaaay on 11/3/22, 2:52 PM

  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.

• by notjustanymike on 11/3/22, 1:33 PM

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

  Say no more, you're hired.

• by lazyllama on 11/3/22, 2:56 PM

  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.

• by oxff on 11/3/22, 3:42 PM

  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.

• by STLCajun on 11/3/22, 2:57 PM

  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.

• by agentultra on 11/3/22, 3:04 PM

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

• by Taylor_OD on 11/3/22, 3:52 PM

  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.

• by dvh on 11/3/22, 1:33 PM

  World needs more 1x programmers.

• by gryzzly on 11/3/22, 1:19 PM

  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.

• by strangescript on 11/3/22, 2:51 PM

  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.

• by z3 on 11/3/22, 3:32 PM

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

• by greybeardednyc on 11/4/22, 1:41 AM

  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

• by matt_s on 11/3/22, 1:45 PM

  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.

• by kinduff on 11/3/22, 4:49 PM

  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/

• by f0e4c2f7 on 11/3/22, 12:56 PM

  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.

• by kevinfiol on 11/3/22, 3:42 PM

  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.

• by pcurve on 11/3/22, 1:48 PM

  You are a good programmer. Period.

• by taternuts on 11/3/22, 5:05 PM

  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.

• by twobitshifter on 11/3/22, 4:12 PM

  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.

• by Test0129 on 11/3/22, 2:18 PM

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

• by nicokeano on 11/3/22, 2:01 PM

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

• by yieldcrv on 11/3/22, 2:54 PM

  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

• by epgui on 11/3/22, 3:18 PM

  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.

• by _bax on 11/3/22, 2:36 PM

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

• by al2o3cr on 11/3/22, 2:38 PM

      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.

• by m3kw9 on 11/3/22, 3:28 PM

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

• by joshxyz on 11/4/22, 8:00 AM

  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.

• by giantg2 on 11/3/22, 2:40 PM

  I'm a quite bad bad programmer.

• by katsura on 11/3/22, 3:17 PM

  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.

• by revskill on 11/3/22, 1:16 PM

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