Live data from Hacker News

I am a quite good bad programmer

news.ycombinator.com

31–40 of 160 posts

Re: I am a quite good bad programmer

#31
post #5

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 enlighte…

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

Re: I am a quite good bad programmer

#36

Earlier quoted context omitted.

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

There's only 24 hours in a day.

Re: I am a quite good bad programmer

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

Re: I am a quite good bad programmer

#38

Earlier quoted context omitted.

> And why founding team doesn’t stay long in a successful startup. Doesn't the founding team get to determine the hiring practices?

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.

Re: I am a quite good bad programmer

#39
post #5

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 enlighte…

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

Re: I am a quite good bad programmer

#40

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

Post reply on HN