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…
I am a quite good bad programmer
31–40 of 160 posts
Re: I am a quite good bad programmer
#32Re: I am a quite good bad programmer
#33Re: I am a quite good bad programmer
#34Re: I am a quite good bad programmer
#35Re: I am a quite good bad programmer
#36Earlier 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?
Re: I am a quite good bad programmer
#37I'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
#38Earlier 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.
Re: I am a quite good bad programmer
#39You'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…
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.
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.