Comment by throwaway2037
3 years ago
You wrote: <<People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.>>
I am constantly interviewing candidates for roles at my company. It seems like CVs are a complete gamble. Either some are lies, or wildy understated, and everything in between -- at all levels of experience! "[J]ust to prove..." and yet so many can not do the 2022 version of FizzBuzz. I am stunned how many senior (well, so they say!) hands-on technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works. For get about explaining the finer points of sorting algorithms (honestly, very low value in my line of work).
There is no reasonable alternative to testing of some kind for hands-on techincal roles -- I am flexible about method: (1) white board coding (ugh in 2022), (2) IDE/text editor on shared PC / video chat (meh / eh in 2022), or (3) take home (the best in 2022, even if there are drawbacks for people with families).
Joel Spolsky said it best about hiring: The goal is to avoid bad hires. Average and above are fine.
...explain to me how a hash map works. For get about explaining the finer points of sorting algorithms
I've been in software development for 15 years and being able to explain either of these things has never come up and I probably wouldn't be able to give a decent answer without reviewing the topics specifically.
Yes, companies are hiring for competency not tenure or years of life lived while holding job. If you want the latter, I have heard it is more structured that way in Japan and much of Europe.
I would expect most people I hire to be able to explain how a hash map works.
Depends on what exactly your company is doing? Why do you care if an applicant understand how a hash map works; and what's particular about a hash map?
I'd care more about an applicant understanding the concept of a hash; or hashing in general. If an applicant shows that he understands that a hash is a magical and fascinating mathematical concept; and it can have uses in Information/Computers, that would be more interesting (to me) than someone who memorized a hash map definition.
He can always learn about a particular application of hashing (hash map, for example). But the latter shows aptitude and capacity to learn these later on the job.
12 replies →
Yes, companies are hiring for competency not tenure or years of life lived while holding job.
Oh I wasn't trying to say that this knowledge was valuable or not. I was just pointing out that you seem surprised that experienced people wouldn't be able to provide a good answer to that question. And the answer is that in many jobs, its not useful knowledge.
I concede it may just be that I've been lucky, but when interviewing experienced candidates I've never really had any problem judging their competency just from discussing their past work. A little bit of back-and-forth deep dive into the technology has always exposed people who are shallower than their CV would have you believe.
What has burned me, however, cannot be tested adequately in an interview. Bad attitude and laziness. Anyone can behave well in interviews, so we've hired a few people who turned out to have a passive aggressive streak or condescending attitude that interferes with the rest of the team. We've also hired people who are really great developers ... when they work. But they're really lazy and getting them interested enough to do the work is the hard part.
Hiring is hard. I doubt I need to tell you that. There is a reason we gravitate towards hiring people we've worked with in the past, or come recommended by someone we trust.
I've had the same experience. Everyone wants you to "just look at their resume". Meanwhile, I've interviewed plenty of people with great resumes who can't solve a simple problem like reversing a string [1].
If you can point me to extensive open-source experience on projects that roughly approximate professional coding, then fine, I'd be happy to walk through your code with you instead of doing an algorithmic problem. The issue is that that's a minority of developers... most people don't have the time or desire to do extensive open-source work outside of work hours and I don't blame them for it [2]! But given that resumes are unreliable, I need to test you somehow.
[1] No, I don't ever have to reverse strings at work. But I do have to write efficient code. And if you can't conceptualize how to reverse a string then you probably won't stand a chance at more difficult algorithmic issues I often come across.
[2] I don't recall who it was, but I once heard a very well-regarded chef say that he's tired after work and so he doesn't like to cook much at home. I have zero problem with a developer doing the same with coding! Go home and work on a hobby, spend time with your family, or smoke pot and watch netflix... I care about what you are capable of at work, not what you do with your free time.
>technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works
In my experience people know these things, they just don't realize that what they're doing can be described generically.
An example: If you're in an iOS interview and ask the person to describe a graph, they will get very angry and complain that this is useless knowledge and they don't need it to get the job. But if you ask the same person to describe an UIView hierarchy, they often have no problem doing so. So they _know_ what a graph is, they just didn't know it had that name.
With that in mind, my tests shows that generic algorithm questions suck and questions themed around actual features of the product are the best. If you word the question in a way that feels relevant and is familiar to developers, they will be more likely to know the answer even if deep down the solution is exactly the same as the generic ones.