Live data from Hacker News

Things I Learned from a Job Hunt for a Senior Engineering Role

fuzzyblog.io

71–80 of 766 posts

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#71
post #6

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.

I understand that's a problem, but if I have an entire github of highly starred and heavily developed projects with reasonable commit histories... don't make me do your do damned homework or implement a toy BST. I have better things to do with my personal time than toy problems because you can't be bothered to open my github.

The worst part is that usually these toy problems are justified with "but you can post this to your Github for others to see!"

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#72
The process described in Point 1 is the most important takeaway. Probably HR departments have all adopted this process following some best-practice which surely arose in the last few years.

Maybe there is some blog post (from HR specialist) explaining it in detail?

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#73

Number 1: I think this is due to specializing in Ruby on Rails which is falling out of favor? Or your city location? I know in my location the average job hunt is 2 weeks. Number 2: As someone that interviews people alot, this is cuz MANY people who apply CANNOT code, no matter what their resume says. We have had people leave and never come back during our console app on site test (read in a text file and print out i…

> At the end of the interview, I would recommend asking "are there any concerns or issues you would have with hiring me for this position?" and LISTEN to their feedback. At the end of each interviewer. Asking the HR person at the end of it all is a waste of time for 2 reasons: 1. they won’t know yet 2. they won’t tell you but the tech interviewer almost certainly isn’t trained to keep his mouth shut and also generall…

My SO is a HR manager, many times as a screen for tech roles. It's interesting hearing it from the other side. She's a brick wall with regards to sensitive job information that lie past her scope of knowledge. She just won't release it.

She says the same thing as you however: if you want the good stuff, you have to attack the social vulnerabilities of tech people. They generally aren't trained to know what to say or not to say past the obvious. With carefully constructed questions, you can often get the information you're after.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#74
post #30

I've been involved in hiring senior engineers for a while now, and here's a few counterpoints: 1) Ruby is hard to get a job in, so you are off to a rough start. 2) A lot of people with lots of experience actually can't code for crap. Do you know how many python developers I see that don't know the difference between a tuple and list? Like, how could you be a real dev if you never even wondered why sometimes you use […

> 1) Ruby is hard to get a job in, so you are off to a rough start. Huh? Enterprise level companies are desperate for Ruby engineers to maintain large Rails apps and there still is a good amount of startups doing new work with it.

Startups that once would be be Ruby shops are moving to Elixir in droves

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#75

The "No One Believes Anyone Can Actually Code" point is right on the money by my anecdotal experience. Just a few weeks ago I was asked to implement FizzBuzz in an interview for the first time in my 15 years of engineering! This was despite having a large amount of verifiable open source Haskell projects.

I usually ask a trivial problem like this. Not really to see if they can code (I have had one or two people fail here though), but more to serve as a conversation topic. Why did you do this? How would you do that? etc...

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#76
post #6

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.

I feel like this is a myth, what do you estimate the figure is? I think under 10%, maybe under 5%. I have significant experience interviewing senior, junior, and mid-range candidates. 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. I've only had one junior candidate who couldn't code at all. Sloppiness is rampant, but sloppy code that gets things done is what…

It's not a myth. I see it when recruiting for my teams. My sample size is too small to give a proportion, but it's enough that not having tests would be a total waste of my and their time since I'd have to fire them on day 1.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#77
Side note/rant: I hate the Cracking the Coding Interview style... studying for these type of interviews is annoying. Trying to find a good video on youtube, where they aren't just naively coding up the bruteForce->optimal possible solutions, especially is irritating. It is literally a landscape of college kids with thousands of viewers who treat these interviews like the SAT. Even the author of the book produces videos with very little insight or meaningful content.

"Find all the subsets in a set that add up to sum" -- "Okay for this we will use the sliding window technique and here is how it is done" -- WTF is this. I get that they want to see problem-solving skills, but this is on a different level requiring the interviewee to have studied and knowledge of the technique, otherwise we are basically trying to develop efficient algorithms from scratch and in little time. --This makes sense for college interviewees who have only studied the past 4 years, but for a professional with experience why is this adequate??

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#78
post #6

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.

I feel like this is a myth, what do you estimate the figure is? I think under 10%, maybe under 5%. I have significant experience interviewing senior, junior, and mid-range candidates. 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. I've only had one junior candidate who couldn't code at all. Sloppiness is rampant, but sloppy code that gets things done is what…

> 99% of my candidates can code, as in iterate over collections, write case statements, and call functions.

Honestly, that's way too trivial to call "can code". I usually ask something less trivial, yet still extremely easy like "a function to check if a string is a palindrome" (I explain what a palindrome is) or "check if a substring exists in a given string".

You wouldn't believe how many people "with 10 years experience" just lose all motor function in their hands and mouth, even without any time pressure.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#79
post #6

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.

The idea that no one can code is often a result of poor interview practices, i.e. coding trivia contests under the gun.

Then misconstruing poor performance as coding ability.

Re: Things I Learned from a Job Hunt for a Senior Engineering Role

#80
Maybe the difference in people's experience with candidates who can't code is that some types of programming are full of BSers and others aren't. In nearly 30 years I've never encountered a candidate who flat-out couldn't code. If you see a lot of that in your specialty, maybe you should ask yourself what it is about that specialty that leads to a different experience.
Post reply on HN