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…
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…
Lessons from 3,000 technical interviews
121–130 of 330 posts
Re: Lessons from 3,000 technical interviews
#122Earlier quoted context omitted.
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' 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…
Re: Lessons from 3,000 technical interviews
#123Earlier 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 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 thing…
I think it definitely does, depending on the person. Many, many attributes of the person change over time. That's what growth and evolution is about!
Some people take a career path where they become expert at a narrow topic. As they master their field, I think they lose a lot of curiosity because there's simply less to be curious about unless they're on the forefront of research and not just a practitioner.
Other people simply develop other life priorities.
It's 100% an individual thing.
Re: Lessons from 3,000 technical interviews
#124Thanks 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…
Thank you, and thanks Aline!
Re: Lessons from 3,000 technical interviews
#125Interesting 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…
Re: Lessons from 3,000 technical interviews
#126Interesting 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…
Re: Lessons from 3,000 technical interviews
#127Earlier 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…
I've never used Go, don't really plan to unless I have to, nothing wrong with it just not my area of expertise and I'm busy with other toys although I'm sure its a very nice language, and if I went up against a non-technical or technically weak interviewer (aka almost all of them) I could probably BS my way thru based on what I do know about concurrency in general. Although after decades of experience, the reason why I'm not still programming in 6502/Z80 assembler is I'm good at that whole "BS my way thru till I'm an actual expert" thing, so maybe I'm talking myself into agreeing for non obvious reason!
BSing skill is under-rated. If you can't BS your way thru something that you don't entirely understand (because you're lazy), then when you're at the cutting edge developing or debugging you'll have trouble BSing about stuff that no one on the planet understands. Not all the worlds problems have a stack overflow question or a script reader at a support hotline, and how you deal with that gut check says a lot.
Re: Lessons from 3,000 technical interviews
#128Earlier quoted context omitted.
What about the way she collected and analyzed the data caused the correlation to falsely be poor or negative?
Nothing! The author explicitely states that the data and analysis was not granular enough tp make distinction between the different kinds of MS degrees. This leaves open the possibility rhat some categories of MS degrees might correlate positively, even though MS degrees overall correlate negatively.
>>>No surprises here. I’ve ranted quite a bit about the disutility of master’s degrees, so I won’t belabor the point.
is literally all she says about MS degrees. Wow the bias of this site is incredible..
Re: Lessons from 3,000 technical interviews
#129Not 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.
For many reasons.
I find some creators put a lot of ego into their products, not that they are egoists so much, but doing something on your own can be emotionally challenging. I don't mean 'ego' in a negative way - just that when you are on your own you have to make so, so many decisions. APIs, compatibility, etc. etc. you're often a little overwhelmed, you often have to 'just do it' and 'go with your gut' in many areas. Which may or may not be a good practice/attitude for a Google employee.
They might have a stronger sense of the 'outcome' (i.e. what it does) than the capacity for the underlying code. Maybe it 'does the job' but is poorly written? Which again, might not work in Google environment.
... and working on a very large team is night-and-day from working on your own.
I think we all want to 'feel it is unfair' that such an important contributor somehow 'can't get a job at Google' ... maybe he's worthy, maybe not, but I can totally grasp someone mighn't be a good contributor at Google.
Maybe it's easier to see it from a non-technical standpoint: it's often very difficult for founders of their own companies to get along in a place like Google. I think that's easier for us grasp. The same thing can apply in the technical domain.
Re: Lessons from 3,000 technical interviews
#130Earlier quoted context omitted.
What about the way she collected and analyzed the data caused the correlation to falsely be poor or negative?
Nothing! The author explicitely states that the data and analysis was not granular enough tp make distinction between the different kinds of MS degrees. This leaves open the possibility rhat some categories of MS degrees might correlate positively, even though MS degrees overall correlate negatively.
http://blog.alinelerner.com/how-different-is-a-b-s-in-comput...
Is what she says about MS degrees in another post. No data or analysis is shown, just opinion.