9 ms·

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production s

by kayman 10y ago

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. At the end of the week, you pay me wages and if you're not happy, you can not extend another week. Isn't this a much better way to evaluate a good candidate?

jimbokun 10y ago
Sure, but some developers with a job already might prefer the interview.
krisgenre 10y ago
This is the perfect and ideal process but unfortunately hard to scale.
- andersonmvd 10y ago
  Regarding scaling: should we really hire developers as we scale servers? I don't think so.
- EpicEng 10y ago
  Forget scale; I don't think it's practical for even one candidate.
amorphid 10y ago
Some reasons against a 1 week working interview: * It can take up to a week just to get someone ramped up with access to things in many environments (setting up accounts, configuring dev environment, etc.) It's not free to create and disable a dev's access. * Most places I've seen aren't set up to ramp someone up in a week. I think Pivotal Labs gives people a try for 3 week contracts, and they have a culture of ramping up new hires via pair programming in XP environment. * You'd only be productive in an environment where you are already familiar with the tools they are using. If they're using Erlang, and you're coming from Java, you simply couldn't do much with Erlang in a week. * Many places can't/won't put you to work without you passing a background check. * Candidates who already have a job aren't likely to be in a position to take a week off to work for someone else.
- dimino 10y ago
  You make a good point, but if I'm getting to pick my ideal work environment though, it's one where I can get ramped up and contributing meaningfully in a week.
  - EpicEng 10y ago
    If I'm working in my ideal work environment, the problem we are trying to solve is too complex to understand fully within a week.
    - dimino 10y ago
      Different strokes, I suppose. Also "understand fully" isn't "can contribute to a sub-problem meaningfully".
- jacalata 10y ago
  Pivotal Labs definitely doesn't require a 3 week contract before hiring, and it never even came up as a theoretical option when I interviewed with them and got an offer last year.
  - amorphid 10y ago
    Gotcha. Maybe the one example I am remembering is a special case, or that person simply didn't work out after three weeks.
redcap 10y ago
What I've seen suggested elsewhere is having publicly viewable code on github or the like - that would effectively be your coding resume and evidence of your ability.
- andyjdavis 10y ago
  True but it is not that hard for someone to fake that if they really want to. That said, faking history in github likely takes enough technical ability that the person could probably do a decent job programming if they use their powers for good.
  - pmiller2 10y ago
    I wouldn't be surprised if there's a pre-baked script out there that clones a repo and rewrites all the commits with a different author and committer.
  - zeemonkee3 10y ago
    Just ask them simple questions about their code. "Why did you use a class here? What does this function do?". Or even what motivated them to do the project or what the hardest challenges were. It should be pretty clear whether they're the real deal or not.
richforrester 10y ago
Yes. Unless you're not the only person we're looking at hiring. We're not going to pay 10 people for a week and hire just one. We'd rather we get a sample by seeing you do some work on a whiteboard, and make some cuts right then and there. In other words: yes, that's a better way for you to prove yourself. No, we don't have the resources for this approach.
- enraged_camel 10y ago
  You don't want to pay 10 people for a week. You want to pay one person at a time over a 10 week stretch. That way, you can evaluate each candidate independently and hire the best one. This is undoubtedly a better approach than doing a bunch of coding interviews, so you should have a strong incentive to make sure you have the resources for it. After all, you want to minimize the risk of hiring mediocre people and maximize the chances of hiring really good people, right? The latter will pay for themselves tenfold.
  - EpicEng 10y ago
    I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months). I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one week eval (and they usually have a job already, so how are they going to get away for a week?). This is a time consuming and expensive proposition which would require buy in at multiple levels from multiple departments and would probably end up not working out so well.
    - richforrester 10y ago
      Thank you, this was almost exactly what I was going to respond with. My only addition: "Alternatively, we can write/review some code on a whiteboard."
      - 10y ago
nilkn 10y ago
Out of curiosity, am I supposed to take an entire week of PTO in order to undergo such an interview process while currently employed? Because I can't really think of a single company I'd be willing to do that for.
modeless 10y ago
That's great of you to offer as a candidate. However, from the interviewer's side, I can't ask candidates to do this. The people I want to hire are already busy. They don't have a whole week to devote to my interview process. Not even if I pay them for it.
EpicEng 10y ago
>Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you. Oh, and did I find you through a recruiter? Now I have to pay them a cut. Do I now get to run this little bureaucratic maze for all N candidates I'm looking at? You have become a very expensive interview across at least three departments and you're probably not worth it. Sorry, but no. I do ask for some whiteboard coding, but it can be done in any language (or pseudo code) and I'm really only trying to tease out your thought process. For a junior or mid level position, yes; I am also trying to figure out if you can write a line of code. I'm also not sure how you're going to be able to get away from your current job for an entire week (I have literally never interviewed a candidate who wasn't fresh out of college who was unemployed at the time). I agree that it can be a pain, but there aren't always better ways to measure your ability to take a problem and turn the solution into an algorithm.
- chief1ic 10y ago
  The fact that you need to involve three different departments just to hire someone for a week is a key part of why hiring is so broken these days.
  - EpicEng 10y ago
    How so? HR needs to be in the loop unless I want to take on payroll, contracts, etc. IT needs to be in the loop unless I want to spend my time setting up equipment, which certainly isn't the best use of it. I am most valuable when I am leading my team and doing engineering. Not every company is some five man outfit, and successful five man outfits have to grow up at some point. There are many things to consider when bringing someone on, even a contractor.
  - phasmantistes 10y ago
Bahamut 10y ago
Most good candidates wouldn't put up with that situation (1 week contracting) - also, years of experience can vary drastically. I recently interviewed a candidate with over 15 years of experience, predominantly in the backend, yet he didn't really have much experience scaling systems. He checked out in all ways until we drilled down into scaling issues.
ffn 10y ago
> evaluate the candidate But candidate evaluation is not an objective business, one company's perfect candidate might be complete trash at another firm. A company's interview process then is necessarily a reflection that company's character, culture, and attitude just as much as it is a process to find potential employees. For example, your suggested hiring process of doing essentially an extended homework assignment might be great for a firm who doesn't care about "hiring the best", "building the elite team" or whatever, and instead wants to just assemble a ragtag team of misfits who trust and work well with each other to get things done. Meanwhile, the Silicon Valley standard Googlesque hiring practice of using timed tree-inverting-list-o(log n)-optimized-talk-through-what-you-are-doing-(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off) algorithm questions to pinpoint the most academically smart candidate is perfect for companies who want to hire the "smartest programmer" to create a culture of intelligence oneupmanship to drive "innovation". And unless one happens to be in a situation where one absolute needs a job right away, a candidate could really glean a lot about a potential company's direction and culture through just how they conduct their interview, and decide if this is, indeed, a place where one could do one's best for the company and continue with the application or apply elsewhere.
- dmoy 10y ago
  90% of devs there don't use his software, and we have no idea why his application was denied :/
- MustardTiger 10y ago
  >(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off) I use tons of open source software written by people I would never consider hiring. "You use something I wrote therefore I am good" is not a reasonable assumption.
grey-area 10y ago
From the perspective of a hiring company, say they have 5 final candidates. Suggesting a 1 week placement will not be practical either for most of the candidates (who still have their old job) or for the company (who has real work to do and not 5 weeks of on-boarding). Also to compare candidates they need them trying the same thing, not 5 different things. I think a few hours discussing code is a small sacrifice for a fairer, more equitable interview process.
gregmac 10y ago
> I'm tired of companies asking me to code at their interviews. I have 10 years experience I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc. Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr). Giant for loops where a simple LINQ query would do. It also failed to solve the problem. 10 years but hasn't learned anything new doesn't count for 10 years experience, in my opinion. That's why even "experienced" developers get coding questions. (Btw, If the candidate hadn't explicitly called out their supposed expertise their use of old coding style could be overlooked; but since they had this on their resume, it either meant they were completely clueless about it, or simply lying. Either way, not a good start.)
- cosmolev 10y ago
  Disclaimer: I've never written any C# code, I write Java code. "Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr)" - while nobody writes code in this way in production this is exactly the way of coding endorsed by Codility-like programming challenges when you have 30 minutes to come up with a solution.
  - winsome 10y ago
    Maybe for someone with no experience in the desired language and minimal access to docs, but for someone that professes a knowledge of C# 6 they ought to at least know about the `TimeSpan` class. For anyone with the knowledge the person claimed to have, that code should boil down to something more like TimeSpan.Parse($"{hourStr}:{minStr}").TotalMinutes;
- yoklov 10y ago
  Going to second the other comment, when you're rushed for time, you don't end up with "beautiful" code (But you should at least solve the problem). I know none of the code I've ever wrote for a job interview was very good. Often it's total shit, hell, it often has a while (true) loop that I break out of later. (usually I ask if they'd like me to clean it up after I get it working properly). If your interview is designed around trying to see stylistic choices such as these (yes, the distinction between writing a loop and using linq is style), you should refocus it to be about figuring out the candidate's thought process.
DigitalSea 10y ago
I have done what you have proposed and it worked for my latest job (2 years and counting). I flat out refused a coding interview. I openly said, in my experience as a developer, great candidates fall through the cracks because they fail under a controlled environment which does not reflect the real world. They actually agreed with me. I came in and did a one week trial, I brought in my own computer, they gave me access to a repository and a task list, told me to do what I could in the week and ask questions. Arguably, the experience was great. I was able to not only see if I wanted to work for this company, but what the people are like and what kind of problems I would be solving. It was a great way for the company to see if I got along with their team and if they liked me as a person. Being a developer is half knowing how to code and the rest is whether or not you are a match personality wise for the company. You might be smart, but can you get along with others and work in different situations? A palindrome function or FizzBuzz during a coding interview can't tell you everything about a developer. You know what else is great? I came onboard as a senior developer, after a year, I was running my own team of 2 other developers. Then something greater happened, I managed to change the way the company hires developers. We do the initial screening which is just a chat to see if their skillset matches the role, then we reduce the list down and bring them in to pair program with someone. It works so well. Also what is cool is that the two developers we have brought on since I started were hired after great work performances during their week trial/interview.
- kriro 10y ago
  Let me add a somewhat unrelated side note since you have some say in the new hiring process which is awesome btw. and the company sounds like they "get it"... Bring your own device should always be understood as a security tradeoff. Especially if it's someone who is auditioning for a job (I'm sure you're aware of that but can't hurt to point it out).
- tigershark 10y ago
  It's actually illegal in all the contracts that I ever had to work for someone else while you are employed for a company. And even if it was legal I would never lose a week salary for some fancy interview that takes a week, plus all the time that it takes to test the other n-people to have an answer.
kriro 10y ago
This is a decent solution if you are a freelancer or between jobs or family free and able to relocate short term (you could do it remote but job interviews if you actually work on premise should also be on premise to some extend). If you're currently holding another job it's pretty tough as you'd essentially have to take a week of vacation time or do all the work remote.
gedrap 10y ago
>>> I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. I don't really agree with this statement. The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. I've seen people with 10+ years of experience rolling out their own web frameworks (and definitely not good ones) every year or two, developers who have never written a single unit test (they don't see the point of it; also the software there was the most bug ridden product I have ever seen, surprise surprise). Their employers were not technical at all so were relatively happy with the results. You wouldn't marry a person after knowing them for a day, just because someone said that he/she is a lovely person, would you? Same here with hiring. But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :)
- BinaryIdiot 10y ago
  > The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. Sure but this really has nothing to do with the parent's post. The parent said they have references and the experience and code in production. All of this is verifiable short of, say, DoD contract work. I doubt you have worked with folks with 10+ years of experience who wouldn't pass as junior developers who also had references and verifiable code running in a production environment (and if you did I would imagine that's a fluke negative hire). > But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :) Considering almost every technology company hires the same way and the employees typically have the "I went through it so you have to do" attitude you're not really going to find another company that has a "better" hiring procedure. Your response is more facetious than realistic. If you want to be a developer you don't have much choice than to go through the system that has been studied to death and known to be flawed.
  - MustardTiger 10y ago
    >Sure but this really has nothing to do with the parent's post. The parent said they have references and the experience and code in production. All of this is verifiable short of, say, DoD contract work. It has everything to do with it. References are completely useless unless you happen to be lucky enough to know one of their references well. A random stranger saying "Bob knows X" is just as useless as Bob telling me he knows X. The references opinion is likely worthless, I can't bet my business on it. And how are we supposed to verify the quality of this in production code, much less its existence? >I doubt you have worked with folks with 10+ years of experience who wouldn't pass as junior developers who also had references and verifiable code running in a production environment (and if you did I would imagine that's a fluke negative hire). That's easily 95%+ people with 10 years experience. Everyone has references, that is not something that is hard to acquire or meaningful in any way. Wordpress is running in production all over, I sure as hell wouldn't want to hire any of the people involved in it.
BinaryIdiot 10y ago
While I agree with your sentiment entirely I think you idea is faulty. Too much up-front cost for the employer and high risk for the employee if you need that job. I would like to see a short homework assignment which is then used to work with the interviewee. At least in some form (idea needs refinement).
ori_b 10y ago
I have better things to do than spend a few months of PTO interviewing with multiple companies. This won't fly with me, and I doubt it will fly with many people that are currently employed.
agentultra 10y ago
> I'm tired of companies asking me to code at their interviews. I get that. I am too. I'm around 13+ years of experience. I have contributions to major open source projects, have given talks at a few conferences, write about my experiences on a blog... it doesn't matter. I've ran into a few interviewers who take a few minutes before the interview to skim my blog. Once I ran into someone who actually read a few posts and saw a talk I've given (always a boon). If you really want to get a sense of how I think and what my code looks like it's out there in the open. Few people will bother to look. Thankfully I've done enough interviews that there are some patterns I can share. Here's my unofficial guide to acing programming interviews: 1. Be honest. Don't put something on your resume because you think it will make you sound good. Yes the first screen is just keyword bingo... but at some point you might make it to a technical interview with someone who hates it when people do this and will make a point of asking you obscure questions about the ANSI C standard. If you've written a few small C programs or done a few tutorials you don't know C -- you've just used it. We tend to over-estimate our abilities which is why interviewers don't trust resumes. But if you want to get a job doing more C don't be afraid to put that out there. 2. Whiteboard coding is stupid. Instead learn logic and predicate calculus. Learn to take a written or oral description of a problem and work out what the constants are and write out an invariant or two. Use pseudo-code. Pretend you are a caricature of a white-haired professor teaching a class... write out the problem, go on tangents, explain your reasoning in steps. Write pseudo-code only if pressed. 3. Coding. Long before you start interviewing start a repository. Pick the language you're strongest in and work out the following problems: a function to detect a palindrome, a function to detect an anagram, a function to find the Nth number of the fibonacci sequence, a function to generate the list of numbers of the fibonacci sequence, and fizzbuzz. Try to come up with more than one solution to each problem. Re-type them out. Commit them to memory by rote practice. Work out problems on coding practice sites and add the most popular, boring ones to your repository. As you interview add questions you come across to your repository. Practice the most common ones. Commit them to memory. This is probably one of the most inane practices in hiring but it's also one of the easiest to overcome. 90% of interview coding problems are regurgitated Google searches for interview coding problems. 4. Prepare a list of questions to ask the interviewer before hand. At some point they're going to ask you if you have any questions for them. Grill them hard. What makes them excited about their job? What's the hardest problem they've had to overcome? What is their greatest failure? What did they do about it after? What is the most common problem they expect you to encounter in this role? Etc, etc. Know who you're talking to -- save this for the technical interviewer whom you'll likely be working alongside/for. Before you know it you'll be done. You might get an email or a phone call letting you know whether you made it to the next round or whatever. You may not make it. The important thing to remember: It's not personal, it's not pervasive, and it's not permanent. Remember that every person you encounter is living a life and story that is every bit as complex and deep as yours. There are a number of possible circumstances affecting your position that you have very little control over: it's not your fault if you don't ace every interview as you likely won't despite how hard you try. If you're persistent you'll eventually find something. Happy hacking.
allsystemsgo 10y ago
Couldn't agree more. It's getting ridiculous.
gimpster 10y ago
This reminds me of "smart and gets things done". Your idea is to test whether people can get things done. An interview can test how smart they are. Both are important. I've seen web developers with years of experience delivering successful projects who turned out to be terrible programmers. In this situation, it is nearly always because they're not smart enough or because they have an anti-intellectual outlook on life ("I found this on stack overflow, it works, I don't understand it in depth but it's good enough for me" or "why would I know that, I never needed it") or often both. They were ok churning out 4 month projects one after the other or maintaining some business web site for years, but when you have them working on difficult and complex problems, their abilities turn out to be lacking and the brilliant kid with much less experience turns out to be much more useful.

by kayman 10y ago

jimbokun 10y ago

Sure, but some developers with a job already might prefer the interview.

krisgenre 10y ago

This is the perfect and ideal process but unfortunately hard to scale.

andersonmvd 10y ago
Regarding scaling: should we really hire developers as we scale servers? I don't think so.
EpicEng 10y ago
Forget scale; I don't think it's practical for even one candidate.

amorphid 10y ago

Some reasons against a 1 week working interview: * It can take up to a week just to get someone ramped up with access to things in many environments (setting up accounts, configuring dev environment, etc.) It's not free to create and disable a dev's access. * Most places I've seen aren't set up to ramp someone up in a week. I think Pivotal Labs gives people a try for 3 week contracts, and they have a culture of ramping up new hires via pair programming in XP environment. * You'd only be productive in an environment where you are already familiar with the tools they are using. If they're using Erlang, and you're coming from Java, you simply couldn't do much with Erlang in a week. * Many places can't/won't put you to work without you passing a background check. * Candidates who already have a job aren't likely to be in a position to take a week off to work for someone else.

dimino 10y ago
You make a good point, but if I'm getting to pick my ideal work environment though, it's one where I can get ramped up and contributing meaningfully in a week.
- EpicEng 10y ago
  If I'm working in my ideal work environment, the problem we are trying to solve is too complex to understand fully within a week.
  - dimino 10y ago
    Different strokes, I suppose. Also "understand fully" isn't "can contribute to a sub-problem meaningfully".
jacalata 10y ago
Pivotal Labs definitely doesn't require a 3 week contract before hiring, and it never even came up as a theoretical option when I interviewed with them and got an offer last year.
- amorphid 10y ago
  Gotcha. Maybe the one example I am remembering is a special case, or that person simply didn't work out after three weeks.

redcap 10y ago

What I've seen suggested elsewhere is having publicly viewable code on github or the like - that would effectively be your coding resume and evidence of your ability.

andyjdavis 10y ago
True but it is not that hard for someone to fake that if they really want to. That said, faking history in github likely takes enough technical ability that the person could probably do a decent job programming if they use their powers for good.
- pmiller2 10y ago
  I wouldn't be surprised if there's a pre-baked script out there that clones a repo and rewrites all the commits with a different author and committer.
- zeemonkee3 10y ago
  Just ask them simple questions about their code. "Why did you use a class here? What does this function do?". Or even what motivated them to do the project or what the hardest challenges were. It should be pretty clear whether they're the real deal or not.

richforrester 10y ago

Yes. Unless you're not the only person we're looking at hiring. We're not going to pay 10 people for a week and hire just one. We'd rather we get a sample by seeing you do some work on a whiteboard, and make some cuts right then and there. In other words: yes, that's a better way for you to prove yourself. No, we don't have the resources for this approach.

enraged_camel 10y ago
You don't want to pay 10 people for a week. You want to pay one person at a time over a 10 week stretch. That way, you can evaluate each candidate independently and hire the best one. This is undoubtedly a better approach than doing a bunch of coding interviews, so you should have a strong incentive to make sure you have the resources for it. After all, you want to minimize the risk of hiring mediocre people and maximize the chances of hiring really good people, right? The latter will pay for themselves tenfold.
- EpicEng 10y ago
  I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months). I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one week eval (and they usually have a job already, so how are they going to get away for a week?). This is a time consuming and expensive proposition which would require buy in at multiple levels from multiple departments and would probably end up not working out so well.
  - richforrester 10y ago
    Thank you, this was almost exactly what I was going to respond with. My only addition: "Alternatively, we can write/review some code on a whiteboard."
    - 10y ago

nilkn 10y ago

Out of curiosity, am I supposed to take an entire week of PTO in order to undergo such an interview process while currently employed? Because I can't really think of a single company I'd be willing to do that for.

modeless 10y ago

That's great of you to offer as a candidate. However, from the interviewer's side, I can't ask candidates to do this. The people I want to hire are already busy. They don't have a whole week to devote to my interview process. Not even if I pay them for it.

EpicEng 10y ago

>Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you. Oh, and did I find you through a recruiter? Now I have to pay them a cut. Do I now get to run this little bureaucratic maze for all N candidates I'm looking at? You have become a very expensive interview across at least three departments and you're probably not worth it. Sorry, but no. I do ask for some whiteboard coding, but it can be done in any language (or pseudo code) and I'm really only trying to tease out your thought process. For a junior or mid level position, yes; I am also trying to figure out if you can write a line of code. I'm also not sure how you're going to be able to get away from your current job for an entire week (I have literally never interviewed a candidate who wasn't fresh out of college who was unemployed at the time). I agree that it can be a pain, but there aren't always better ways to measure your ability to take a problem and turn the solution into an algorithm.

chief1ic 10y ago
The fact that you need to involve three different departments just to hire someone for a week is a key part of why hiring is so broken these days.
- EpicEng 10y ago
  How so? HR needs to be in the loop unless I want to take on payroll, contracts, etc. IT needs to be in the loop unless I want to spend my time setting up equipment, which certainly isn't the best use of it. I am most valuable when I am leading my team and doing engineering. Not every company is some five man outfit, and successful five man outfits have to grow up at some point. There are many things to consider when bringing someone on, even a contractor.
- phasmantistes 10y ago

Bahamut 10y ago

Most good candidates wouldn't put up with that situation (1 week contracting) - also, years of experience can vary drastically. I recently interviewed a candidate with over 15 years of experience, predominantly in the backend, yet he didn't really have much experience scaling systems. He checked out in all ways until we drilled down into scaling issues.

ffn 10y ago

> evaluate the candidate But candidate evaluation is not an objective business, one company's perfect candidate might be complete trash at another firm. A company's interview process then is necessarily a reflection that company's character, culture, and attitude just as much as it is a process to find potential employees. For example, your suggested hiring process of doing essentially an extended homework assignment might be great for a firm who doesn't care about "hiring the best", "building the elite team" or whatever, and instead wants to just assemble a ragtag team of misfits who trust and work well with each other to get things done. Meanwhile, the Silicon Valley standard Googlesque hiring practice of using timed tree-inverting-list-o(log n)-optimized-talk-through-what-you-are-doing-(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off) algorithm questions to pinpoint the most academically smart candidate is perfect for companies who want to hire the "smartest programmer" to create a culture of intelligence oneupmanship to drive "innovation". And unless one happens to be in a situation where one absolute needs a job right away, a candidate could really glean a lot about a potential company's direction and culture through just how they conduct their interview, and decide if this is, indeed, a place where one could do one's best for the company and continue with the application or apply elsewhere.

dmoy 10y ago
90% of devs there don't use his software, and we have no idea why his application was denied :/
MustardTiger 10y ago
>(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off) I use tons of open source software written by people I would never consider hiring. "You use something I wrote therefore I am good" is not a reasonable assumption.

grey-area 10y ago

From the perspective of a hiring company, say they have 5 final candidates. Suggesting a 1 week placement will not be practical either for most of the candidates (who still have their old job) or for the company (who has real work to do and not 5 weeks of on-boarding). Also to compare candidates they need them trying the same thing, not 5 different things. I think a few hours discussing code is a small sacrifice for a fairer, more equitable interview process.

gregmac 10y ago

> I'm tired of companies asking me to code at their interviews. I have 10 years experience I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc. Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr). Giant for loops where a simple LINQ query would do. It also failed to solve the problem. 10 years but hasn't learned anything new doesn't count for 10 years experience, in my opinion. That's why even "experienced" developers get coding questions. (Btw, If the candidate hadn't explicitly called out their supposed expertise their use of old coding style could be overlooked; but since they had this on their resume, it either meant they were completely clueless about it, or simply lying. Either way, not a good start.)

cosmolev 10y ago
Disclaimer: I've never written any C# code, I write Java code. "Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr)" - while nobody writes code in this way in production this is exactly the way of coding endorsed by Codility-like programming challenges when you have 30 minutes to come up with a solution.
- winsome 10y ago
  Maybe for someone with no experience in the desired language and minimal access to docs, but for someone that professes a knowledge of C# 6 they ought to at least know about the `TimeSpan` class. For anyone with the knowledge the person claimed to have, that code should boil down to something more like TimeSpan.Parse($"{hourStr}:{minStr}").TotalMinutes;
yoklov 10y ago
Going to second the other comment, when you're rushed for time, you don't end up with "beautiful" code (But you should at least solve the problem). I know none of the code I've ever wrote for a job interview was very good. Often it's total shit, hell, it often has a while (true) loop that I break out of later. (usually I ask if they'd like me to clean it up after I get it working properly). If your interview is designed around trying to see stylistic choices such as these (yes, the distinction between writing a loop and using linq is style), you should refocus it to be about figuring out the candidate's thought process.

DigitalSea 10y ago

I have done what you have proposed and it worked for my latest job (2 years and counting). I flat out refused a coding interview. I openly said, in my experience as a developer, great candidates fall through the cracks because they fail under a controlled environment which does not reflect the real world. They actually agreed with me. I came in and did a one week trial, I brought in my own computer, they gave me access to a repository and a task list, told me to do what I could in the week and ask questions. Arguably, the experience was great. I was able to not only see if I wanted to work for this company, but what the people are like and what kind of problems I would be solving. It was a great way for the company to see if I got along with their team and if they liked me as a person. Being a developer is half knowing how to code and the rest is whether or not you are a match personality wise for the company. You might be smart, but can you get along with others and work in different situations? A palindrome function or FizzBuzz during a coding interview can't tell you everything about a developer. You know what else is great? I came onboard as a senior developer, after a year, I was running my own team of 2 other developers. Then something greater happened, I managed to change the way the company hires developers. We do the initial screening which is just a chat to see if their skillset matches the role, then we reduce the list down and bring them in to pair program with someone. It works so well. Also what is cool is that the two developers we have brought on since I started were hired after great work performances during their week trial/interview.

kriro 10y ago
Let me add a somewhat unrelated side note since you have some say in the new hiring process which is awesome btw. and the company sounds like they "get it"... Bring your own device should always be understood as a security tradeoff. Especially if it's someone who is auditioning for a job (I'm sure you're aware of that but can't hurt to point it out).
tigershark 10y ago
It's actually illegal in all the contracts that I ever had to work for someone else while you are employed for a company. And even if it was legal I would never lose a week salary for some fancy interview that takes a week, plus all the time that it takes to test the other n-people to have an answer.

kriro 10y ago

This is a decent solution if you are a freelancer or between jobs or family free and able to relocate short term (you could do it remote but job interviews if you actually work on premise should also be on premise to some extend). If you're currently holding another job it's pretty tough as you'd essentially have to take a week of vacation time or do all the work remote.

gedrap 10y ago

>>> I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. I don't really agree with this statement. The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. I've seen people with 10+ years of experience rolling out their own web frameworks (and definitely not good ones) every year or two, developers who have never written a single unit test (they don't see the point of it; also the software there was the most bug ridden product I have ever seen, surprise surprise). Their employers were not technical at all so were relatively happy with the results. You wouldn't marry a person after knowing them for a day, just because someone said that he/she is a lovely person, would you? Same here with hiring. But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :)

BinaryIdiot 10y ago
> The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. Sure but this really has nothing to do with the parent's post. The parent said they have references and the experience and code in production. All of this is verifiable short of, say, DoD contract work. I doubt you have worked with folks with 10+ years of experience who wouldn't pass as junior developers who also had references and verifiable code running in a production environment (and if you did I would imagine that's a fluke negative hire). > But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :) Considering almost every technology company hires the same way and the employees typically have the "I went through it so you have to do" attitude you're not really going to find another company that has a "better" hiring procedure. Your response is more facetious than realistic. If you want to be a developer you don't have much choice than to go through the system that has been studied to death and known to be flawed.
- MustardTiger 10y ago
  >Sure but this really has nothing to do with the parent's post. The parent said they have references and the experience and code in production. All of this is verifiable short of, say, DoD contract work. It has everything to do with it. References are completely useless unless you happen to be lucky enough to know one of their references well. A random stranger saying "Bob knows X" is just as useless as Bob telling me he knows X. The references opinion is likely worthless, I can't bet my business on it. And how are we supposed to verify the quality of this in production code, much less its existence? >I doubt you have worked with folks with 10+ years of experience who wouldn't pass as junior developers who also had references and verifiable code running in a production environment (and if you did I would imagine that's a fluke negative hire). That's easily 95%+ people with 10 years experience. Everyone has references, that is not something that is hard to acquire or meaningful in any way. Wordpress is running in production all over, I sure as hell wouldn't want to hire any of the people involved in it.

BinaryIdiot 10y ago

While I agree with your sentiment entirely I think you idea is faulty. Too much up-front cost for the employer and high risk for the employee if you need that job. I would like to see a short homework assignment which is then used to work with the interviewee. At least in some form (idea needs refinement).

ori_b 10y ago

I have better things to do than spend a few months of PTO interviewing with multiple companies. This won't fly with me, and I doubt it will fly with many people that are currently employed.

agentultra 10y ago

> I'm tired of companies asking me to code at their interviews. I get that. I am too. I'm around 13+ years of experience. I have contributions to major open source projects, have given talks at a few conferences, write about my experiences on a blog... it doesn't matter. I've ran into a few interviewers who take a few minutes before the interview to skim my blog. Once I ran into someone who actually read a few posts and saw a talk I've given (always a boon). If you really want to get a sense of how I think and what my code looks like it's out there in the open. Few people will bother to look. Thankfully I've done enough interviews that there are some patterns I can share. Here's my unofficial guide to acing programming interviews: 1. Be honest. Don't put something on your resume because you think it will make you sound good. Yes the first screen is just keyword bingo... but at some point you might make it to a technical interview with someone who hates it when people do this and will make a point of asking you obscure questions about the ANSI C standard. If you've written a few small C programs or done a few tutorials you don't know C -- you've just used it. We tend to over-estimate our abilities which is why interviewers don't trust resumes. But if you want to get a job doing more C don't be afraid to put that out there. 2. Whiteboard coding is stupid. Instead learn logic and predicate calculus. Learn to take a written or oral description of a problem and work out what the constants are and write out an invariant or two. Use pseudo-code. Pretend you are a caricature of a white-haired professor teaching a class... write out the problem, go on tangents, explain your reasoning in steps. Write pseudo-code only if pressed. 3. Coding. Long before you start interviewing start a repository. Pick the language you're strongest in and work out the following problems: a function to detect a palindrome, a function to detect an anagram, a function to find the Nth number of the fibonacci sequence, a function to generate the list of numbers of the fibonacci sequence, and fizzbuzz. Try to come up with more than one solution to each problem. Re-type them out. Commit them to memory by rote practice. Work out problems on coding practice sites and add the most popular, boring ones to your repository. As you interview add questions you come across to your repository. Practice the most common ones. Commit them to memory. This is probably one of the most inane practices in hiring but it's also one of the easiest to overcome. 90% of interview coding problems are regurgitated Google searches for interview coding problems. 4. Prepare a list of questions to ask the interviewer before hand. At some point they're going to ask you if you have any questions for them. Grill them hard. What makes them excited about their job? What's the hardest problem they've had to overcome? What is their greatest failure? What did they do about it after? What is the most common problem they expect you to encounter in this role? Etc, etc. Know who you're talking to -- save this for the technical interviewer whom you'll likely be working alongside/for. Before you know it you'll be done. You might get an email or a phone call letting you know whether you made it to the next round or whatever. You may not make it. The important thing to remember: It's not personal, it's not pervasive, and it's not permanent. Remember that every person you encounter is living a life and story that is every bit as complex and deep as yours. There are a number of possible circumstances affecting your position that you have very little control over: it's not your fault if you don't ace every interview as you likely won't despite how hard you try. If you're persistent you'll eventually find something. Happy hacking.

allsystemsgo 10y ago

Couldn't agree more. It's getting ridiculous.

gimpster 10y ago

This reminds me of "smart and gets things done". Your idea is to test whether people can get things done. An interview can test how smart they are. Both are important. I've seen web developers with years of experience delivering successful projects who turned out to be terrible programmers. In this situation, it is nearly always because they're not smart enough or because they have an anti-intellectual outlook on life ("I found this on stack overflow, it works, I don't understand it in depth but it's good enough for me" or "why would I know that, I never needed it") or often both. They were ok churning out 4 month projects one after the other or maintaining some business web site for years, but when you have them working on difficult and complex problems, their abilities turn out to be lacking and the brilliant kid with much less experience turns out to be much more useful.