3 ms·

> I've found simply talking to prospective employees (be it software or anything else) about how they work, challenges they've encountered and how they overcame

by ekidd 9y ago

> I've found simply talking to prospective employees (be it software or anything else) about how they work, challenges they've encountered and how they overcame them and figuring out their attitudes has never failed me in hiring. At previous jobs, I've run into candidates who interview well but code poorly. They look good at first: 1. Their resume looks reasonable. 2. They sound qualified on a phone screen. 3. They can talk about previous projects. 4. They seem like great people to work with. ...but when put to the test, they can't code. I'm talking really simple stuff, like "You have 40 minutes to write (something no harder than FizzBuzz)." They can use their own laptop, with the language of their choice, and StackOverflow. Or for a job involving Scheme, we asked them reverse a singly-linked list. These were almost insultingly easy tests, given the posted job requirements. But I saw otherwise promising candidates struggle for the better part of an hour. But asking people to code can also help them get hired. I remember one interviewee who was doing poorly until we asked him to code, and then he solved the coding problems in literally about 20 seconds. We hired him, and he turned out to be a incredibly strong team member for many years. I think one fair way to handle these things might be to offer interviewees a choice: 1. We can ask you to write code during the interview, or 2. You can submit a link to a small open source project for us to look at. That gives both people who can't code under pressure and people who don't write code outside their day job an option. And it provides the interviewer with a work sample to discuss in the interview.

FLUX-YOU 9y ago
>I remember one interviewee who was doing poorly until we asked him to code, and then he solved the coding problems in literally about 20 seconds It's entirely possible that person just happened to have seen the problem before. Many interviewers would throw additional problems at them if they solved it that quickly because they would assume this. Especially true if you pulled the problem directly from a problem site where it has a high chance of someone seeing it before. You can get decently far as a programmer in mediocre jobs just knowing how to write a CRUD app. You'd never use modulo or reverse a linked list in these positions, yet they pay $60k+ and otherwise deliver products. The org doesn't care that code is delivered at a bureaucratically slow pace or incredibly simple because it's dysfunctional in the first place, so delivering a feature in 3 days which would take a good programmer 2 hours doesn't matter. Lots of "the user is wrong" pushback when something in the code fails too. Unfortunately, because of the way we're made to write resumes, these positions can be made to appear like any other normal position. I think it's more interesting that he seemed to do poorly until you gave him code. This may also sound insulting but I certainly don't mean it to be: maybe your code base isn't that challenging, which is why he is now a strong candidate. Are they doing maintenance, or contributing a lot of new code which requires architectural decisions that weren't previously found in your code (and could be copied)?
- ekidd 9y ago
  > You'd never use modulo or reverse a linked list in these positions The position I'm thinking of was a senior developer position that involved writing large amounts of Scheme code to interface with a video game engine. Typical Scheme code uses recursion where normal languages would use loops, and singly-linked lists are the most basic Scheme data structure, used for everything. So if you can't reverse a linked link in some language, you're probably not especially qualified for a job as a senior Scheme programmer. Not everything is a CRUD app. (And it's basically the first homework question you get in a first-year Data Structures class, so it's not too much to ask for a senior dev doing low-level work.) > I think it's more interesting that he seemed to do poorly until you gave him code. I've found that some amazing developers have weak people skills. They don't necessarily know how to write a resume, and they don't know how to "sell" themselves in interviews. But they may still be brilliant, dedicated coders, and excellent teammates.
  - fitpolar 9y ago
    >so it's not too much to ask for a senior dev doing low-level work. Actually for a senior dev, it is too much to expect low-level work they haven't used in 10 years. The analogy I quite often give is that you wouldn't assess a French teacher on their Latin class from 2005. The bottom line is that you probably asked a useless question that was great for teaching the CS foundations in school, but that hasn't ever been used once in their careers. People discard useless information, especially smart people because they prize the efficiency that their memory can use in place of useless information.

by ekidd 9y ago

FLUX-YOU 9y ago

>I remember one interviewee who was doing poorly until we asked him to code, and then he solved the coding problems in literally about 20 seconds It's entirely possible that person just happened to have seen the problem before. Many interviewers would throw additional problems at them if they solved it that quickly because they would assume this. Especially true if you pulled the problem directly from a problem site where it has a high chance of someone seeing it before. You can get decently far as a programmer in mediocre jobs just knowing how to write a CRUD app. You'd never use modulo or reverse a linked list in these positions, yet they pay $60k+ and otherwise deliver products. The org doesn't care that code is delivered at a bureaucratically slow pace or incredibly simple because it's dysfunctional in the first place, so delivering a feature in 3 days which would take a good programmer 2 hours doesn't matter. Lots of "the user is wrong" pushback when something in the code fails too. Unfortunately, because of the way we're made to write resumes, these positions can be made to appear like any other normal position. I think it's more interesting that he seemed to do poorly until you gave him code. This may also sound insulting but I certainly don't mean it to be: maybe your code base isn't that challenging, which is why he is now a strong candidate. Are they doing maintenance, or contributing a lot of new code which requires architectural decisions that weren't previously found in your code (and could be copied)?

ekidd 9y ago
> You'd never use modulo or reverse a linked list in these positions The position I'm thinking of was a senior developer position that involved writing large amounts of Scheme code to interface with a video game engine. Typical Scheme code uses recursion where normal languages would use loops, and singly-linked lists are the most basic Scheme data structure, used for everything. So if you can't reverse a linked link in some language, you're probably not especially qualified for a job as a senior Scheme programmer. Not everything is a CRUD app. (And it's basically the first homework question you get in a first-year Data Structures class, so it's not too much to ask for a senior dev doing low-level work.) > I think it's more interesting that he seemed to do poorly until you gave him code. I've found that some amazing developers have weak people skills. They don't necessarily know how to write a resume, and they don't know how to "sell" themselves in interviews. But they may still be brilliant, dedicated coders, and excellent teammates.
- fitpolar 9y ago
  >so it's not too much to ask for a senior dev doing low-level work. Actually for a senior dev, it is too much to expect low-level work they haven't used in 10 years. The analogy I quite often give is that you wouldn't assess a French teacher on their Latin class from 2005. The bottom line is that you probably asked a useless question that was great for teaching the CS foundations in school, but that hasn't ever been used once in their careers. People discard useless information, especially smart people because they prize the efficiency that their memory can use in place of useless information.