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

Lessons from 3,000 technical interviews

blog.interviewing.io

Post reply on HN
Print view View original

91–100 of 330 posts

Re: Lessons from 3,000 technical interviews

#91

Post by cookiecaper »

moxious wrote: post #59
fecak wrote: 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…

I don't think curiosity diminishes with age, even if the ability to explore that curiosity may. You can still talk to someone and find out if they are interested in experimental technologies, what they choose to tinker with in the limited discretionary time they have, and so on. You can ask about their opinion on new technical developments and whether they follow any trade publications or forums and the coolest things they've found from those places in the last few months.

Since for programmers at least, such information is not hard-separated from the course of their normal work, they will usually have the opportunity, if interested, to be at least partially informed about such things and have some sense of the overarching zeitgeist. For instance, a C# developer would be fully justified in reading about the changes slated for the next iteration of C# during his/her day job, especially as that iteration neared and achieved release.

On top of this, professional engagement and awareness IS something that deserves out-of-work nurture time, even when you have a family or other demanding non-work obligations. You don't have to have an impressive free time project like a hand-built CPU, but expecting someone to put in a few hours a month to tinker, learn, or explore new things related to their field is not unreasonably demanding IMO, even for experienced/busy professionals.

Obviously "participated in a MOOC [Massive Open Online Course, btw, for those curious]" may indicate curiosity (though it may also indicate someone trying to short-circuit their lack of skill by gaining Yet Another Credential to ride off), but it's far from the only signal.

The best employee is an experienced person who has retained their intellectual curiosity, even if they don't have the time to fully exploit it.

Re: Lessons from 3,000 technical interviews

#92

Post by ma2rten »

Until recently I worked at a startup as Machine Learning Engineer/Data Scientist. There I got some experience interviewing people and looking at their resumes. In my experience, which is very limited compared to this post, people who put an MOOC on their resume are usually less qualified compared to people who don't.

There is nothing wrong with MOOCs, but they are almost always beginner-level. If you put them on your resume it kindof implies you don't have a lot of experience beyond that. Putting the Coursera Machine Learning course on your resume would be the equivalent of putting Java 101 on your resume for a Software Engineer.

I would recommend anyone to put projects on your CV instead. Even if you don't have a lot of work experience, just put side-projects and school projects on there.

Re: Lessons from 3,000 technical interviews

#93

Post by auggierose »

BOOSTERHIDROGEN wrote: post #68
fecak wrote: 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…

Im not quite understand why recruiters asked books on reading list?

I don't understand that either. I read papers, not books.

Re: Lessons from 3,000 technical interviews

#95

Post by dragonwriter »

kimcheekumquat wrote: post #66
nickbauman wrote: post #40

Earlier quoted context omitted.

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.

Wealth also correlates with intelligence. Intelligence is mostly determined by genetics (studies show ~70% to 80%).

> Wealth also correlates with intelligence.

Given that many environmental conditions to which exposure (in many cases, particularly early childhood exposure) demonstrably adversely impacts intelligence are more likely to be avoided with wealth (that is, both inversely correlated and with a clear causative mechanism for that correlation), this isn't at all surprising.

Re: Lessons from 3,000 technical interviews

#96

Post by ryanworl »

JamesBarney wrote: post #63
chewyshine wrote: post #24

Earlier quoted context omitted.

If the interviews are "structured", the correlation between interview performance and job performance is probably around .3 based on meta-analyses of research findings. If the interviews are "unstructured", the correlation will be within sampling error of zero.

Do you have a source for this? I totally believe you, but I've been trying to find good empirical studies and authors to read on interviewing.

Not the person who originally replied to you, but the HR class I took in college broke down the correlation of interview performance to job performance into a few finer-grained buckets than just structured and unstructured. Sorry, no sources here, as I've since gotten rid of that textbook.

Structured vs. unstructured are the fairly general categories, but that correlation number is accurate. The best predictor I can recall (~0.6 IIRC?) is a "work sample test". You can Google that and find all kinds of HR resources about it.

That is HR jargon for, in this case, writing code to solve a real problem under normal conditions for that company. That is, on an actual computer, not on a whiteboard, and not being constantly scrutinized throughout the process.

Re: Lessons from 3,000 technical interviews

#97

Post by aquadrop »

collyw wrote: 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…

I guess it might be because with experience your expectations also rise. You may be easily qualified for starting programming position somewhere, but now, when you're more experienced, you'll aim higher, right?

Re: Lessons from 3,000 technical interviews

#98

Post by Apocryphon »

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.

Re: Lessons from 3,000 technical interviews

#99

Post by ashwinaj »

hcatlin wrote: post #80
fecak wrote: post #73

Earlier quoted context omitted.

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…

I'm sure this happens, yes. But, that's not what's going on here, IMHO. 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' Most of these interviews are more like math problems than anything a practical developer would encounter. Shit, if these interviews were "What do you think of node?" or "What is Go's concurrency model?" I think ex…

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

No. No one in their daily jobs implements a linked list or B-Tree. There are predefined libraries in the languages or a user created library that people use. Do you really think every person in the company has his/her own version of a linked list in the same code base? This is a fallacy perpetuated time and again. (I'm not against these type of questions, but they don't represent someone's true ability)

Building a product, app, project requires application of this knowledge: eg., I need to design a distributed data store, should I use hash map? What about collisions? Should the collisions be resolved by chaining (linked List) or another map? What kind of data am I storing? Can that be exploited to make this more efficient, synchronization of data across nodes (?), etc..

Many of these interviews completely overlook someone's design ability and harp on some straightforward (and some obscure) topics which IMO has little to no co-relation to someone's ability as a software engineer.

Re: Lessons from 3,000 technical interviews

#100

Post by joshvm »

blazespin wrote: post #4

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.

The conclusion is a bit obvious: if you ask people algorithms questions, the people who do the best will be people who spent a lot of time rote learning algorithms material. This means schools which place a lot of emphasis on the theoretical core or people who've taken online algorithms courses.

I'd be much more interested to see performance on other questions e.g. Google's typical curveball for new grads is an architecture question like "How would you implement YouTube?".

Post reply on HN