5 ms·

That's a terrible attitude. If you can't be bothered to complete a coding exercise just so I can verify your skills what happens when you have to do something o

by ng12 10y ago

That's a terrible attitude. If you can't be bothered to complete a coding exercise just so I can verify your skills what happens when you have to do something on the job you consider beneath you?

cerrelio 10y ago
Yup. Not worth my time.
toomuchtodo 10y ago
Not a terrible attitude at all. Its unacceptable for a corporation to maximize its efficiency while frowning on a potential candidate doing the same. Level the playing field. It's a seller's market (tech workers are still very much in demand).
mhluongo 10y ago
The problem is you're trying to verify the wrong skills.
eropple 10y ago
It's always so very strange that, as a consultant, I am never asked to perform the kinds of jump-through-hoops stuff that hiring candidates are, despite often having more access to their systems than those candidates will if hired. Maybe it's because the whole thing is nonsensical power plays on the part of hiring managers when candidates don't realize that it's a seller's market and they don't have to play the game.
- bumbledraven 10y ago
  > It's always so very strange that, as a consultant, I am never asked to perform the kinds of jump-through-hoops stuff that hiring candidates are, That's not strange at all. It's much easier to "fire" a consultant than an employee.
  - eropple 10y ago
    At-will employment, dude. Termination at most companies below the size where bureaucracy sprouts (where most of my business comes from) is a pretty trivial "you're out." Rather, it's a recognition that we are business partners and the relationship must be collaborative and in good faith, with a much different dynamic than employer/employee.
    - chucksmash 10y ago
      Legally it is pretty trivial. Respectfully though, just looking at it from that angle misses a lot. - The person you've hired has made friends. You might like them personally. Firing them will have repercussions for your team's morale. - Onboarding is a good bit more hassle than interviewing. Just like how it's cheaper to find bugs in dev rather than in prod, filtering during phone interviews is cheaper than in on-site interviews is cheaper than post hiring. - Constantly hiring people, discovering they are incompetent and then firing them has implications for your own ability to lead and develop a team. So maybe now I look like the type of team lead who codes fine, but just isn't cut out to deal with the people side of things. - In a small team environment, every team member has to be able to move the needle for the project individually. If I only have 3 engineers and 1 is bad, can I afford to pair half of my good engineers with the one who is struggling? I'd much prefer to work at a company with a strong filter out front that then invests in the people it hires. Much better to say "Gee, Joe is mostly a wonderful employee but not great with skillX, let's see if we can pair with a Sr to work on that during the next project cycle" than have constant churn.
      - JoeAltmaier 10y ago
        Certainly its cheaper to find problems early. But its also possible to retrain; to create policies that enable progress regardless of the individual skills; to shift duties to match strengths etc. Its not always possible to hire stellar teams (by definition half of all teams are below average). Still work can get done. Look at Pair Programming, look at Agile. Efforts to create a process where predictable work gets done regardless.
      - 10y ago
Buttons840 10y ago
I'm willing to spend about as much time doing coding exercises as the company has spent on me. This attitude developed after a couple companies asked me to do exercises, which I completed, and then they never responded to me. They didn't even acknowledge they had received my answer until I pestered them, at which time they confirmed they had received my solution, but had chosen to go with somebody else. If you want me to spend a few hours performing a coding exercise, I'd be happy to, as long as I first get a few hours of interview time to ask you questions about your company and determine if it's a place I'd like to work. You're, of course, welcome to ask me questions about myself during that interview time as well.
- GrinningFool 10y ago
  As someone who administers coding exercises to candidates where I work, I can only say that I respond promptly when a candidate says they've completed the exercise if only to let them know I received it. I also encourage them to ask any questions they have and respond promptly to them if they do. The exercise is valuable to us in our decision making process, which is why we request that candidates do it. It's disappointing to hear that basic professionalism isn't as common as it should be - but don't blame the exercise for that. Perhaps instead, breathe a sigh of relief that you won't have to work with people who do not value your time.
  - eropple 10y ago
    > don't blame the exercise for that Yes, blame the exercise for that, because the exercise is fundamentally and inescapably is an attempt to assert a level of power over candidates; instead of studying their Github or just talking to them hiring managers demand that they take on the time-and-effort risk of qualifying themselves to the hirer. Which is really stupid in a seller's market, BTW. But, even past that stupidity, it makes it tenable, in the mind of the evaluator, to blow off the candidate because they have, by accepting it, signaled that they will put up with at least a decent amount of shit coming down the pipe towards them without serious complaint. It's fundamentally dehumanizing hoop-jumping, which creates predictable results, and we should be better than that.
fernandotakai 10y ago
honestly? i think i have enough references to go past that. also, if you think i'm good enough, pay me a day of work and gimme some real world problems. i don't remember the last time i had to write bubble sort or a binary tree by hand. but i do remember when i had to deal with salesforce api errors and how to deal with them. or even, how to deal with rabbitmq retries compared to thrift methods.
tluyben2 10y ago
Thise two are not comparable: you are asking me, a senior with 25 years of coding and team building/lead experience to do a bunch of demeaning tasks for free that tell you nothing about my skills in a real life situation. While on the other hand you gave me a contract and I feel part of the company and the team which makes me want to perform whatever. Very different.
- ng12 10y ago
  It's a balancing act, right? After being a hiring manager for 5 years I've learned that what a candidate says about themselves means jack-all. You could be a genuinely great hire or some guy who spent 25 years banging their head against the wall going from one failed project to another and your elevator pitch will be roughly the same. Trust but verify. I'm sure some companies overdo it but if you're going to be touching code in any capacity I want to do the best I can to verify your abilities in a reasonable amount of time. A 1-hour coding exercise fits that criteria pretty well.
  - cerrelio 10y ago
    Hiring someone with that much (or even half that much) experience shouldn't include a coding exercise. If it does, the results should contribute ~5%-10% weight to the final decision. Seniors'/leads' skills diverge from engineering over time. You shouldn't even be coding as a lead. You direct the coding of juniors. When I interview those upper levels, I talk more about design and how they work with other departments (ops, product, UI) to get things done; how they overcome people and process problems. I know several leads who can write great code, but they can't lead a project to completion for the life of them. And if you discover that during the interview, you have to determine whether it was genuinely their lack of competence or because of poor management. Personally, I'd rather spend that hour allotted to coding digging more deeply into their non-coding skills.
    - NotSammyHagar 10y ago
      If the leaders of programmers can't code, then they can't evaluate them, and can't help them grow very well, and can't pass on the experience of developers over time. It's crucial for first level leads to be able to code.

by ng12 10y ago

That's a terrible attitude. If you can't be bothered to complete a coding exercise just so I can verify your skills what happens when you have to do something on the job you consider beneath you?

cerrelio 10y ago

Yup. Not worth my time.

toomuchtodo 10y ago

Not a terrible attitude at all. Its unacceptable for a corporation to maximize its efficiency while frowning on a potential candidate doing the same. Level the playing field. It's a seller's market (tech workers are still very much in demand).

mhluongo 10y ago

The problem is you're trying to verify the wrong skills.

eropple 10y ago

It's always so very strange that, as a consultant, I am never asked to perform the kinds of jump-through-hoops stuff that hiring candidates are, despite often having more access to their systems than those candidates will if hired. Maybe it's because the whole thing is nonsensical power plays on the part of hiring managers when candidates don't realize that it's a seller's market and they don't have to play the game.

bumbledraven 10y ago
> It's always so very strange that, as a consultant, I am never asked to perform the kinds of jump-through-hoops stuff that hiring candidates are, That's not strange at all. It's much easier to "fire" a consultant than an employee.
- eropple 10y ago
  At-will employment, dude. Termination at most companies below the size where bureaucracy sprouts (where most of my business comes from) is a pretty trivial "you're out." Rather, it's a recognition that we are business partners and the relationship must be collaborative and in good faith, with a much different dynamic than employer/employee.
  - chucksmash 10y ago
    Legally it is pretty trivial. Respectfully though, just looking at it from that angle misses a lot. - The person you've hired has made friends. You might like them personally. Firing them will have repercussions for your team's morale. - Onboarding is a good bit more hassle than interviewing. Just like how it's cheaper to find bugs in dev rather than in prod, filtering during phone interviews is cheaper than in on-site interviews is cheaper than post hiring. - Constantly hiring people, discovering they are incompetent and then firing them has implications for your own ability to lead and develop a team. So maybe now I look like the type of team lead who codes fine, but just isn't cut out to deal with the people side of things. - In a small team environment, every team member has to be able to move the needle for the project individually. If I only have 3 engineers and 1 is bad, can I afford to pair half of my good engineers with the one who is struggling? I'd much prefer to work at a company with a strong filter out front that then invests in the people it hires. Much better to say "Gee, Joe is mostly a wonderful employee but not great with skillX, let's see if we can pair with a Sr to work on that during the next project cycle" than have constant churn.
    - JoeAltmaier 10y ago
      Certainly its cheaper to find problems early. But its also possible to retrain; to create policies that enable progress regardless of the individual skills; to shift duties to match strengths etc. Its not always possible to hire stellar teams (by definition half of all teams are below average). Still work can get done. Look at Pair Programming, look at Agile. Efforts to create a process where predictable work gets done regardless.
    - 10y ago

Buttons840 10y ago

I'm willing to spend about as much time doing coding exercises as the company has spent on me. This attitude developed after a couple companies asked me to do exercises, which I completed, and then they never responded to me. They didn't even acknowledge they had received my answer until I pestered them, at which time they confirmed they had received my solution, but had chosen to go with somebody else. If you want me to spend a few hours performing a coding exercise, I'd be happy to, as long as I first get a few hours of interview time to ask you questions about your company and determine if it's a place I'd like to work. You're, of course, welcome to ask me questions about myself during that interview time as well.

GrinningFool 10y ago
As someone who administers coding exercises to candidates where I work, I can only say that I respond promptly when a candidate says they've completed the exercise if only to let them know I received it. I also encourage them to ask any questions they have and respond promptly to them if they do. The exercise is valuable to us in our decision making process, which is why we request that candidates do it. It's disappointing to hear that basic professionalism isn't as common as it should be - but don't blame the exercise for that. Perhaps instead, breathe a sigh of relief that you won't have to work with people who do not value your time.
- eropple 10y ago
  > don't blame the exercise for that Yes, blame the exercise for that, because the exercise is fundamentally and inescapably is an attempt to assert a level of power over candidates; instead of studying their Github or just talking to them hiring managers demand that they take on the time-and-effort risk of qualifying themselves to the hirer. Which is really stupid in a seller's market, BTW. But, even past that stupidity, it makes it tenable, in the mind of the evaluator, to blow off the candidate because they have, by accepting it, signaled that they will put up with at least a decent amount of shit coming down the pipe towards them without serious complaint. It's fundamentally dehumanizing hoop-jumping, which creates predictable results, and we should be better than that.

fernandotakai 10y ago

honestly? i think i have enough references to go past that. also, if you think i'm good enough, pay me a day of work and gimme some real world problems. i don't remember the last time i had to write bubble sort or a binary tree by hand. but i do remember when i had to deal with salesforce api errors and how to deal with them. or even, how to deal with rabbitmq retries compared to thrift methods.

tluyben2 10y ago

Thise two are not comparable: you are asking me, a senior with 25 years of coding and team building/lead experience to do a bunch of demeaning tasks for free that tell you nothing about my skills in a real life situation. While on the other hand you gave me a contract and I feel part of the company and the team which makes me want to perform whatever. Very different.

ng12 10y ago
It's a balancing act, right? After being a hiring manager for 5 years I've learned that what a candidate says about themselves means jack-all. You could be a genuinely great hire or some guy who spent 25 years banging their head against the wall going from one failed project to another and your elevator pitch will be roughly the same. Trust but verify. I'm sure some companies overdo it but if you're going to be touching code in any capacity I want to do the best I can to verify your abilities in a reasonable amount of time. A 1-hour coding exercise fits that criteria pretty well.
- cerrelio 10y ago
  Hiring someone with that much (or even half that much) experience shouldn't include a coding exercise. If it does, the results should contribute ~5%-10% weight to the final decision. Seniors'/leads' skills diverge from engineering over time. You shouldn't even be coding as a lead. You direct the coding of juniors. When I interview those upper levels, I talk more about design and how they work with other departments (ops, product, UI) to get things done; how they overcome people and process problems. I know several leads who can write great code, but they can't lead a project to completion for the life of them. And if you discover that during the interview, you have to determine whether it was genuinely their lack of competence or because of poor management. Personally, I'd rather spend that hour allotted to coding digging more deeply into their non-coding skills.
  - NotSammyHagar 10y ago
    If the leaders of programmers can't code, then they can't evaluate them, and can't help them grow very well, and can't pass on the experience of developers over time. It's crucial for first level leads to be able to code.