Live data from Hacker News

Lessons from 3,000 technical interviews

blog.interviewing.io

161–170 of 330 posts

Re: Lessons from 3,000 technical interviews

#161

Not to harp on the "technical interviews are disconnected from actual work!" angle too much, but I'm reminded of a comment from a thread about the creator of Homebrew failing a Google interview. Someone pointed out that it goes to show that it's possible to create widely-used software without an intimate knowledge of CS. I wonder if that's a disconcerting fact for some employers to grapple with.

Google's specific interview standards only select for academic rigor, not just successful software skills.

Look at how many failed or poorly designed products and libs Google has released.

Re: Lessons from 3,000 technical interviews

#162
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…

Um, did you actually look at the article? There was no data shown between interview performance and MS degree status. The graph you saw was interview performance vs. years of experience. This isn't surprising since a person with 20 years experience will generally interview for a much more challenging job than someone with 0 years.

[deleted]

Re: Lessons from 3,000 technical interviews

#163
post #81

Earlier quoted context omitted.

It'd be nice if we had on hand a lemma that stated that intellectual curiosity, once "proven" as a property of one phase of a person's life, will remain as a property of that person in all later phases, even if the indicator signal for it disappears. Then we could just look for people who look like they once were intellectually curious (perhaps in college) and then hire them on the basis that they'll be able to pick…

It would be nice, but I think we'd be hard-pressed to ever agree on what intellectual curiosity even is. It's one of those "I know it when I see it" things. I could evaluate whether a person has it (to my standard) but would someone else accept my call, 5 years later, for their company?

A proxy might be "did you study something non-trivial, without your work forcing you to, in last 1-2 years?"

Re: Lessons from 3,000 technical interviews

#164
"We got this data from looking at interviewees’ LinkedIn profiles."

Verification of completion and award id? There are a lot of individuals who will add a degree regardless of attendance, completion or award. Who validates the assertions?

Re: Lessons from 3,000 technical interviews

#165
"Whether passing an algorithmic technical phone screen means you’re a great engineer is another matter entirely and hopefully the subject of a future post."

This sentence plus the inverse correlation between experience and "interview performance" shown there. Makes a big smell about how biased are those interviews to themselves and not to real technical interviews.

From the data it looks like the questions asked using that service are the ones you might learn in university and after many years not using them, that knowledge fades away because you're not using it.

This is reinforced by MOOCs being the 101 of the subject they're dealing with. It would be interesting to see if there are trivia questions from 101 courses.

The most obvious bias is in the clickbait title. Those 3K interviews are in a specific platform, meaning they're done in a specific way.

So after checking their results it seems that interviews done using that service benefit people with fresh university or 101 lessons knowledge.

What worries me more is the lack of improvement and perhaps the moral superiority of ending the article with a "these findings have done nothing to change interviewing.io’s core mission". It feels like the entire statistics game shown there was to feed back what they already knew.

Re: Lessons from 3,000 technical interviews

#166
The master's in CS can be useful if:

1. You have an undergrad degree in liberal arts 2. You pay as little tuition as possible 3. You take no time off and continue to work FT

These apply to me -- my undergrad was in English, I paid 6k total (27% of the 21k total cost) and went to school at night over 4 years while my career continued to progress.

Most of the people in my program couldn't write a FOR loop if their life depended on it, they viewed it (incorrectly) as a jobs program while the school needed the $$ to keep the dept afloat, so I'm not surprised they fared poorly in technical interviews.

But that doesn't mean the degree isn't useful. If you're already a programmer, it helps get your foot in the door at many places. HR managers/recruiters feel more confident forwarding on your résumé, they can't parse your GitHub repos.

The degree is icing on the cake, it's not going to magically turn you into the Cinderella of Programming if you have no real-world experience. I got my master's with a QA and a paralegal and today? They're still a QA and a paralegal.

That being said, timed technical interviews are almost universally asinine, IMHO. When in real life do you have 10 minutes to figure out a problem? Or are prevented from Googling the answer? The measure of successful programmers is how efficient and professional they are in problem solving, not how much useless information they can keep in their head.

Things I've never had to do in 'real' life: -Never had to split a linked list given a pivot value -Never had to reverse a string or a red/black tree -Never written my own implementation for Breadth First Search

etc etc

Personally I'd rather see take-home assignments that roughly approximate the type of work you'd do, which in my career has been churning out new features or applications. Does knowing the time-complexity of radix sort vs heap sort really have a material impact on your effectiveness as a programmer? No.

Re: Lessons from 3,000 technical interviews

#167

Earlier quoted context omitted.

Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job' Yes, it is. More to the point, it's built-in bias toward recent college graduates. Once someone's actually been out in the real world programming for several years, any space in their brain's metaphorical working set that was ever dedicated to remembering how to do this stuff has long…

I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems. If you have trouble with those, I'm going to really wonder if your programming skills are really very good to begin with.

They're not particularly difficult. You usually take the algorithm definition and implement one, as you did in the university or in the Coursera algorithms course. Fun, you might learn a thing or two about the language you're using.

If the point of the exercise is a TRIVIA question, leave the interview. On the other hand, if the point of the exercise is not to get the right solution but see how you think and how you use basic programming blocks, then you're in the right place.

I've used the linked list question. And the goal is not for me to check if it is "not difficult" for you. Because I might not be able to teach you what a linked list is in 5 minutes while you're nervous in a technical interview. But to work on technical problems and see the following:

- Can you speak your mind so your peers know what are you doing?

- Will you ask for help?

- Will you accept help and feedback?

- Can we have a discussion about something that there are many "right answers"?

- Do you know the basic building blocks of the language you decided to use? <-- This plus javascript plus references is very funny.

Re: Lessons from 3,000 technical interviews

#168

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.

Interviewing skill is one way you get a job. After you've been doing this for long enough, and have a reputation, you tend to just get jobs by referrals.

I decided in my last change of positions to try interviewing for jobs like most people without referrals, since I had several other referral positions open.

And I was horrible. I was ridiculously bad, and couldn't get a job at jobs that paid less, and were for less skill. It was quite hilarious.

Thankfully, all of the referral jobs were begging for me, and that was fine. There was no real loss, but it was a bit concerning that if I didn't have an extensive connection network that I would be in a significantly worse role.

Re: Lessons from 3,000 technical interviews

#169

Not to harp on the "technical interviews are disconnected from actual work!" angle too much, but I'm reminded of a comment from a thread about the creator of Homebrew failing a Google interview. Someone pointed out that it goes to show that it's possible to create widely-used software without an intimate knowledge of CS. I wonder if that's a disconcerting fact for some employers to grapple with.

Made a similar comment above, but that was entirely true for myself. I have worked on amazing things as we all have in life, petabyte databases, and just the most incredible setups.

But when it comes to an interview, I cannot get a job several levels below my own (without referrals).

With referrals, I am offered the moon and the stars, complete pick out of a tremendous number of amazing jobs.

But any random interview, and I totally bomb it. I wonder how many out there are like that as well. It feels rather strange from my perspective, but maybe it's fairly normal?

Re: Lessons from 3,000 technical interviews

#170
post #73
post #59

Earlier quoted context omitted.

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

I see this pattern time and time again in both my recruiting work and in my resume business. Someone gets a rather non-challenging job that pays market rate or better, starts a family, pays little attention to any tech outside their day job, and suddenly finds that their marketability outside the current job has suffered greatly. As developers get older, they need to be conscious of the relevance of their work in reg…

That's a problem with... "people looking for shiny things". There are many shiny things, and they loose their shine quite fast.

It is true that many managers, recruiting agencies (almost 100%), and HR, will look for the keywords of the technologies the company is using. So if they use the new Angular 4, they will look for that.

But there are companies that look for the basics: do you know javascript? Have you worked with SPAs? And these are the ones that IMHO deserve your time to apply.

Because tomorrow, today's current trends will be tomorrow's trends. Companies looking for people that can adapt say a lot about what kind of work place will you find there.

Post reply on HN