The Lesson to Unlearn • Hacker News Board

Re: The Lesson to Unlearn

#481

Post by JesseAldridge » Sun, Dec 08, 2019, 2:05 AM UTC

> Why did founders tie themselves in knots doing the wrong things when the answer was right in front of them? Because that was what they'd been trained to do.

Maybe I'm overly cynical, but I see another possibility: They want to create the appearance of running a hot startup without actually having to do the work. Why make something people want when you can just dazzle some investors and get them to dump a million dollars in your lap, no strings attached?

I wonder if that also might explain why such a tiny fraction of startups generate essentially all the wealth -- most of them aren't really trying.

Re: The Lesson to Unlearn

#482

Post by aardvarks » Sun, Dec 08, 2019, 2:17 AM UTC

There is a parallel with one of pg's other essays, 'Why nerds are unpopular'[1]. He says (I paraphrase): 'nerds care more about being smart than being popular'. But that's another way of saying nerds think the tests you have to pass to be popular are (on balance) a waste of time, ie bad tests.

[1] http://paulgraham.com/nerds.html

Re: The Lesson to Unlearn

#483

Post by wnmurphy » Sun, Dec 08, 2019, 2:37 AM UTC

bitwize wrote: post #459

alien_ wrote: post #329

Earlier quoted context omitted.

At Amazon, perhaps one of the largest and most successful employers, the solution to this is that when interviewing, everyone's main goal is to hire people better than the current average of the team. To ensure this, someone experienced with interviewing from outside the team/organization, so called bar raiser, is always added to the interviewing team. This person is there to ensure high quality hires and has hiring…

Amazon phone screens you by saying: "Get out a notebook and a pencil. Write down the code in C to flatten a binary tree into a sorted list, and then read it back to me over the phone." If this is raising the bar, no fucking thank you.

Seriously.

Re: The Lesson to Unlearn

#484

Post by sn9 » Sun, Dec 08, 2019, 2:46 AM UTC

pjscott wrote: post #478

arman_ashrafian wrote: post #452

Earlier quoted context omitted.

Look up "edit distance"... it is one of the first problems an Algorithms course will discuss that can be solved by dynamic programming. But ya, no way anyone is coming up with that unless they have seen it before.

An algorithm for "do these strings differ by an edit distance of at most 1?" is much simpler, and should be easy to figure out. No dynamic programming required.

This is something I would expect a freshman CS major to be able to solve.

It only requires knowledge of looping, conditionals, and how to work with strings in your language (e.g, indexing, finding length, maybe substrings, etc.).

This is like a less insulting version of fizzbuzz.

People are way overcomplicating this. Any professional programmer could solve this.

Re: The Lesson to Unlearn

#485

Post by throwawaytemp1 » Sun, Dec 08, 2019, 2:47 AM UTC

rsp1984 wrote: post #83

I completely agree with the the theory, however what 90% or more of us do when they finish university is to go work for an established (i.e. large) company, where winning means hacking bad tests (promotion cycles). So in some perverse sense school does prepare most of us well for working life, as most of the time doing well in BigCo isn't to actually perform well or to actually make a difference, it's to leave the im…

This isn't fair to tests. They are actually far more fair and objective than BigCo promo processes. You can't fake doing a variety of hard math questions the way you can move up the ladder due things like nepotism.

Re: The Lesson to Unlearn

#486

Post by 7402 » Sun, Dec 08, 2019, 2:48 AM UTC

pavlov wrote: post #240

The tech industry has unfortunately adopted the methodology of centralized hackable tests as the canonical gatekeeping method in the form of programming interviews. Most big tech companies don't care about how good you have been at delivering some value through creating software: they want to see you deliver a very specific type of performance at a whiteboard. Interviewers are given specific math puzzle questions to…

I think I blame Google, because it was started by a couple of graduate students.

I don't know how it was at Stanford, but at Berkeley in Physics there was a series of big honking tests ("Qualifying Exams") that dominated our attention the first two years. You were expected to know all of undergraduate Physics. Fail it, and you're out.

Grad students don't know any better. "How do we hire the best people? I know - they'll have to pass a big hard test, just like we did."

Then everyone else goes, "How do we hire the best people? I know - we'll do it like Google does, they seem pretty successful."

Ugh.

No, I don't know that it really went like that. I just suspect it.

Re: The Lesson to Unlearn

#487

Post by xmprt » Sun, Dec 08, 2019, 2:48 AM UTC

knzhou wrote: post #264

As somebody who has designed some of the tests Paul Graham is complaining about, it really is hard from the other side! For example, it's long been known in the physics education research community that students come away from introductory courses with very little physical understanding, even if they can do the plug and chug problems on typical tests just fine. Students can all recite Newton's third law, but immediat…

One of the best physics tests that I took was one where each question has a sense of progression. So the first part laid out a fundamental law of physics and the question was to prove something using it. Then using the result from that the problem was tweaked in a few ways for a few more questions until you were far removed from the original concept but could still explain why and how something worked.

To take your gravity example, the first question might be something about calculating gravitational force on the ISS. Then explain that it's rotating in space and therefore has centripetal force that accounts for this gravity. Then compute how fast it must be rotating. And from there you can switch to a completely different topic in the same context. Maybe something about EM radiation from the Sun that falls on the space station.

Re: The Lesson to Unlearn

#488

Post by iudqnolq » Sun, Dec 08, 2019, 3:03 AM UTC

stiglitz wrote: post #475

iudqnolq wrote: post #463

Earlier quoted context omitted.

Are you proposing brute forcing it? Depending on requirements that might be fine, but I doubt FB would like that kind of solution. If they did, they'd have a different kind of question.

This isn't "brute force." It's solving the specific problem posed rather than a generalization, which in this case is both easier and more efficient (since there are cases in which you could terminate the loop early).

Thanks! I completely misunderstood what the commentator I replied to was saying. Not understanding how to solve it well I assumed they were referring the first option with loops and tests that popped into my head: make every one-edit possible and see if it's one of them.

Re: The Lesson to Unlearn

#489

Post by eBombzor » Sun, Dec 08, 2019, 3:44 AM UTC

Wonder what this guy thinks of Asian schools, where you literally have to dedicate yourself to studying 9 hours a day, 6 days a week, through middle and high school (where you have to dedicate 11+ hours regularly) for one test that literally determines your entire career path, unless you want to move to a different country that is.

Re: The Lesson to Unlearn

#490

Post by greggman2 » Sun, Dec 08, 2019, 3:51 AM UTC

burlesona wrote: post #253

pavlov wrote: post #240

The tech industry has unfortunately adopted the methodology of centralized hackable tests as the canonical gatekeeping method in the form of programming interviews. Most big tech companies don't care about how good you have been at delivering some value through creating software: they want to see you deliver a very specific type of performance at a whiteboard. Interviewers are given specific math puzzle questions to…

Being a hiring manager at a big company, I can tell you this is just as frustrating for me as it is for candidates. I hate “leet code” and frankly find algorithmic interviews to be very low signal compared to more practical, open-ended, domain-specific problems. I will say though, the problem is one of “standardization” across an organization where it’s too big for everyone to fit in a room. Suppose you give each tea…

I would like to see data on if these interview systems actually achieved their goal of rejecting bad candidates.

I worked at a FAANG company and saw several people get let go for underperforming. I have no idea if they could have been productive doing something else but they were clearly not productive at the tasks assigned them or that they chose to do. I also saw several other people I thought were a candidate for going down the same path before I left. Whether they got moved to something they were more productive on or whether they were showing value in other ways I have no idea.

The point being the hiring system didn't reject these people. My guess is they either got lucky like me, easy questions, or they are good at answering the questions but not good in actual production.

For example one person that was let go was clearly smart and could make the code but they would refactor forever looking for perfection and end up taking 4x - 8x longer than others around them. Maybe in some place that's a plus but for our team we needed to ship and this person was not able to prioritize shipping and after several attempts they were let go.

Another had a task that they were taking a long time on. Others on the team gave them the benefit of the doubt that it was harder than it looked but when they were finally let go it turned out it was not harder than it looked and was finished rather quickly.

Another wrote bloated obfusticated code that seemed to be 6x the number of lines it needed to be. Maybe they could have been helped via code review.

Yet another was one I interviewed and they passed the "can write code test" but in the entire time I was there I don't think I saw them submit a single PR. I have no idea what was filling their time.

I don't know if that ratio of unproductive candidates is better or worse than anywhere else I've worked on average. Pretty much every place I worked before FAANG was 100 people or less and my team 30 people or less and those teams were 10 engineers or less. There were always 1 or 2 engineers in the company known for being slow or writing bad designs. Sounds about the same but I didn't measure.