Hacker News Reader

Comment by fecak | Hacker News Reader

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.

View on HN

"Intellectual curiosity" was my primary attribute for many years. Particularly when I was young and didn't really know any better. It makes sense doesn't it? Someone who is interested in learning for learning's sake will be a better developer!

Except I'm convinced it's not really true. It's something that is horribly subjective and really self-selective. It's funny, intellectually curious people often have exactly the same interests as whomever is doing the interview. I find that nearly everyone loves to learn, you just have to find the thing they're interested in learning about.

The signal that I have found to be a great indicator of success on my teams isn't about curiosity at all. It's about attention to detail. In the world of scatter brained developers who never seem to really follow through on anything, it's those guys that are the real unicorns.

Our interview process is now designed to bubble that to the top. Vague programming problems with poorly defined requirements provide a platform by which we can see how someone digs into problems. I'll ask for them to send me a couple of things after the interview, it's a really good signal when they pull out their phone and add it to a to-do list.

Those guys may not always be the "smartest" or the most interesting, but man when you're going to spend months working down a really large project they get stuff done.

> It's about attention to detail. In the world of scatter brained developers who never seem to really follow through on anything, it's those guys that are the real unicorns.

I've done a few hundred technical interviews over the years and this is absolutely true. It's these guys who make production ready systems possible more than anybody else.

You had me until, "it's a really good signal when they pull out their phone and add it to a to-do list."

Because it's just one of many possible courses of action for staying organized. For all you know the guy added it to his to-do list on his way to the car, or maybe he employs some other mechanic. While you could argue that an interview is a showboating environment where one is expected to signal certain desireable traits, I personally resent that these attributes seem to manifest in recruiters as specific actions that reinforce their perceptions of a good candidate -- if someone is unconventional then how is looking for specific signals going to tell you anything useful about them?

It's a signal. It's not a binary yes/no, there are many observations we're making throughout the interview. This is just one, and the to-do list isn't the only correct answer. Asking me to email those details to them is another possible right answer. Writing a note in a notebook is fine.

The key thing to remember here is that we're asking this very much in the middle of the interview, and I just want to see that they have some sort of system in place for remembering these things.

In my experience, most of the time, simply going "sure, I'll do that" and depending on memory to actually get it done is a negative signal. Maybe they are particularly gifted in terms of memory, but in my experience that is rarely the case.

In hiring we're willing to accept false-negatives, but never false-positives. You are correct, I may let a perfectly good candidate walk, but I'm willing to accept that as the cost of hiring a bad one is just too high.

I would not have written that down, but I can assure you that I would remember to send you whatever you asked: An interview setting is very special, and tend to get hyper focus. I wouldn't go out from there wondering the typical "man, that was intense - wonder how it went??", and then forget to send you those things you asked!

Unless your request was very specific and strange ("send me the completed k3-45 and t9807 forms"), in which case I'd have to jot /that/ down.

Should you not rather evaluate whether your request was fulfilled?

So the requests are often a bit strange (relevant to the interview tho). Usually asking for a citation for some claim made during the interview. I also make a point to ask in the middle of the interview so there's lot of times to forget.

Again I do want to stress: This is a small detail as part of a larger interview. Screwing this one thing up isn't going to sink you, but we combine it with a bunch of other signals and observations to make decisions. I've been doing this for several years, and I'm very happy with the results.

I sincerely think the downsides of a false positive are vastly overrated.

IMHO the real problem is the strict barrier between people who are part of company and non-company. Imagine if we had a more permeable membrane with different departments hiring firing as they see fit (a faster flow than this structured hiring). This would test the candidates on working in the real environment rather than the whole magic and mysticism of made-up work scenarios in interviews.

In fact I wish we had a more libertarian system inside companies with more free markets rather than all the central planning which happens now

As it happens I have a poor temporal memory so the most important tool I have is I always carry my notebook and jot down everything that gets said, particularly as my previous role involved coordinating and managing teams and projects.

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

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 regards to current trends, and if the day job is largely irrelevant they may need to find access to projects (often unpaid) that will serve to impress new employers.

I don't think that the value of experience has truly diminished, but I think what is now classified as 'experience' may have shifted a bit.

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 experienced people would do fine.

I think my words may have been clumsy. My reference to "tech outside their job" was meant more about having relevant skills to a current job market (marketability), not the interview itself.

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

> No one in their daily jobs implements a linked list or B-Tree.

Counter case: HFT. Those guys really do implement this stuff. Again and again.

Which is why it's an outlier.

this, so this.

Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done.

I find the processes in a large company rather robotic (note: we're a startup, so my views might be biased).

>Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done.

A person who can only use a pre-made wheel is a technician (regardless of how ostentatious their job title may be).

A person who can invent the wheel on demand can also usually invent any other type of rolling mechanism one might encounter a need for and that makes that person a full-fledged engineer.

No value judgement of either person is implied; it's simply a statement of capability. Which type of person is needed depends on the company and the position but it is becoming increasingly clear that the two roles in software are separate, just as they are in other engineering disciplines.

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 since been paged out in favor of the actual day-to-day knowledge they need to do their job. Implementing basic data structures and algorithms is not part of what they need to do their job; that stuff's already provided by the platforms they use.

So when you get to the interview, if you just put someone on the spot and ask them to do one of these things, you're inherently biasing toward an inexperienced recent college graduate who will have this stuff close to the top of their head (on account of having just done it in school and not yet swapped it out of working memory through time on the job).

Which is in turn why there are now books you study -- as an already-qualified programmer -- in order to freshen your memory and ability to quickly regurgitate problems that have nothing whatsoever to do with your day-to-day work, in order to be able to perform them on command in interviews.

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.

Those are bad examples, but real interview questions tend to be "implement from scratch, live and without reference to any materials, these things you've forgotten about because you could take them for granted for such a long time".

Also these days the trendy interview problem is longest common subsequence, which ends up testing "how recently did you review dynamic-programming techniques", not "can you code".

> 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

I'll be honest, this is indistinguishable from "I am good at X and I'm great therefore X is a good measure of ability".

Maybe worth rephrasing

Traversing is a linked list is far simpler than implementing a B-tree.

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.

You refer to the interviewers as 'peers' but that's very much not the relationship that exists in an interviewer. The context is different, therefore the behaviour is different.

What you're describing is a confidence bias filter, dressed as an objective test.

Individually, with minor refreshing-study, perhaps no.

But in practice it's merely one of hundreds of things that might get instantly sprung on you as you stand before a whiteboard. In addition, developers with actual jobs can't stay in a continuous cycle of "exam cram" to the same extent that unemployed recent graduates can.

Right, as a metaphor, I'd almost compare it to grading a novelist or writer's grammatical knowledge of parts of speech and sentence structure rather than their ability to write a book or compelling article.

The problem is its possible to run a B-tree implementation and see if the unit tests pass or non-technical interviewers can compare the official solution to what the candidate is talking about fairly easily.

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.

Actually BSing in tech makes you look very poor if you don't come out with a convincing answer.

(I listened to a training video given by a Marketing Cloud consultancy at my work. Someone asked "what is FTP" after seeing that as an option to upload files. Lots waffle including "the cloud" and no actual answer. The person asking the question was no wiser, and my opinion of the consultant went way down).

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.

One thing that annoys me at present is NoSQL experience (or similar).

I know enough about relational databases and NoSQL to know that unless you have a specific use case, relational is likely a better choice. If you are not scaling beyond one server, and want to view your data from different angles its almost certainly a better choice. As such I haven't really got a great deal of NoSQL experience. I will build a better application than someone who does resume driven development, but won't get past many HR drones.

Interestingly, one of my 'no' signals is people relying on a DB to do the work for them. Don't know how to index this? Shove it in the DB and query it back.

If you don't have a relational query in mind a relational DB is a bad fit, or at least premature optimization.

I am not quite sure what you mean with your comment, as "relying on a DB to do the work for them" sound like a good thing to me. Its usually way faster than doing stuff in the application code, and the declarative nature of SQL usually means less bugs.

> I am not quite sure what you mean with your comment, as "relying on a DB to do the work for them"

Maybe "to do the thinking for them" would be more accurate.

> sound like a good thing to me.

You did what they do - you assumed based on some your usual workloads that a DB and the overhead of using another language, and a non-compile-time checked language, with poor integration (type mismatch), is the solution for the problem I'm working on.

What I expect them to do is ask questions. How many values are there? Are they complex types or something that would map to tables well? What are the querying requirements? Are there any relational elements to the data?

> Its usually way faster than doing stuff in the application code

If shoving things across two sets of pipes, to a general-purpose app not tuned to your workload, is faster - you're writing your main app incorrectly.

> the declarative nature of SQL usually means less bugs.

A declarative language usually means less bugs. But adding a second mismatched language usually means more. Especially when it comes with a whole new system that takes experts to properly tweak.

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 right back up if given the time and the motivation.

Of course, nobody has ever done any experimentation to prove such a hypothesis so that it could be used as a lemma.

I often wish there was some sort of prediction market of I/O-psychology hypotheses that you could just throw a random prediction onto. The stakes on the most contentious results would then prompt the investors to leverage their bets with research organizations into grant-funding to study those questions.

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?"

I start a lot of things like that (currently trying to learn Rust). A lot of the time other things take over in my spare time and I never actually get anywhere. Having a job where you can put consistent practice into new technologies makes a big difference. I week at work is probably equal to more than a month of my spare time.

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.

> I don't think curiosity diminishes with age, even if the ability to explore that curiosity may.

Anecdotally I'd assume that intellectual curiosity often increases with age, although that might be attributed to the availability of learning materials now compared to years ago. Some people here on HN would likely be shocked as to how many people in the industry consume almost zero content outside of what is necessary for their jobs.

> Some people here on HN would likely be shocked as to how many people in the industry consume almost zero content outside of what is necessary for their jobs.

Seriously. People significantly underestimate how much better the average HN user is than the average developer.

The median software developer sees programming as just a job and spends absolutely no time on developing their experience outside of work.

> I don't think curiosity diminishes with age, even if the ability to explore that curiosity may

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.

Outside of research and for fields outside of compsci, how else can applicants demonstrate "intellectual curiosity", and can you just expand a bit on what that means?

Thank you, and thanks Aline!

To me, intellectual curiosity is basically "learning for the sake of learning". In other words, picking up a skill or researching a topic that interests you without having a real need to apply said skil/knowledge professionally or personally.

Often the research may be tangentially related to their work, but it doesn't have to be in order to be 'credited' as intellectual curiosity.

Outside of CS, demonstrating curiosity can be almost anything. A non-CS person learning a technical topic is actually a decent example. Non-programmers that buy Arduino and do some home automation project.

It can be almost anything I'd think. Many people don't dedicate much personal time to learning. Demonstrating that learning can be challenging.

I have clients that require interviewees to do a presentation on anything at all during the hiring process (both non-tech and tech employees). Some have demonstrated game strategies they've studied.

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

What you do at your job during the day is usually imposed on the employee. Few employees get to choose the languages, tools, etc. that their company uses, so their interests aren't always relevant to their day jobs.

Your reading list on the other hand is entirely up to you. It's likely an indicator of something to the person asking the question. People who don't like math (or aren't skilled in math) aren't reading advanced math textbooks for pleasure.

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

Reply on news.ycombinator.com