Live data from Hacker News

Lessons from 3,000 technical interviews

blog.interviewing.io

51–60 of 330 posts

Re: Lessons from 3,000 technical interviews

#51
post #14

Interesting bit on the MS degree. I followed the link, and I'm not quite as surprised that the correlation is poor, or even negative, given the way the data was collected and analyzed. Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers. However, many CS MS degrees actually do requi…

I got a CS masters and even though it was a worthwhile experience to me but I never expected to necessarily make more or be chosen over another candidate purely based on education (assuming all other things being equal.

I felt like my knowledge definitely cured during the process with graduate level data structures, architecture, operating systems and networking. The 2nd pass on some of these areas (despite getting mostly A's from a generally-considered challenging but now well known program). I took the opportunity to craft my program of study more than I would have been able to as an undergrad (both due to lack of knowledge and how undergraduates are given a lot less leeway) to include electronics and automation courses. It also gave me the opportunity to work with and mentor other students which was rewarding and I think has benefited me in and out of the workplace.

I wouldn't argue for doing it purely for career reasons and its not something to do just because you've been in school so long you don't know how to do anything else, but I found it worthwhile and you just need to consider what you want out of it.

Re: Lessons from 3,000 technical interviews

#52
post #14

Interesting bit on the MS degree. I followed the link, and I'm not quite as surprised that the correlation is poor, or even negative, given the way the data was collected and analyzed. Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers. However, many CS MS degrees actually do requi…

> Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers. At what point do we not consider operating systems and compilers "fundamental"? What percentage of CS/programming jobs require deep knowledge in these arenas?

Absolutely I think they still should be considered fundamental.

By definition, these are the subjects that allow you to keep going when your abstractions leak[0].

To say a job "requires" them is pedantic, but what's the point of calling something a CS degree if it is not at least signaling an understanding of these fundamentals.

[0] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

Re: Lessons from 3,000 technical interviews

#53

Top school is probably serving as a proxy for intelligence in this analysis...a well known predictor of both interview and actual job performance.

Top school is also serving as a proxy for wealth and privilege. Good grades are also a proxy for wealth. Kids who have rich parents get private tutoring.

The privilege to value education and to spend time studying, yes. Almost all resources can be found online nowadays. If you've ever been to an SAT tutoring class, you know that the only benefit the kids have is the benefit of being forced to take practice tests.

A top school is a good signal for how much time someone spent studying in high school, except for affirmative action students who get into top schools with much worse scores and GPA.

Re: Lessons from 3,000 technical interviews

#54
post #33

Earlier quoted context omitted.

> the majority of actual tasks are often googled and stack-overflowed The more I've grown as a developer the less I've had to do this.

Ah damn; and I had been doing so well mushing down my imposter complex :P I've found the exact opposite, the longer I dev the more I look for things. I've found it entirely impractical to keep the esoterica of dozens of different languages, frameworks and tools in my head at once. What little memory I have is typically reserved for thinking about abstractions, arch/features, and core concepts, and I let myself lean h…

Working within a single language (Python), I've come to the point where I have sufficient knowledge to be able to answer many things about it without googling. However, my false positive rate is sky high because I know too many implementation details. It was unavoidable in working within a particular stack for ~5 consecutive years, but the false confidence it promotes can be counterproductive, as well as useful.

Re: Lessons from 3,000 technical interviews

#55

Earlier quoted context omitted.

Ah damn; and I had been doing so well mushing down my imposter complex :P I've found the exact opposite, the longer I dev the more I look for things. I've found it entirely impractical to keep the esoterica of dozens of different languages, frameworks and tools in my head at once. What little memory I have is typically reserved for thinking about abstractions, arch/features, and core concepts, and I let myself lean h…

I back you up on this. I'm about 10 years in my career, and I use SO more and more. Because, conceptually, I know what I want to do. Last night it was trying to use the asyncio library for Python 3 to use sockets. I know what I wanted to do: async, accept, listen, read and write to sockets. But how, _specifically_, do you do that with python 3 ? Don't know and dont care. Ask SO or find someone's blog howto and be don…

You may appreciate this: https://tldr-pages.github.io/

Re: Lessons from 3,000 technical interviews

#56
Thanks for writing this Aline. As a recruiter for almost 20 years, I wish I had access to all my data and then the time to compile it, and anecdotally I'd expect the finding about MOOCs would be similar.

The most selective of my hiring clients over the years tended to stress intellectual curiosity as a leading criterion and factor in their hiring decisions, as they felt that trait had led to better outcomes (good hires) over the years. MOOCs are still a relatively recent development and new option for the intellectually curious, but it's not much different than asking someone about the books on their reading list.

Unfortunately, demonstrating intellectual curiosity often takes up personal time, so someone with heavy personal time obligations and a non-challenging day job is at a significant disadvantage. One could assume that those who have the time to take MOOCs also have time to study the types of interview questions likely favored by the types of companies represented in this study.

Thanks for continuing to share your data for the benefit of others.

Re: Lessons from 3,000 technical interviews

#57

I am perplexed why anyone would think that interview performances has any interesting statistical relevance. Much more interesting would be how successful the candidate was after receiving a job at the company.

Because interviewing skill is how you get a job.

If I am looking for a job, I care a whole lot about what would make me better at getting jobs.

Re: Lessons from 3,000 technical interviews

#58
post #16
post #2

Interesting and surprising, especially the experience thing. I think I am a significantly better engineer than earlier in my career, so I assumed experience would count for a fair bit. Then again I have inherited projects from experienced guys who make crap high level architecture decisions and the code is way more difficult to work with than it ought to be. But then this article seems to be measuring interview perfo…

Most of the things that make us better during our career have nothing to do with programming faster: If anything, they can make us program slower, and do worse in interviews. For instance, an interview I took last year came with a premise that I found downright bonkers. It was based on code the company had in production, but it stopped being a good problem to look at years before. I was having trouble coming up with…

Most pedagogy, over time, gravitates toward what's easy to measure, not what's valuable to learn. So we've been very lucky in hiring by network even though we kinda feel terrible about it. On the other hand we're hiring more women now too as a result, not least because women are now much more conscientious about managing their network of other female developers than men.

Re: Lessons from 3,000 technical interviews

#59
post #56

Thanks for writing this Aline. As a recruiter for almost 20 years, I wish I had access to all my data and then the time to compile it, and anecdotally I'd expect the finding about MOOCs would be similar. The most selective of my hiring clients over the years tended to stress intellectual curiosity as a leading criterion and factor in their hiring decisions, as they felt that trait had led to better outcomes (good hir…

> Unfortunately, demonstrating intellectual curiosity often takes up personal time, so someone with heavy personal time obligations and a non-challenging day job is at a significant disadvantage.

This is true, and one of the things that tends to stack disadvantages against people who are older in the industry. There's a good correlation between free time and age in some ways, as people get to mid-career they tend to marry, have kids, and so on. Maximum free time comes during college and immediately after, for many people.

Valuing intellectual curiosity also tends to mean that this curiosity is valued over direct experience, which is what the older more time-strapped people have to offer relative to younger people who are doing the MOOCs.

Re: Lessons from 3,000 technical interviews

#60
post #5

Very unsurprising for me. You are measuring your ability to solve algorithm puzzles. Most engineers don't actually do many algorithm puzzles in day-to-day work, especially the types of algorithms that interviews tend to focus on like sorting and dynamic programming. So "years of experience" is not measuring experience in what you're actually being tested on. On the other hand, you do exactly those types of things in…

Those riddles are second semester problems on CS, thus anybody that isn't an student spent at least the last 4 years not working on them. The same probably applies to top companies, people probably interviewed there more than 2 years ago. But Coursera stuff that gets into a CV is almost certainly recent.

Totally agree with this. I'm reminded of when I interviewed with Amazon a few years back and it was clear that the questions were best suited to filtering down to the best graduates. In my mid 30's I was too rusty to satisfy the interviewer and my real world experience counted for nothing as the entire process was structured like a series of exam questions.

I think there's a point - I would guess at about 8+ years of experience - where a technical interview will stop being a reliable indicator of an engineer's ability. It then becomes more important to evaluate what the candidate has been doing in their career and how that experience can be taken advantage of within the team that they'd be joining. Technical ability can still be judged by asking to see some existing code if it's that essential.

Post reply on HN