7 ms·

I have passed a bunch of job interviews in the past - but I feel the exact same away and hire this way these days. I really do not see the point of brainteasers

I have passed a bunch of job interviews in the past - but I feel the exact same away and hire this way these days. I really do not see the point of brainteasers or white board coding questions if you have a budget where you can just pay out a contract like this. Also, I believe there was an article posted here a few weeks back that indicated Google's brainteasers did not lead to quality candidates - I know I am cherry picking something that supports my beliefs but it was here nonetheless. Also, I have interviewed a lot of people with 4.0 BS/MS in 5 years that turned out to be horrible employees. They were awesome with the brain teaser questions but sucked when they actually had to build something. I guess I do not see how you can lose if you take the contract-to-hire approach ..

300bps 13y ago
I guess I do not see how you can lose if you take the contract-to-hire approach I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.
- tocomment 13y ago
  I don't think many candidates are interested in "immediate" hiring. Most people I know need to take extra time to wait for other offers to come in. It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc. I think it's a win-win.
  - TheCoelacanth 13y ago
    It doesn't have to be immediate, but most high quality workers will not be interested in anything that requires them to spend a period of time without a full-time job. So whatever contract work you give them will have to be small enough that they can do it while still working a full-time job, or you will miss out on most of the high quality people.
  - walshemj 13y ago
    Well I would want contractor rates >$550 perdiem for this short term contract and via my company so I can reap the tax benefit. Trouble is most employed people will have restrictions on outside work and if its related work the current employer will own that IP.
  - jaegerpicker 13y ago
    Nearly all of the high quality developers I know aren't interested in contract-to-hire, I know I'm not at all. To many things can go wrong in a short contract window, and regardless of the reality, most immediate hires feel they have a much stronger connection to the employer.
  - btilly 13y ago
    Many candidates with current jobs that they would like to leave are only interested in immediate hiring. They do not have the luxury to take several days off of their existing job for a tiny contract which might or might not land them a job that they might or might not prove to want. One size definitely does not fit all here.
  - jlarocco 13y ago
    I recently switch jobs and can say with certainty I had no interest in contracting or contract-to-hire positions. Quitting a full time job for a new position is a big commitment on my part, and I'd like a big commitment on the other side of the table. Not to mention contracting gigs don't usually have insurance, vacation, or other benefits. If it means a more rigorous interview that's okay with me.
  - tocomment 13y ago
    All of you guys are imagining some sort of 6 month junky contract to hire situation. All I'm talking about is a 3-10 day contract like the article mentions. An unemployed candidate can do a contract like that while evaluating other jobs and possibly waiting for other offers to come in. An employed candidate can do the work in off-hours.
- VladRussian2 13y ago
  >filtering out a portion of the highest quality candidates if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) - well, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.
  - chollida1 13y ago
    > if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) ell, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply. I'm not sure if this is a joke, but I'll bite. The entire problem with hiring is that no-one, I repeat, NO-ONE is capable of determining who are the best candidates. If they could then everyone would the same formula and this would be a solved issue. GOOG and MSFT have tonnes of hiring data and they admit they can't do this very well. It seems very presumptuous of you to assume you can and anyone who can't is somehow an outlier.
- ctb_mg 13y ago
  Agree with this. There's a definite stigma with contract-to-hire, at least in my group of tech friends. No one desires to be in a contract limbo where they aren't sure if they're going to be hired for real or or if they're doing the job search all over again in a few weeks. Further, as soon as you use contract work to determine hiring criteria -- you've added your management into the mix. Are expectations made clear? Is the person's time managed efficiently? If management fails at any point then it's detrimental to the prospective employee's future, likely not by their own fault.
  - misiti3780 13y ago
    disclaimer: i am 1/2 two members of the management team at my company - if it was larger - this could be a problem I agree
  - WalterSear 13y ago
    The contract doesn't/shouldn't be for a meaningful amount of work. It should be for the smallest amount of work that will allow you to evaluate the candidate. It doesn't even have to be for 'real' work - it could be a problem that has already been solved, or something that you think could be better but isn't a priority. The point is, there's no reason for it to be a genuine contract position, and every reason for it to be concise enough for them to fit in during their off hours. After all, you are going to have to look at it too :) And they do have the time for it: after all, they are making the time for interviewing.
- dangero 13y ago
  Good point. Maybe the best approach would be to let the interviewer choose the approach that works best for them. It would be sooo refreshing for a company to present me with interview options that will showcase my skills the best.
pnathan 13y ago
I've become a real believer in the "portfolio". I make the assumption that any person with a github (bitbucket/etc) site with a track record is someone worth looking at; if their portfolio demonstrates quality work and the resume looks all right, I'll recommend them. Yes, false negatives, people with horrible IP agreements get screwed, etc. False positives are much worse than false negatives in the common business wisdom.
- peeters 13y ago
  It seems to me like software engineering is one of the only fields with people arrogant enough to assume that every good and passionate programmer should also be doing programming as a hobby. I loved software engineering so much that I decided to turn it into a career, so that I could do it every day. But now you want me to do it every day and every night? No. My work during the day is fulfilling. My hobbies provide variety and an opportunity to pursue other interests.
  - 7Figures2Commas 13y ago
    It seems to me that software engineering is one of the only fields with people arrogant enough to assume that employers should hire folks without being able to see what they've actually accomplished. A "portfolio" does not have to, and should not, consist of side projects. Don't have any real code that you are allowed to share? Obviously, many employers won't hire engineers without reviewing existing code or having you engage in a coding exercise, but here's an idea: take a bunch of screenshots of public-facing applications/functionality you've built for your current and/or past employers. With WordPress and a $25 portfolio theme, you can have a decent-looking showcase of your work product up and running in a matter of hours. If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.
    - dmatlack 13y ago
      What? Not everyone works on front-facing, UI applications. What if I contributed a good amount of code to a large tech company's networking infrastructure. What do you want me to show you? A picture of the servers? A picture of Amazon's homepage or google.com, if those are the companies I'm working for? Not being able to show "code" or "screenshots" is not the fault of the prospective employee (as you "oh so subtly" implied with your last sentence).
moubarak 13y ago
i once needed a job so bad and was asked to solve a Rails challenge. i never did Rails before but i learned it and solved the challenge in a week. i also thoroughly documented my learning process and decisions. However i was rejected for being too fresh which i understood, i learned a lot during that week and even though i didn't get the job i feel that i achieved something. so i also don't see how you can lose with a contract-to-hire approach.
- rhizome 13y ago
  That's great that you got something out of it, but I have to wonder why it took them until after you completed the task to figure out that you were "too fresh."
  - moubarak 13y ago
    the best reason i remember was that it wasn't unanimous. my submission had to go through several people, and while the guys who i had direct contact with showed that they liked me, the decision came after their meeting with the CTO. They also knew before hand and gave me a chance perhaps i would do something very impressive. i'm not saying my submission was perfect, i might have done a couple of things wrong, or during that period they might have found someone better, there might have been several reasons i think, but i still learned a ton about Rails.
Swannie 13y ago
Right. Most "brain teaser" technical interviews are just an oral test. We all know that passing a test is hugely different from productive work. I don't understand why technical interviews are not more oriented to "how would you design X? Ok, what objects? What interfaces? How does that work, explain like I'm your 10yr old nephew? Ok, pseudo code that part. What are challenges with it? Have you coded similar things? Tell me about one. How would you do it different now? How would you convince me that it's worth refactoring? How about if I was your peer and I told you your idea was the worst thing I'd ever heard? Ok, now assume I'm working for you, and it's my second week, explain how to write your new design from scratch, and what some gotchas I should avoid are?" We all know that green field coding is a rarity, and most time is spent writing/running tests, refactoring, bug squashing, design writing, code reviewing, team managing (always at least upwards and sideways). Most of this is still "technical", but seems to be overlooked with endless stupid brain teasers. I know what Knuth volumes are, I know what google is, and I know my basic algorithms. Most people don't need to have memorised how to implement random algorithm x.
archangel_one 13y ago
> Google's brainteasers did not lead to quality candidates This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews. I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour. > I guess I do not see how you can lose if you take the contract-to-hire approach .. For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.
- RogerL 13y ago
  Well, the person that referred to the article used the wrong term. Certainly brainteasers don't work, and they have been prohibited at Google for awhile. But the recent article stated that there was no correlation between interviewers and job performance. That the beloved hash table, distributed computing, priority queue, red-black tree questions that you pepper people have nothing to do with the quality of the person you hire. Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on. Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?

300bps 13y ago

I guess I do not see how you can lose if you take the contract-to-hire approach I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.

tocomment 13y ago
I don't think many candidates are interested in "immediate" hiring. Most people I know need to take extra time to wait for other offers to come in. It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc. I think it's a win-win.
- TheCoelacanth 13y ago
  It doesn't have to be immediate, but most high quality workers will not be interested in anything that requires them to spend a period of time without a full-time job. So whatever contract work you give them will have to be small enough that they can do it while still working a full-time job, or you will miss out on most of the high quality people.
- walshemj 13y ago
  Well I would want contractor rates >$550 perdiem for this short term contract and via my company so I can reap the tax benefit. Trouble is most employed people will have restrictions on outside work and if its related work the current employer will own that IP.
- jaegerpicker 13y ago
  Nearly all of the high quality developers I know aren't interested in contract-to-hire, I know I'm not at all. To many things can go wrong in a short contract window, and regardless of the reality, most immediate hires feel they have a much stronger connection to the employer.
- btilly 13y ago
  Many candidates with current jobs that they would like to leave are only interested in immediate hiring. They do not have the luxury to take several days off of their existing job for a tiny contract which might or might not land them a job that they might or might not prove to want. One size definitely does not fit all here.
- jlarocco 13y ago
  I recently switch jobs and can say with certainty I had no interest in contracting or contract-to-hire positions. Quitting a full time job for a new position is a big commitment on my part, and I'd like a big commitment on the other side of the table. Not to mention contracting gigs don't usually have insurance, vacation, or other benefits. If it means a more rigorous interview that's okay with me.
- tocomment 13y ago
  All of you guys are imagining some sort of 6 month junky contract to hire situation. All I'm talking about is a 3-10 day contract like the article mentions. An unemployed candidate can do a contract like that while evaluating other jobs and possibly waiting for other offers to come in. An employed candidate can do the work in off-hours.
VladRussian2 13y ago
>filtering out a portion of the highest quality candidates if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) - well, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.
- chollida1 13y ago
  > if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) ell, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply. I'm not sure if this is a joke, but I'll bite. The entire problem with hiring is that no-one, I repeat, NO-ONE is capable of determining who are the best candidates. If they could then everyone would the same formula and this would be a solved issue. GOOG and MSFT have tonnes of hiring data and they admit they can't do this very well. It seems very presumptuous of you to assume you can and anyone who can't is somehow an outlier.
ctb_mg 13y ago
Agree with this. There's a definite stigma with contract-to-hire, at least in my group of tech friends. No one desires to be in a contract limbo where they aren't sure if they're going to be hired for real or or if they're doing the job search all over again in a few weeks. Further, as soon as you use contract work to determine hiring criteria -- you've added your management into the mix. Are expectations made clear? Is the person's time managed efficiently? If management fails at any point then it's detrimental to the prospective employee's future, likely not by their own fault.
- misiti3780 13y ago
  disclaimer: i am 1/2 two members of the management team at my company - if it was larger - this could be a problem I agree
- WalterSear 13y ago
  The contract doesn't/shouldn't be for a meaningful amount of work. It should be for the smallest amount of work that will allow you to evaluate the candidate. It doesn't even have to be for 'real' work - it could be a problem that has already been solved, or something that you think could be better but isn't a priority. The point is, there's no reason for it to be a genuine contract position, and every reason for it to be concise enough for them to fit in during their off hours. After all, you are going to have to look at it too :) And they do have the time for it: after all, they are making the time for interviewing.
dangero 13y ago
Good point. Maybe the best approach would be to let the interviewer choose the approach that works best for them. It would be sooo refreshing for a company to present me with interview options that will showcase my skills the best.

pnathan 13y ago

I've become a real believer in the "portfolio". I make the assumption that any person with a github (bitbucket/etc) site with a track record is someone worth looking at; if their portfolio demonstrates quality work and the resume looks all right, I'll recommend them. Yes, false negatives, people with horrible IP agreements get screwed, etc. False positives are much worse than false negatives in the common business wisdom.

peeters 13y ago
It seems to me like software engineering is one of the only fields with people arrogant enough to assume that every good and passionate programmer should also be doing programming as a hobby. I loved software engineering so much that I decided to turn it into a career, so that I could do it every day. But now you want me to do it every day and every night? No. My work during the day is fulfilling. My hobbies provide variety and an opportunity to pursue other interests.
- 7Figures2Commas 13y ago
  It seems to me that software engineering is one of the only fields with people arrogant enough to assume that employers should hire folks without being able to see what they've actually accomplished. A "portfolio" does not have to, and should not, consist of side projects. Don't have any real code that you are allowed to share? Obviously, many employers won't hire engineers without reviewing existing code or having you engage in a coding exercise, but here's an idea: take a bunch of screenshots of public-facing applications/functionality you've built for your current and/or past employers. With WordPress and a $25 portfolio theme, you can have a decent-looking showcase of your work product up and running in a matter of hours. If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.
  - dmatlack 13y ago
    What? Not everyone works on front-facing, UI applications. What if I contributed a good amount of code to a large tech company's networking infrastructure. What do you want me to show you? A picture of the servers? A picture of Amazon's homepage or google.com, if those are the companies I'm working for? Not being able to show "code" or "screenshots" is not the fault of the prospective employee (as you "oh so subtly" implied with your last sentence).

moubarak 13y ago

i once needed a job so bad and was asked to solve a Rails challenge. i never did Rails before but i learned it and solved the challenge in a week. i also thoroughly documented my learning process and decisions. However i was rejected for being too fresh which i understood, i learned a lot during that week and even though i didn't get the job i feel that i achieved something. so i also don't see how you can lose with a contract-to-hire approach.

rhizome 13y ago
That's great that you got something out of it, but I have to wonder why it took them until after you completed the task to figure out that you were "too fresh."
- moubarak 13y ago
  the best reason i remember was that it wasn't unanimous. my submission had to go through several people, and while the guys who i had direct contact with showed that they liked me, the decision came after their meeting with the CTO. They also knew before hand and gave me a chance perhaps i would do something very impressive. i'm not saying my submission was perfect, i might have done a couple of things wrong, or during that period they might have found someone better, there might have been several reasons i think, but i still learned a ton about Rails.

Swannie 13y ago

Right. Most "brain teaser" technical interviews are just an oral test. We all know that passing a test is hugely different from productive work. I don't understand why technical interviews are not more oriented to "how would you design X? Ok, what objects? What interfaces? How does that work, explain like I'm your 10yr old nephew? Ok, pseudo code that part. What are challenges with it? Have you coded similar things? Tell me about one. How would you do it different now? How would you convince me that it's worth refactoring? How about if I was your peer and I told you your idea was the worst thing I'd ever heard? Ok, now assume I'm working for you, and it's my second week, explain how to write your new design from scratch, and what some gotchas I should avoid are?" We all know that green field coding is a rarity, and most time is spent writing/running tests, refactoring, bug squashing, design writing, code reviewing, team managing (always at least upwards and sideways). Most of this is still "technical", but seems to be overlooked with endless stupid brain teasers. I know what Knuth volumes are, I know what google is, and I know my basic algorithms. Most people don't need to have memorised how to implement random algorithm x.

archangel_one 13y ago

> Google's brainteasers did not lead to quality candidates This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews. I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour. > I guess I do not see how you can lose if you take the contract-to-hire approach .. For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.

RogerL 13y ago
Well, the person that referred to the article used the wrong term. Certainly brainteasers don't work, and they have been prohibited at Google for awhile. But the recent article stated that there was no correlation between interviewers and job performance. That the beloved hash table, distributed computing, priority queue, red-black tree questions that you pepper people have nothing to do with the quality of the person you hire. Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on. Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?