5 ms·

> Do you find these kind of tests useful? I’ve hired dozens of Sr. engineers and given coding tests to almost all of them (after a 2nd round interview, never e

by awb 5y ago

> Do you find these kind of tests useful? I’ve hired dozens of Sr. engineers and given coding tests to almost all of them (after a 2nd round interview, never earlier). However, my tests are time-boxes (1hr) and are about greenfielding an app (like a ToDo app) to see how they approach a problem rather than programming knowledge. > Why? About 33-50% of devs that pass the two interviews fail the coding test. Of the ones that fail, they’re great at interviewing but probably oversold their skills. Some are really poor at time management. Some are really poor at simplifying problems. And some are really poor at following directions. It’s possible that they were on teams that carried their weight or possible they were exaggerating their capabilities or prior responsibilities. The opposite has happened too where I’ve been blown away by the code quality and approach. But overall it’s been a very helpful datapoint in hiring.

71a54xd 5y ago
This is a hypothetical, but how would you suggest engineers that have issues with simplifying problems, managing time or maybe don't realize they're overselling their skills work in a positive direction to correct some of these things? I've noticed many companies will give technical feedback if you don't pass a round, but seems like there has to be some kind of path to help people like this. Always been curious to me that "ideal" practices for managing time, communicating technically / in a business context never seem to really be written down. I learned some of this (albeit badly) at a few internships, but if there'd been some source to read even if it was only the first 25% that would've been immensely helpful out of college.
- awb 5y ago
  > simplifying problems Practice rewriting personal projects. Once you have a working app, try to make it even simpler, clearer, more efficient, etc. > managing time If you’re on a tight deadline do the easy stuff first and if you’re falling behind get help with the harder parts or ask the team to scale back the scope. But if you bite off more than you can chew you run the risk of having nothing to show for it. If you’re building a proof of concept, then start with the hard parts to show the team that it’s possible and worth additional time to finish it off. > overselling their skills Be honest about your role in a project. Don’t hide the fact that another dev was doing the primary research or making the technical decisions. Just take credit for the things you did from start to finish, without help (because those people that helped might not be there at your next job).
arethuza 5y ago
Do you do the coding test as a take home exercise or something done in your office?
- awb 5y ago
  Take home, paid, self-regulated. Asked that they only spend 1 continuous hour (verified by initial and final GitHub commits).
  - isbvhodnvemrwvn 5y ago
    Commits are not verifiable, any half-competent git user can google how to change committer and author dates. I used to work for a company which did these "self-governed" tests and most candidates who bothered with these spent more time than they actually were supposed to to get an edge.
    - awb 5y ago
      Fair enough, but we ask the dev to send us an invite to the repo when they first create it, so then we ask them to Email us an hour later and we check the repo.
Clubber 5y ago
>About 33-50% of devs that pass the two interviews fail the coding test. I don't mean to sound insulting, but if your organization can't tell if someone knows what they are talking about after an interview, much less two interviews, what the heck is going on?
- kragen 5y ago
  All you have to do to be indistinguishable from someone who knows what they are talking about in two interviews is to say the things that someone who knows what they are talking about would say, in the way that they would say them. This is obviously a nontrivial skill, since it involves memorizing a lot of declarative knowledge, but for extraverted people with good memories it can come more easily than actual coding, let alone debugging. An interviewee who biffs it slightly can be very hard to distinguish from an interviewee who knows so much more than the interviewer that they identify errors in the interviewer's knowledge. And at this point there's a cottage industry of books and YouTube videos specifically designed to help people fake this stuff. Basically what it comes down to is that doing something and explaining it are different skills. True of riding a bicycle, true of fixing a car, true of programming. Karl Popper never discovered shit, Harold Bloom never wrote anything worth reading, and plenty of bestselling novelists are utterly terrible as creative writing instructors.
  - Clubber 5y ago
    >All you have to do to be indistinguishable from someone who knows what they are talking about in two interviews is to say the things that someone who knows what they are talking about would say, in the way that they would say them. Sounds like a supervillain or something. Maybe you're asking the wrong questions or maybe I have a knack for it, but the only thing I can't detect is motivation, which is probably more important than current ability. One of my worst hires was a guy who could answer all the trivia; sharp as a tack, but didn't have the discipline to do the work. He was always slacking and I couldn't count on him to get things done, even with loose deadlines. I mean most hiring managers don't bother calling references either. That yields a lot of insight; those references were hand picked by the candidate. Maybe call their last employer, even if it wasn't listed as a reference. One of my first questions is, "Tell me about your favorite project and why." If they answer in a sentence or two, even when prodded or show little or no enthusiasm, it's a pass. You have to like the work to be good at it. Ask some follow up questions to their answer. A phony can only go so deep. Second question is, "Tell me about your least favorite project and why."
phendrenad2 5y ago
What you're measuring as "bad time management" is likely to some degree people being frustrated and dismayed and giving up because an arbitrary timed test isn't fun or interesting or rewarding, when there are companies probably paying just as much as you with an easier interview process. So yeah, anecdata can be tricky.
- awb 5y ago
  What I mean is if we ask them to spend no more than 1hr on a ToDo app, I’ve seen people spend 1hr on the folder structure, importing a ton of packages, abstracting logic, etc. and don’t build the basic CRUD functions. So you basically end up with a giant empty shell of a project.

by awb 5y ago

71a54xd 5y ago

This is a hypothetical, but how would you suggest engineers that have issues with simplifying problems, managing time or maybe don't realize they're overselling their skills work in a positive direction to correct some of these things? I've noticed many companies will give technical feedback if you don't pass a round, but seems like there has to be some kind of path to help people like this. Always been curious to me that "ideal" practices for managing time, communicating technically / in a business context never seem to really be written down. I learned some of this (albeit badly) at a few internships, but if there'd been some source to read even if it was only the first 25% that would've been immensely helpful out of college.

awb 5y ago
> simplifying problems Practice rewriting personal projects. Once you have a working app, try to make it even simpler, clearer, more efficient, etc. > managing time If you’re on a tight deadline do the easy stuff first and if you’re falling behind get help with the harder parts or ask the team to scale back the scope. But if you bite off more than you can chew you run the risk of having nothing to show for it. If you’re building a proof of concept, then start with the hard parts to show the team that it’s possible and worth additional time to finish it off. > overselling their skills Be honest about your role in a project. Don’t hide the fact that another dev was doing the primary research or making the technical decisions. Just take credit for the things you did from start to finish, without help (because those people that helped might not be there at your next job).

arethuza 5y ago

Do you do the coding test as a take home exercise or something done in your office?

awb 5y ago
Take home, paid, self-regulated. Asked that they only spend 1 continuous hour (verified by initial and final GitHub commits).
- isbvhodnvemrwvn 5y ago
  Commits are not verifiable, any half-competent git user can google how to change committer and author dates. I used to work for a company which did these "self-governed" tests and most candidates who bothered with these spent more time than they actually were supposed to to get an edge.
  - awb 5y ago
    Fair enough, but we ask the dev to send us an invite to the repo when they first create it, so then we ask them to Email us an hour later and we check the repo.

Clubber 5y ago

>About 33-50% of devs that pass the two interviews fail the coding test. I don't mean to sound insulting, but if your organization can't tell if someone knows what they are talking about after an interview, much less two interviews, what the heck is going on?

kragen 5y ago
All you have to do to be indistinguishable from someone who knows what they are talking about in two interviews is to say the things that someone who knows what they are talking about would say, in the way that they would say them. This is obviously a nontrivial skill, since it involves memorizing a lot of declarative knowledge, but for extraverted people with good memories it can come more easily than actual coding, let alone debugging. An interviewee who biffs it slightly can be very hard to distinguish from an interviewee who knows so much more than the interviewer that they identify errors in the interviewer's knowledge. And at this point there's a cottage industry of books and YouTube videos specifically designed to help people fake this stuff. Basically what it comes down to is that doing something and explaining it are different skills. True of riding a bicycle, true of fixing a car, true of programming. Karl Popper never discovered shit, Harold Bloom never wrote anything worth reading, and plenty of bestselling novelists are utterly terrible as creative writing instructors.
- Clubber 5y ago
  >All you have to do to be indistinguishable from someone who knows what they are talking about in two interviews is to say the things that someone who knows what they are talking about would say, in the way that they would say them. Sounds like a supervillain or something. Maybe you're asking the wrong questions or maybe I have a knack for it, but the only thing I can't detect is motivation, which is probably more important than current ability. One of my worst hires was a guy who could answer all the trivia; sharp as a tack, but didn't have the discipline to do the work. He was always slacking and I couldn't count on him to get things done, even with loose deadlines. I mean most hiring managers don't bother calling references either. That yields a lot of insight; those references were hand picked by the candidate. Maybe call their last employer, even if it wasn't listed as a reference. One of my first questions is, "Tell me about your favorite project and why." If they answer in a sentence or two, even when prodded or show little or no enthusiasm, it's a pass. You have to like the work to be good at it. Ask some follow up questions to their answer. A phony can only go so deep. Second question is, "Tell me about your least favorite project and why."

phendrenad2 5y ago

What you're measuring as "bad time management" is likely to some degree people being frustrated and dismayed and giving up because an arbitrary timed test isn't fun or interesting or rewarding, when there are companies probably paying just as much as you with an easier interview process. So yeah, anecdata can be tricky.

awb 5y ago
What I mean is if we ask them to spend no more than 1hr on a ToDo app, I’ve seen people spend 1hr on the folder structure, importing a ton of packages, abstracting logic, etc. and don’t build the basic CRUD functions. So you basically end up with a giant empty shell of a project.