Live data from Hacker News

I am a quite good bad programmer

news.ycombinator.com

141–150 of 160 posts

Re: I am a quite good bad programmer

#141

Earlier quoted context omitted.

I wonder how much the culture of standardized testing has contributed to this pattern. The idea that it's somehow unfair to test relevant skills and knowledge because previous exposure comes down to simple chance. That for a test to be "objective" it should only ask about abstract matters no one would ever reasonably encounter. It strikes me as sort of essentialist. It also seems sort of contradictory... if experienc…

> if experience in the field is one of the most important criteria, why are they implicitly avoiding testing for that? That's easy. No one wants to hire "olds." Since companies are now run by twenty-something CEOs, no one wants to hire people that make the CEO uncomfortable. It really is that simple. Basic bigotry. In my experience, many companies don't even try to hide it. Recruiters are awful . I just learned that…

Maybe solo dev of niche product is a better alley for some?

Re: I am a quite good bad programmer

#142
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

Re: I am a quite good bad programmer

#143
post #65

Earlier quoted context omitted.

> someone who had done pretty well in our DS > 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” How could he do well in the data structures class? This is the definition of a hash map or hashed dictionary, so this is basic knowledge of data structures that is taught in this class and central to know to even have a chance of passing the exam.

I never understood why a 'dictionary' (so called conveniently in python) is called a 'map' in c++ and yet, a 'hash' in ruby. On a side note, a map in ruby is an operation that actively maps one thing to another. So confusing. Finally reading what you just wrote makes the pieces of this puzzle to fall in place! Never had a data structures class.

According to https://stackoverflow.com/a/2884200 map and dictionary are just terms for the same data structure concept. On the other hand: there exist other backings for this data structure than hashing the key, such as binary trees (for example red-black trees or AVL trees).

Re: I am a quite good bad programmer

#144
post #127

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…

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

use grammerly

Re: I am a quite good bad programmer

#145
post #85

Earlier quoted context omitted.

>> In practice it's not the case, but very technically from a purely theoretical standpoint, I think he's right. > There's no theoretical way for a hash map to work without storing the key - the reason for that is hash collisions in presence of which you do need to run equality comparison with stored keys otherwise you would overwrite data just because of hash clashes. There's a ton of material in a Data Structures c…

> but if the DS course is your first exposure to a hash map, it's a detail that can easily get lost in the huge forest of other brand new things to learn. My experience differs: It is the common situation that the theory is taught in the lecture, and then each week you have to do quite some exercises to implement all the newly learned data structures in code (lots of work to do each week :-) ). So, if you forgot such…

Not to date myself too much but the course was taught in Eiffel :). On top of the theory, and on top of the practical details, there was also the fun of learning an obscure quirky programming language you were unlikely to ever use again.

I loved it all and had a great time. Lots of people really did not.

> So, if you forgot such a “detail”…

Sure, very true in the short term. Next semester though? That code doesn’t matter and most people don’t have flawless long term memory.

Re: I am a quite good bad programmer

#146
post #39

Earlier quoted context omitted.

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

Example: I work in medical devices, a regulated space. My job is 50% normal software engineering, and 50% dealing with BS regulations. It's part of the job. You can get annoyed at it, but it won't go away, and the job can be very fulfilling if you can get past the BS part.

How many devices do you see or design have implicit state in the software controlling them?

(if it is not explcitly defined, and there is state based behaviour, it is by definition then implicit)

At the moment I'm trying to overcome the inertia on this issue in the general process/industry sector with child standards from IEC 61508 - 61511 and 62061.

I am guesssing you apply the medical standards IEC 60601?

Or at design of devices at component level then IEC 61508?

Interested to know how it fits in to the overall Functional Safety approach.

Re: I am a quite good bad programmer

#147

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

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

System and sub-system decomposition is the "black art" IMO that can have so much impact, but be so hard to teach or even evaluate for optimal choices.

When I was a boy, practitioners of such things were called Systems Analysts, and may well have never coded.

Re: I am a quite good bad programmer

#149

Earlier quoted context omitted.

I wonder how much the culture of standardized testing has contributed to this pattern. The idea that it's somehow unfair to test relevant skills and knowledge because previous exposure comes down to simple chance. That for a test to be "objective" it should only ask about abstract matters no one would ever reasonably encounter. It strikes me as sort of essentialist. It also seems sort of contradictory... if experienc…

> if experience in the field is one of the most important criteria, why are they implicitly avoiding testing for that? That's easy. No one wants to hire "olds." Since companies are now run by twenty-something CEOs, no one wants to hire people that make the CEO uncomfortable. It really is that simple. Basic bigotry. In my experience, many companies don't even try to hide it. Recruiters are awful . I just learned that…

This never occurred to me but it makes sense.

I’m in my late 30s. Not too far from being older than many tech CEOs and I have seen plenty of BS I could call out.

I have a family, mortgage, and am not “wowed” by some slick CEO.

Re: I am a quite good bad programmer

#150

Earlier quoted context omitted.

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.

Business processes and traditions are not a source code. It always changes and evolves with people and millions other factors.

One of the factors — it’s too risky for a big company not to hire based on obedience.

Post reply on HN