Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Harder programming questions do a worse job of predicting outcomes

triplebyte.com

Post reply on HN
Print view View original

351–360 of 540 posts

Re: Harder programming questions do a worse job of predicting outcomes

#351

Post by TeMPOraL »

AnIdiotOnTheNet wrote: post #289
zanny wrote: post #269

Earlier quoted context omitted.

I don't believe for a second it requires "natural aptitude" to program. The problem is any programming curriculum starts with a text editor open. If a developer-to-be doesn't understand the framing context of what they are doing they are being dropped in a lake with no sense of direction. Its why all the "naturals" started as geeks who played with computers from a young age. You learned about the environment you woul…

We convinced our parents to buy a computer because it would help our education when all we really wanted one for was playing computer games. Joke was on us though, because playing computer games at the time usually involved a lot of putzing around and figuring out how stuff worked, ultimately teaching us marketable skills.

Totally true.

In my case it was a natural progression: "videogames are great!" -> "I have an idea for even better videogame!" -> "how do I make one?" -> "can I tweak this one into being a bit more the way I like it?" -> tinkering around data files -> "I really want to make my own game" -> picking up a programming book at 13 -> a programming career.

Re: Harder programming questions do a worse job of predicting outcomes

#352

Post by castlecrasher2 »

lovecg wrote: post #297
mlthoughts2018 wrote: post #97

Earlier quoted context omitted.

> “The SV companies must have a good reason for this” In fact, no, nobody has a good reason for it.

Go start a company. Hire people without doing any sort of coding interviews. Report back in a year. The reality is that these are extremely desirable positions with a staggering number of applicants who _do not know how to code_. Not as in “I can’t solve a dynamic programming problem without studying up on it”, but as in literally don’t know what a for loop is. The process is far from perfect and the frustration is u…

I imagine technical screening is necessary, but in-person coding assessments are nonsensical. It's not like programming is a spectator sport, so why are we tested on it live? I suppose the process is self-selecting, because I personally have given up responding to SV recruiters or interviewing with those companies.

Re: Harder programming questions do a worse job of predicting outcomes

#353

Post by riskneutral »

tombert wrote: post #125
griffinkelly wrote: post #74

Earlier quoted context omitted.

I've worked with some folks who were decent engineers who originally didn't get offers from FANG companies because they blew the interview; they later studied their ass off on leetcode and got offers. This did not make them better engineers at all. Ultimately, its just studying for the test, very much like the ACT/SAT in high school. You can be great at taking tests but ultimately a terrible student or vice versa.

I go back and forth about how I feel about doing heavy algorithm/data-structure stuff in interviews. On the one hand, I have never once written any kind of sort algorithm or LRU cache by hand for a production system, because why would I? Pretty much every language's standard library has a fairly-optimized sort and caching thing built in, and if they don't then there's still probably a million outside libraries to do…

> On the other hand, I genuinely do feel theory is really important. While not knowing the minutia of a tim-sort doesn't indicate that you'll be a bad engineer, not knowing the runtime efficiency of a sort can lead to some really awful code.

OK but why don’t these interviewers ever ask “internals” questions? How does a CPU works, or what the different levels of memory hierarchy are, what an interrupt request is, what is pipelining, what is SIMD, what is a GPU, etc. Or how about compiler internals, what are the different stages in a compilers, what are the different grammars and parsers, what is an AST, what is interpretation, compilation, bytecode, JIT, and how does it work? How about database internals? How is a database implemented, what is relational algebra, what is normalization, what is a data model, how do indices work? Similar questions can be asked about operating system internals, networking, floating point arithmetic, etc. In my experience, no interviewer has ever asked me these questions. And as an interviewer, I have consistently been disappointed with candidates’ inability to answer basic and relevant “internals” questions. Ironically, the algorithms and data structures questions that are commonly asked in interviews are outdated ways of thinking which do not take the underlying hardware reality into account (memory hierarchy and parallelism). It could be because a lot of these FANG(-like) “engineers” are themselves not knowledgeable to ask such questions. Or they are aware that new comp sci graduates are unlikely to really understand anything at a deep level, but all comp sci students are drilled on algorithms and data structures. If you are targeting a very specific age group (0-5 years experience) and want a standardized test then I guess asking CS201 exam questions in a job interview make sense. Companies prefer the 0-5yrs experience segment because they’re cheap, don’t have children, are easy to exploit, and they are easier to “mold” into your corporate culture.

Re: Harder programming questions do a worse job of predicting outcomes

#354

Post by alboy »

erik_seaberg wrote: post #315
alboy wrote: post #250

Earlier quoted context omitted.

One could argue that CS undergraduate degrees are perfectly suited for this purpose. FAANG & Co don't seem to care for that. You've successfully passed a few dozen exams at MIT or Stanford? Well, let's make the reasonable assumption that you have no clue about algorithms and data structures and start with our third whiteboarding session, that should be a way better proxy for your knowledge.

Those incentives are misaligned. Not every law school grad can pass the bar.

They may very well be, but is the quality of signal truly worse than that which an interviewer can extract from a few hours of your writing code on the board?

Re: Harder programming questions do a worse job of predicting outcomes

#355

Post by knightofmars »

cubano wrote: post #341
glangdale wrote: post #266

Earlier quoted context omitted.

I'm pretty sure it's age discrimination plain and simple. The only time in my life I would have been in great shape for the standard interview process without a good deal of study was a couple years in early graduate school, where nearly all of this "breadth" stuff was fresh in my mind. The relentless scepticism about people's achievements is to some extent understandable (we've all run into the senior person who can…

Without a doubt it's age discrimination...you've hit the nail on the head. Also, God help you if you have followed a non-traditional career path where you decide at points in your life that you wanted a break from it all. I, too, in 1988, fresh out of my BS in CP with no family or life experiences and a strong desire to code day and night would have sailed past the technical side of these often ridiculous interviews…

They don't want to pay you what they think (the you in their heads think you think) you are worth. That sounds convoluted but I've watched it happen repeatedly.

Bill budget IT guy, "What? We need to harden a server? Why do we need to pay this guy over a hundred thousand a year to do that? The internet is full of documentation. Let's hire someone with just enough technical know how to implement it."

The reality on the other side is that hiring an experienced engineer has it's risk. I've worked with 20+ years of experience engineers who did it because it was a job and didn't deserve the salary based on their skill set. Companies let this happen, you need to cap positions and then give inflation based raises.

Re: Harder programming questions do a worse job of predicting outcomes

#356

Post by Gibbon1 »

gizmo686 wrote: post #246
ohyes wrote: post #208

Earlier quoted context omitted.

What’s frustrating to me is that we haven’t found a way to teach programming that doesn’t rely on natural aptitude. It’s really a travesty that we can’t teach it the same way that we teach maths or natural languages. The end result is we’re left trying to divine whether someone is the programming equivalent of being illiterate. As with illiteracy people find ways to fake it.

As someone who has studied both math and computer science (and is now a professional programmer), I have no idea what you are talking about. We are far better at teaching people to program than we are at teaching them to do math. Its just that most people self select out of math [0], so, due to selection bias, it appears that we are great at teaching those that remain. As an aside, as someone who also studied linguis…

I took math as part of my engineering degree. And that was 30 years ago. The older I get the more I think the way it was taught was terrible. Same reason I think teachers are bitching about the US's fetish for academic testing. Testing pressures teachers to teach students to mechanically solve problems. But with shallow understanding.

Re: Harder programming questions do a worse job of predicting outcomes

#357

Post by abhishekjha »

djhworld wrote: post #57
davidhyde wrote: post #25

I think that asking a candidate to perform a code review can be an effective method of evaluating quite a few desirable qualities. Can they understand someone else's code? Can they engage in constructive critical discussion? Are they able to effectively refactor something to make it better? Can they spot mistakes and do they have an opinion about how to avoid such mistakes?

Yeah that's great but what if they can't reverse a binary tree?

Looks like I am gonna have to look at the solution as I don't fully get how to achieve that structure. Recursion is good for a few standard problems but those are just standard problems. We shouldn't try doing every possible thing using recursion, even if it is possible to do so. Also, debugging an iterative solutions comes naturally to me compared to recursion. I guess I don't have the right mental model for how to track recursion/recursive calls.

Re: Harder programming questions do a worse job of predicting outcomes

#358

Post by kragen »

mlthoughts2018 wrote: post #104
SilasX wrote: post #75

Earlier quoted context omitted.

What stops someone unqualified from getting through? What other filters do you apply?

Probing someone with very technical conversation about past technical projects is a much stronger filter to prevent unqualified candidates than passing CoderPad tests, whiteboard algorithms, etc. The conditional probability you are hopelessly lacking software skills to do a job given that you nonetheless passed a TripleByte exam or something is quite high. Overfitting & memorization for the sake of the test is extrem…

Are you talking about TripleByte exams from experience, or are you speculating that they are similar to other software interviewing processes? The questions they asked me covered what I think of as a staggeringly wide range of knowledge, including sysadmin stuff, detailed knowledge of four or five programming languages, POSIX semantics, high-level scalable systems architecture, and so on. It seemed to me that it would be very difficult to "memorize for the sake of the test".

Re: Harder programming questions do a worse job of predicting outcomes

#359

Post by ball_of_lint »

delphinius81 wrote: post #165
brownbat wrote: post #133

Earlier quoted context omitted.

Does anyone just give you someone else's code and have you write tests and documentation for it?

I had a coding test once where I was given someone else's code with an introduced bug, and I had to fix the bug. To do so, you were basically documenting the code along the way as you traced your way through possible trouble spots. It felt far more meaningful than the typical "implement some list traversal algorithm that you won't actually ever use at this job."

I've had a similar interview and although I did not solve the bug, I think the interview was much more effective than most algorithm based interviews. Not only did my interviewers get to see how I navigate a codebase and use my IDE/other tools, they also saw how I approached known unknowns and discovered information.

Re: Harder programming questions do a worse job of predicting outcomes

#360

Post by vmasto »

toasterlovin wrote: post #344
warp_factor wrote: post #335

Earlier quoted context omitted.

To make it clear, I absolutely hate coding interviews that makes candidate lose so much time restudying. I think having some critical-thinking is absolutely needed and way too many engineers lack some (especially those swallowed into FANGs) What I described on my previous post is a credible explanation that my group of engineer friends came up with on why all the FANG companies pursue those heavy memorization algorit…

To my mind, the more likely explanation is that they would simply get too many false positives if they didn't use the algorithm stuff to filter potential hires. You lose a lot of potentially good hires that way, but the pool you're left with are all of a certain intelligence level. Whereas, if you don't use the algorithm stuff to filter, it's really hard to figure out who is even intelligent enough to do the job.

I'm not following, how does memorizing algorithms correlate with intelligence and skill in the engineering discipline of the job?
Post reply on HN