151–160 of 766 posts
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?
> No one believes that anyone can actually code. Is it just our industry where you have to prove you aren't a complete impostor every time? Basically we treat every applicant like they are Frank Abagnale [0]. A senior role should be focused on more overall system and performance aspects of the software, using good practices. What does writing out a solution for fizzbuzz (or equivalent) prove during an interview? If t…
For a senior role:
1. Someone who can't write and debug a for-loop and an if-statement isn't going to be able to provide training and support to junior level hires. At all.
2. Making high-level changes and performance improvement both require good process discipline, and the ability to write a lot of code to actually accomplish it.
I think there are high value software management tactics that can be implemented without knowing how to code, for example, change control, or enforcing limits on work in progress via. kanban, but for a role that has either "software" or "developer" I think fizzbuzz is a very low bar.
I personally like binary search as in interview question. The basic principle is simple, but there are enough edge cases and variations to make it interesting.
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.
Seriously. I've sat on the hiring side. I've seen impressive resumes. I've had reasonable discussions with people. And then I give them a very, very trivial coding exercise (a take home, they're free to Google, do it on their own computer, in their own IDE, in their professed preferred language), in a time frame that while constrained is still plenty...and the result is -terrible-. I can try and come up with reasons…
And if you throw in distributed databases, there is yet another understanding of "consistency" (vis-a-vis the CAP theorem), which really means "linearizability".
Sorry, didn't mean to be super-pedantic but consistency as a concept may seem simple to the uninitiated but is easy to get tripped up on, especially for folks who are aware there is a deeper layer of understanding associated with the concept, but can't articulate it right off the bat.
All this is to say filtering people truly is a hard thing. The extremes are easy to tell apart, but people who hover around the average are much less differentiated.
[1] https://en.wikipedia.org/wiki/Consistency_(database_systems)...
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…
I've run into this issue in different specific ways earlier in my career and no matter what I'd say about skill level / lack of knowing required technologies / being willing to take lower pay in order to justify aiming for another role it didn't matter in the face of the possibility that the recruiter could obtain a larger % for themselves off of that senior / higher-than-in-my-range job's salary.
Maybe this isn't as applicable for senior dev role applicants as it is for some lower level dev roles but at the point an applicant is actually physically there in front of the interviewers I'm sure one of the last things they are going to want to admit is that they wished they were interviewing for a lower paying / easier job even if it's 110% in the favor of both parties.
Earlier quoted context omitted.
> 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.
I'm a "Ruby engineer" but tend to avoid Rails teams because most of those large Rails apps are a giant pile of technical debt. They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed. No thanks. Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical r…
Very well said and it happens in lots of areas where companies seem to wish for "big outcomes but all for free".
You will see this in security all the time.
"We have to make sure this thing is bullet proof."
"Ok it's going to take a month to harden and audit our the network and infrastructure and add monitoring and we'll be in good shape."
"Uhh ... no we didn't quite mean it like that ... can't you like install a plugin in half an hour that does the same thing?"
(made up conversation but you get the point)
It's official. We now definitely have a vast oversupply of engineering talent available in the marketplace. This post is a great report and a must read of all engineers.
Earlier quoted context omitted.
> 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.
I'm a "Ruby engineer" but tend to avoid Rails teams because most of those large Rails apps are a giant pile of technical debt. They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed. No thanks. Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical r…
Well yeah, churn and burn is my company's motto. At least we pay well.
Earlier quoted context omitted.
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 expe…
const isPalindrome(str) { return str === str.split('').reverse().join(''); }
And the post interview notes said bad performance on the isPalindrome() question since I didn't write out my own functions (interviewer did not mention to).
Earlier quoted context omitted.
> it's there because we have no industry wide, respected entrance exam So you think the person with 30 years experience might be, whats the word... oh right. Lying. You think they are lying. Quit trying to dress it up. Coding tests are exactly you saying you don't believe the experience written on the resume.
I use a coding test not only to see if someone can write basic code, but also to assess general intelligence and see/hear their problem solving process. A resume definitely doesn't tell you all you need to know and experience does not necessarily mean effectiveness.
The problem is that it's kind of awful, and I personally really do believe that it's driving people away from the field.
Here's my take (I've posted this on HN a few times). Many people find in person, at the whiteboard exams quite stressful. This is fairly common, many people describe exams to be among the more stressful events in their lives.
Over time, I believe that institutions that conduct exams evolved a bill or rights between institution and applicant. Exams are used, but they are administered consistently and fairly, the topic and subject matter will not be a huge surprise (questions are kept secret of course, but their nature should be predictable). People who pass or fail will receive an answer, and often get a score and feedback to know how they did. The people who grade the exams are provided training to ensure they evaluate people fairly, consistently, and without bias, and are expert in their field.
Now, I know that universities, medical boards, bar exam reviewers, don't always live up to this, but it is the intended goal. I believe that our field, software, subjects people to exams repeatedly, but without any of the bill or rights I descried above.
For example, how do you grade? Are you qualified to assess general intelligence? Can you understand that someone might not be eager to submit to your general assessment of their intelligence?
Now, if you want to say nobody is entitled to a job, I certainly agree. But the industry seems to think it's entitled to workers, and they just seem utterly blind to how off putting their practices are. And in an industry with concerns about gender, racial, and age discrimination, double secret assessments of people's general intelligence by interviewers of unknown qualifications is about the worst thing you can do.