I Am a Bad Developer

I'm drawn to this for several reasons...

Trite though it is, admitting that you don't know truly is on the path to wisdom.

Not taking time to think things through is endemic in the workplace, not just an interview quirk.

in the real world, many O(N) algorithms are in fact O(I don't know) because of unexpected or unpredicted behavior from language, compiler, interpreter, runtime, os, etc.

I'm pretty sure it's an anonymous post .. on purpose.

> Well my bookshelf is stocked with the classics...I've read most of them

He's able to digest heavy tomes of abstract and concrete methodologies (for some value of "understanding"), but not create anything with it that he isn't told to? That sounds like a bad developer trying to pump up his image, to me.

Going to have to ask for an example.

I am yet to have seen a basic CRUD app that had performance issues due to a bad coding algorithm. Certainly from poor queries but never from an bad algorithm.

Keep in mind I would say that a simple CRUD app with millions of entries is no longer a simple CRUD app.

From your post you sound like a nice fellow and I wish you the best and want you to find happiness and job security. However, also based on your post, I am sad to say that I think you're right, you are a bad developer. I strongly urge you to lower your sights and aim for a job that has a lower skill requirement.

So as not to leave you guessing, here are the red flags that jumped out at me in the post: I don't remember the particulars but I know that for every recursive form there is an iterative solution. This is not a fact to be memorized and referenced, it's a consequence of a fundamental understanding of how programs execute.

I still draw a blank when asked what the magnitude of complexity is for the guests function I just wrote ... damnit, of course calculating the permutations of a list is n-squared, but this is an interrogation of the random trivia I can manage to recall This also sounds like you are trying to apply memorization to a problem that requires analysis. When asked for the complexity of a function, you don't compare it to algorithms with known complexities that you've memorized, rather, you look at the code and reason about what it is doing proportional to its inputs. There are certainly insanely hard algorithms to analyze, but I don't think we're talking about them here.

I really like joint semi-lattices I don't point this out to be pedantic, but as another instance of memorization vs. understanding: they are called 'join semi-lattices' ('join' one of the fundamental operations you use when working with these).

I still blunder my way through an exercise to write a function which returns a boolean in response to the question of whether sequence A is a sub-sequence of sequence B I ask a warmup question like this to cut the interview short if the interviewee has problems. Good programmers will absolutely get nervous, stutter, and make mistakes; that's fine; but this is simpler than that.

I once had a friend who did fantastically on Biology with little effort but did horribly on Physics, despite immense effort. After trying to help her a few times, it was clear that she was trying to apply memorization (which worked well for her in Biology) to Physics. To do well in Physics, you have feel comfortable enough with the math and physical concepts to derive your own answers. The same goes for programming and I wonder if some of your latent unhappiness with your original job wasn't caused by a fundamental impedance mismatch with your approach to programming.

I'm sorry if this was blunt; if we were in person, I'd try to be much more delicate. But you did post on HN, presumably for advice. Best of luck!