16 ms·

The Technical Interview Rift

50 points by DonPellegrino 10y ago

jakewins 10y ago
> These are ways to gauge if they know the langue without making them write code. You should never ask a developer to write anything from scratch, or write anything. But.. why? You are hiring someone to write code, what better way to gauge their ability to do so than a work sample? Obviously you don't drill someone on sorting algorithms, unless that's what you are hiring them for, but make them solve a simple task that is on the level of abstraction and in the domain your company deals with. Having sat through interviews where candidates who had made it through screenings and talked the technical talk turned out to be unable to write actual code to solve rudimentary domain problems, there's no way I'm hiring a developer without programming with them first.
- luhn 10y ago
  The argument I usually hear is that many people don't do well under pressure or with others looking on. So by doing coding tests or whiteboard tests or whatever, you're selecting for people who do well in high-pressure situations, rather than people who are talented coders. But I agree with you. I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz.
  - inframouse 10y ago
    On the one hand, there a significant number of people that can't fizzbuzz applying for the jobs. On the other hand, there are a significant number of people that can only do the interviews and are not good engineers in general once hired. This is made even worse by 1) the cottage industry teaching people to crack/break the interview process, and 2) the number of people hyping their personal "brand" via conf talks, standards nonsense, etc. as a way to sidestep more engineering vetting. (Not everyone does this of course -- but there's a significant number of people that do it just for career upside). Personal anecdote as a hiring manager: I've found that some of the best interviewees but mediocre mid-level engineers are those with a history of low to mid-level jobs at the largest companies.
  - lj3 10y ago
    > I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz. And I've interviewed many people who can do fizzbuzz because they studied for it (CTCI) and wind up being terrible programmers. The end result? Technical interviews are, at best, a completely random hiring signal. You'd be better off flipping a coin. It's better to be lucky than good, so why not use luck as a selection criteria?
    - jakewins 10y ago
      But, if you aren't hiring a developer specifically to implement fizzbuzz for you, why are you giving them that as a problem to solve? Hiring someone to work on a Flask REST API? Make them add a REST endpoint to a little flask app. Hiring someone to do CSS? Make them style a form. Hiring someone to build a database? Make them safely write to disk. This is far from random - it's been almost twenty years since Schmidt and Hunter showed that a work sample is one of the best predictors of future performance, 24%, vs 3% for unstructured interviewing. http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...
      - lj3 10y ago
        I couldn't agree more. The problem with most work sample tests is the length and the format. Most are too long and they have you start with nothing. Adding a rest endpoint to a little flask app is perfect. It's a shame nobody actually does this kind of work sample test. And thanks for that study. It'll make for some nice ammunition. :)
crispyambulance 10y ago
I am glad to see managers that give interviewing the level attention it deserves. Many interviewers just assume they know how to interview people to find the so-called "A player" (yeah, we're up to A+ now too). People love the idea of magic gotcha questions the answer of which determines whether a person is or is-not skilled some specific area. But the reality is most orgs are barely sophisticated enough to manage FIZZBUZZ-level screening, let alone screening for "A players." Proven interview techniques that take practice, training and coordination like the Behavioral Interview are often skipped in favor of ad-hoc, unprepared interviews that end up with a go/no-go vote.
arcanus 10y ago
> All in all, would do again, except not more than 1 a month because flying across a continent and back for 1.5 days is gruelling. This is part of the problem. Aside from college graduates, who has time to fly around the country burning vacation time to maybe get an offer?
- cbanek 10y ago
  On the other hand, would you really accept an offer without having at least met the people you'd have to work with? Especially if you have to move across the country?
  - psyc 10y ago
    Video chat is good enough for me. I don't need to know about their posture or how long their legs are.
    - cbanek 10y ago
      This might just be me, but video chat doesn't really do it. You don't get an idea of the building, bathrooms, cafeteria, and the general idea of how often your coworkers bathe. All of these can be pretty important to my general mental health.
      - bdavisx 10y ago
        Yes, and they could easily hide a noisy, chaotic work environment in a video chat as well.
  - misthop 10y ago
    I wouldn't, no. But in the 2 situations where I have been asked to fly to a company I said I would be happy to once I had an offer of employment. Both did remote interviews and extended an offer.
AvenueIngres 10y ago
Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is passionate and resourceful by talking with them, occasionally erring on research-ish stuff but always focusing on the implementation rather than the theory. Plus I sometimes stumble on the occasional gem that is very knowledgeable and from whom I can learn. Whiteboard interviews, coding challenges, take-home projects. All of those things are so time-consuming for both the company, the interviewer and, of course, the applicant. And all of that just in the hope that the company will accept them... maybe? Of course when nothing else is available then it is the usual drill: phone, skype, on-site 1, on-site 2. But if other signals are available then to the trash it goes.
- mancerayder 10y ago
  If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
  - sqeaky 10y ago
    > says that any code we write belongs to the company. I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here > But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager? I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.
    - mancerayder 10y ago
blantonl 10y ago
I view technical interviews that require algorithm solving and coding on a whiteboard as ridiculous. Primarily, because I am deathly afraid of them. And here is why. I own and operate two online businesses in the Radio Communications space that are the de-facto standards for our industry. I've coded both of them from the ground up in PHP/MySQL and manage all the day to day administration of these sites. Our infrastructure is deployed on 20+ servers on AWS, Google Cloud, and some bare metal deployments, for which I manage solely by myself. We have 100's of TB of audio archive storage that is all developed and managed by myself. I've personally tackled the entire stack from the ground up, end to end. I've hired an outside consultant, once, to do graphic design work. I've taught myself titanium accelerator and released a highly successful mobile app for my business for Android and iOS. I've even deployed much of our API using NodeJS! Gasp! I do all security, SEO, sysadmin, scheduling, upgrades, marketing etc. But I'm not a computer scientist. If you asked me to outline a best-case sorting algorithm for x use case my response would be "uhhh... " If you asked me to write out a for loop in PHP on a whiteboard I'd say to myself "uh... where do the semicolons go again?" But I can piece together building blocks from AWS, Stack Overflow, open source projects, multiple SAAS providers. I can also write contracts, executive license agreements with third-parties, develop highly successful and consumable APIs, and manage the financials for a multi-million dollar business. I've also deployed multiple APIs in SOAP, XML, and JSON which form the most successful parts of my business But get me up in front of a technical interview team where the startup is looking for a computer scientist and I'll have a ton of "yea, but..." and probably wouldn't last too long. So when I see these examples of technical interviews in organizations where I know I could add value, but realize their process for evaluating that value could certainly eliminate me very early, that scares the crap out of me. Fortunately, my business has been successful enough that this will never be a scenario I have to face. It still bothers me though.
- nilkn 10y ago
  It sounds to me like you're more of a technically inclined software executive/business person than a coder. Would you agree or disagree with that statement? Your run-of-the-mill programmer isn't going to be writing any contracts or license agreements and they're certainly not going to be managing any financials. If the interviews consist entirely of whiteboard problems, then they're probably just planning on sticking you onto an agile team where you'll grab tickets off a queue every morning and churn through them at your own pace. It sounds to me like this is quite a bit different from what you've actually been doing. So I guess the point I'm trying to drive at here is that maybe your mistake is identifying yourself as just a software developer when you're actually an executive?
svachalek 10y ago
From a Silicon Valley perspective, I didn't even know that this was something that companies considered not doing. 'Round here, a technical interview is guaranteed, it's more a question of if/when there will be anything else involved in the interview. Also, will it be a mundane technical interview, or more like 6+ hours doing Top-Coder style questions on a whiteboard? It used to be only Microsoft and Google were known for that but now it's practically everyone as far as I can tell.
- abecedarius 10y ago
  Re: your last sentence, it's been common in my experience for at least the last couple of decades: that is, interviews for most of a working day, including at least one each focused on coding and design. Maybe my experience is unusual, but there were both big companies and startups.
kafkaesq 10y ago
Some useful advice, but something about the overall tone seems a bit off: You are a manager and it’s time to hire a new developer to join your impressive team of A+ players. That's where things started to go of course. You're not an "A+ player", and most of your team aren't "A+ players" either. You're just human beings doing the best you can and (hopefully) trying to improve a bit each day -- like anybody else. No one wants to work with losers. But any (serious) talk of of "We're all A+ players here!" or "I know how to spot A+ players!" is just motivational kool-aid, and ultimately a distraction from the real work you have to do -- including the task of finding the best people you can hire, and who are willing to throw their lot with your cause. Especially when it's quite often the people hired for their seeming "A+" qualities (which they are able to exude in spades) who turn out to be the most toxic, morale-killing members of your (once) impressive team.
- jghn 10y ago
  When I see job postings or recruiter messages talking about how they only hire The Best I immediately tune out. At best they'll be extremely misguided and delusional. At worst they'll be massive Dbags
- jackmott 10y ago
  oh you said toxic.
- mathattack 10y ago
  A+ is also relative to the environment. Performance doesn't always extend across companies. Solo programmers who are an A+ in informal environments struggle in environments that require more inter-programmer coordination. And some A+ specialists sometimes struggle when expected to be generalists, and vice versa. Some big company superstars thrive in small companies, but not all. And some startup superstars would fall apart with the structure of Microsoft and Google.
- jasode 10y ago
  >, but something about the overall tone seems a bit off: [...] You're not an "A+ player", and most of your team aren't "A+ players" either. I believe you misinterpreted the author's backhanded "compliment" about teams' _self-proclaimed_ "impressive A+ players". His tone is sarcasm if you combine it with the repeated fixation on "Fibonacci" puzzles in the rest of the essay: - quote: , what possible insight does questions like “solve a Fibonacci sequence” + whiteboard + no internet give you to know about a person fit for a development role? - Go Beyond Fibonacci Pen/Paper Tests to Assess Candidates - If you get Fibonacci’ed in your next job interview, perhaps you should look elsewhere? If you are the one doing the Fibonacci’ing, you are doing it wrong. (In other words, if your team bombards candidates with Fibonacci, you of course will think your company consists of A+ players!) His "tone" might have tripped the obvious sarcasm detector more readily if he wrote it to say: "it's time to hire a new developer to join your impressive Project Euler hackathon champions. blah blah blah"
lisper 10y ago
I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you happen to get a word/question you know, you look awesome. If you don't, you don't. (Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss.) I just wish Triplebyte would expand their outreach beyond YC companies.
- kafkaesq 10y ago
  Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method (1) Better to say you were unable to "remember", rather than a "figure out". No one ever "figures out" things like the Newton-Raphson method over the phone -- not even people like Isaac Newton or Joseph Raphson (substituting whatever comparable level of distraction on had to contend with in those days, absent telephones -- "while ordering a beer at the pub", I guess). (2) The use of this question as a binary hiring filter (mindlessly copy-and-pasted from their rough impression of what ever other company is doing in 2016) was a failure on their side, not yours.
  - lisper 10y ago
    Actually, under non-brain-wedgie conditions, I can re-derive Newton-Raphson because I do have a good conceptual grasp of it. (In fact, after I got off the phone, I did it just to convince myself that I could. It took me about five minutes, which is nothing under realistic conditions, but a long time when you're on the phone.) But at the time I had a brain wedgie, and the interviewer just kept pushing and prodding and wouldn't let it go. It was damned annoying. I was sitting there thinking, why are you so fixated on this? It was definitely their loss because the technical problems they were facing were very similar to ones that I had faced (and solved!) in a previous startup (network optimization problems). But I never even got to talk about that. Because of that experience, I now make it point whenever I interview someone to always ask, particularly if they're floundering, "What should I ask you about that will let you show off your strengths?" I don't have any qualms rejecting someone who can't answer that question (and a surprising number of candidates can't).
amorphid 10y ago
When I worked as a technical recruiter, I found that a great way to screen candidates was to explain the "box" I was trying to put them in. I described the work I'd done to research the position, why I was screening for certain criteria, and that ultimately I wanted to get their approval on the summary I had written about them. Being non-technical, this worked better for positions I was experienced recruiting for of course. For example, when recruiting a web developer, I'd start by asking a hiring manager what they wanted. "Get me a full stack Rails developer who knows OO Javascript." Then I'd just drill into why they asked for that until I didn' have manh questions. I'd be able to describe roughly what projects needed attention, how the tech stack helped solve that problem, and ask the candidate to help me sell them as someone who can do that. It wasn't perfect, but it worked better than most recruiting attempts I've experienced so far. Now as a developer with a few years of experience, I feel I have no idea what I am doing, and am winging it at all times :)
pklausler 10y ago
OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community." The companies constitute the community. The community comprises the companies.
- tdumitrescu 10y ago
  "In addition to its original senses, dating from the 15th century, “to include” and “to consist of ” ( The United States of America comprises 50 states), comprise has had since the late 18th century the meaning “to form or constitute” ( Fifty states comprise the United States of America)." http://www.dictionary.com/browse/comprise http://www.dictionary.com/browse/comprise
  - pklausler 10y ago
    This is like legitimatizing incorrect usage of "literally" or "unique" because some people don't know their definitions. It is ambiguous and sloppy to misuse a word as if it means its antonym.
- clifanatic 10y ago
  And: > as eluded in the following It "alludes" (to), not "eludes". And you and I are both complete jerks for being literate in at least one natural language.
  - pklausler 10y ago
    It literally kills me how performant and impactful your code is to the many unique users that comprise the community. :-) Seriously, though, the original attempt at writing actually does mean something -- if the companies do comprise communities somehow (perhaps of users or shareholders), then it makes sense to reference the subset of companies that comprise a particular community. But that's not what the author intended to say -- they just wanted a pompous way to say "all the companies" or (better) "the companies". (And don't get me started about misusing "community" to mean "group" or "collection" or "lame way to make the preceding word plural", as in "the developer community".)
sssilver 10y ago
This is what I don't understand. During technical interviews, why don't we just give the potential employee a laptop and ask them to solve the problem as they would during a regular work day? Why can't they search Stack Overflow, and perhaps reach out to a friend or even a random person on IRC for advice? Isn't this how the real life works? They may not know anything about min heaps, but perhaps a 15 minute research will help them solve the problem better than anyone who actually memorized Cracking the Software Interview by heart? Isn't it better to measure discipline and ability to learn and solve problems instead of measuring existing knowledge?

50 points by DonPellegrino 10y ago

> These are ways to gauge if they know the langue without making them write code. You should never ask a developer to write anything from scratch, or write anything. But.. why? You are hiring someone to write code, what better way to gauge their ability to do so than a work sample? Obviously you don't drill someone on sorting algorithms, unless that's what you are hiring them for, but make them solve a simple task that is on the level of abstraction and in the domain your company deals with. Having sat through interviews where candidates who had made it through screenings and talked the technical talk turned out to be unable to write actual code to solve rudimentary domain problems, there's no way I'm hiring a developer without programming with them first.

luhn 10y ago
The argument I usually hear is that many people don't do well under pressure or with others looking on. So by doing coding tests or whiteboard tests or whatever, you're selecting for people who do well in high-pressure situations, rather than people who are talented coders. But I agree with you. I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz.
- inframouse 10y ago
  On the one hand, there a significant number of people that can't fizzbuzz applying for the jobs. On the other hand, there are a significant number of people that can only do the interviews and are not good engineers in general once hired. This is made even worse by 1) the cottage industry teaching people to crack/break the interview process, and 2) the number of people hyping their personal "brand" via conf talks, standards nonsense, etc. as a way to sidestep more engineering vetting. (Not everyone does this of course -- but there's a significant number of people that do it just for career upside). Personal anecdote as a hiring manager: I've found that some of the best interviewees but mediocre mid-level engineers are those with a history of low to mid-level jobs at the largest companies.
- lj3 10y ago
  > I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz. And I've interviewed many people who can do fizzbuzz because they studied for it (CTCI) and wind up being terrible programmers. The end result? Technical interviews are, at best, a completely random hiring signal. You'd be better off flipping a coin. It's better to be lucky than good, so why not use luck as a selection criteria?
  - jakewins 10y ago
    But, if you aren't hiring a developer specifically to implement fizzbuzz for you, why are you giving them that as a problem to solve? Hiring someone to work on a Flask REST API? Make them add a REST endpoint to a little flask app. Hiring someone to do CSS? Make them style a form. Hiring someone to build a database? Make them safely write to disk. This is far from random - it's been almost twenty years since Schmidt and Hunter showed that a work sample is one of the best predictors of future performance, 24%, vs 3% for unstructured interviewing. http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...
    - lj3 10y ago
      I couldn't agree more. The problem with most work sample tests is the length and the format. Most are too long and they have you start with nothing. Adding a rest endpoint to a little flask app is perfect. It's a shame nobody actually does this kind of work sample test. And thanks for that study. It'll make for some nice ammunition. :)

crispyambulance 10y ago

I am glad to see managers that give interviewing the level attention it deserves. Many interviewers just assume they know how to interview people to find the so-called "A player" (yeah, we're up to A+ now too). People love the idea of magic gotcha questions the answer of which determines whether a person is or is-not skilled some specific area. But the reality is most orgs are barely sophisticated enough to manage FIZZBUZZ-level screening, let alone screening for "A players." Proven interview techniques that take practice, training and coordination like the Behavioral Interview are often skipped in favor of ad-hoc, unprepared interviews that end up with a go/no-go vote.

arcanus 10y ago

> All in all, would do again, except not more than 1 a month because flying across a continent and back for 1.5 days is gruelling. This is part of the problem. Aside from college graduates, who has time to fly around the country burning vacation time to maybe get an offer?

cbanek 10y ago
On the other hand, would you really accept an offer without having at least met the people you'd have to work with? Especially if you have to move across the country?
- psyc 10y ago
  Video chat is good enough for me. I don't need to know about their posture or how long their legs are.
  - cbanek 10y ago
    This might just be me, but video chat doesn't really do it. You don't get an idea of the building, bathrooms, cafeteria, and the general idea of how often your coworkers bathe. All of these can be pretty important to my general mental health.
    - bdavisx 10y ago
      Yes, and they could easily hide a noisy, chaotic work environment in a video chat as well.
- misthop 10y ago
  I wouldn't, no. But in the 2 situations where I have been asked to fly to a company I said I would be happy to once I had an offer of employment. Both did remote interviews and extended an offer.

AvenueIngres 10y ago

Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is passionate and resourceful by talking with them, occasionally erring on research-ish stuff but always focusing on the implementation rather than the theory. Plus I sometimes stumble on the occasional gem that is very knowledgeable and from whom I can learn. Whiteboard interviews, coding challenges, take-home projects. All of those things are so time-consuming for both the company, the interviewer and, of course, the applicant. And all of that just in the hope that the company will accept them... maybe? Of course when nothing else is available then it is the usual drill: phone, skype, on-site 1, on-site 2. But if other signals are available then to the trash it goes.

mancerayder 10y ago
If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
- sqeaky 10y ago
  > says that any code we write belongs to the company. I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here > But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager? I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.
  - mancerayder 10y ago

blantonl 10y ago

I view technical interviews that require algorithm solving and coding on a whiteboard as ridiculous. Primarily, because I am deathly afraid of them. And here is why. I own and operate two online businesses in the Radio Communications space that are the de-facto standards for our industry. I've coded both of them from the ground up in PHP/MySQL and manage all the day to day administration of these sites. Our infrastructure is deployed on 20+ servers on AWS, Google Cloud, and some bare metal deployments, for which I manage solely by myself. We have 100's of TB of audio archive storage that is all developed and managed by myself. I've personally tackled the entire stack from the ground up, end to end. I've hired an outside consultant, once, to do graphic design work. I've taught myself titanium accelerator and released a highly successful mobile app for my business for Android and iOS. I've even deployed much of our API using NodeJS! Gasp! I do all security, SEO, sysadmin, scheduling, upgrades, marketing etc. But I'm not a computer scientist. If you asked me to outline a best-case sorting algorithm for x use case my response would be "uhhh... " If you asked me to write out a for loop in PHP on a whiteboard I'd say to myself "uh... where do the semicolons go again?" But I can piece together building blocks from AWS, Stack Overflow, open source projects, multiple SAAS providers. I can also write contracts, executive license agreements with third-parties, develop highly successful and consumable APIs, and manage the financials for a multi-million dollar business. I've also deployed multiple APIs in SOAP, XML, and JSON which form the most successful parts of my business But get me up in front of a technical interview team where the startup is looking for a computer scientist and I'll have a ton of "yea, but..." and probably wouldn't last too long. So when I see these examples of technical interviews in organizations where I know I could add value, but realize their process for evaluating that value could certainly eliminate me very early, that scares the crap out of me. Fortunately, my business has been successful enough that this will never be a scenario I have to face. It still bothers me though.

nilkn 10y ago
It sounds to me like you're more of a technically inclined software executive/business person than a coder. Would you agree or disagree with that statement? Your run-of-the-mill programmer isn't going to be writing any contracts or license agreements and they're certainly not going to be managing any financials. If the interviews consist entirely of whiteboard problems, then they're probably just planning on sticking you onto an agile team where you'll grab tickets off a queue every morning and churn through them at your own pace. It sounds to me like this is quite a bit different from what you've actually been doing. So I guess the point I'm trying to drive at here is that maybe your mistake is identifying yourself as just a software developer when you're actually an executive?

svachalek 10y ago

From a Silicon Valley perspective, I didn't even know that this was something that companies considered not doing. 'Round here, a technical interview is guaranteed, it's more a question of if/when there will be anything else involved in the interview. Also, will it be a mundane technical interview, or more like 6+ hours doing Top-Coder style questions on a whiteboard? It used to be only Microsoft and Google were known for that but now it's practically everyone as far as I can tell.

abecedarius 10y ago
Re: your last sentence, it's been common in my experience for at least the last couple of decades: that is, interviews for most of a working day, including at least one each focused on coding and design. Maybe my experience is unusual, but there were both big companies and startups.

kafkaesq 10y ago

Some useful advice, but something about the overall tone seems a bit off: You are a manager and it’s time to hire a new developer to join your impressive team of A+ players. That's where things started to go of course. You're not an "A+ player", and most of your team aren't "A+ players" either. You're just human beings doing the best you can and (hopefully) trying to improve a bit each day -- like anybody else. No one wants to work with losers. But any (serious) talk of of "We're all A+ players here!" or "I know how to spot A+ players!" is just motivational kool-aid, and ultimately a distraction from the real work you have to do -- including the task of finding the best people you can hire, and who are willing to throw their lot with your cause. Especially when it's quite often the people hired for their seeming "A+" qualities (which they are able to exude in spades) who turn out to be the most toxic, morale-killing members of your (once) impressive team.

jghn 10y ago
When I see job postings or recruiter messages talking about how they only hire The Best I immediately tune out. At best they'll be extremely misguided and delusional. At worst they'll be massive Dbags
jackmott 10y ago
oh you said toxic.
mathattack 10y ago
A+ is also relative to the environment. Performance doesn't always extend across companies. Solo programmers who are an A+ in informal environments struggle in environments that require more inter-programmer coordination. And some A+ specialists sometimes struggle when expected to be generalists, and vice versa. Some big company superstars thrive in small companies, but not all. And some startup superstars would fall apart with the structure of Microsoft and Google.
jasode 10y ago
>, but something about the overall tone seems a bit off: [...] You're not an "A+ player", and most of your team aren't "A+ players" either. I believe you misinterpreted the author's backhanded "compliment" about teams' _self-proclaimed_ "impressive A+ players". His tone is sarcasm if you combine it with the repeated fixation on "Fibonacci" puzzles in the rest of the essay: - quote: , what possible insight does questions like “solve a Fibonacci sequence” + whiteboard + no internet give you to know about a person fit for a development role? - Go Beyond Fibonacci Pen/Paper Tests to Assess Candidates - If you get Fibonacci’ed in your next job interview, perhaps you should look elsewhere? If you are the one doing the Fibonacci’ing, you are doing it wrong. (In other words, if your team bombards candidates with Fibonacci, you of course will think your company consists of A+ players!) His "tone" might have tripped the obvious sarcasm detector more readily if he wrote it to say: "it's time to hire a new developer to join your impressive Project Euler hackathon champions. blah blah blah"

lisper 10y ago

I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you happen to get a word/question you know, you look awesome. If you don't, you don't. (Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss.) I just wish Triplebyte would expand their outreach beyond YC companies.

kafkaesq 10y ago
Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method (1) Better to say you were unable to "remember", rather than a "figure out". No one ever "figures out" things like the Newton-Raphson method over the phone -- not even people like Isaac Newton or Joseph Raphson (substituting whatever comparable level of distraction on had to contend with in those days, absent telephones -- "while ordering a beer at the pub", I guess). (2) The use of this question as a binary hiring filter (mindlessly copy-and-pasted from their rough impression of what ever other company is doing in 2016) was a failure on their side, not yours.
- lisper 10y ago
  Actually, under non-brain-wedgie conditions, I can re-derive Newton-Raphson because I do have a good conceptual grasp of it. (In fact, after I got off the phone, I did it just to convince myself that I could. It took me about five minutes, which is nothing under realistic conditions, but a long time when you're on the phone.) But at the time I had a brain wedgie, and the interviewer just kept pushing and prodding and wouldn't let it go. It was damned annoying. I was sitting there thinking, why are you so fixated on this? It was definitely their loss because the technical problems they were facing were very similar to ones that I had faced (and solved!) in a previous startup (network optimization problems). But I never even got to talk about that. Because of that experience, I now make it point whenever I interview someone to always ask, particularly if they're floundering, "What should I ask you about that will let you show off your strengths?" I don't have any qualms rejecting someone who can't answer that question (and a surprising number of candidates can't).

amorphid 10y ago

When I worked as a technical recruiter, I found that a great way to screen candidates was to explain the "box" I was trying to put them in. I described the work I'd done to research the position, why I was screening for certain criteria, and that ultimately I wanted to get their approval on the summary I had written about them. Being non-technical, this worked better for positions I was experienced recruiting for of course. For example, when recruiting a web developer, I'd start by asking a hiring manager what they wanted. "Get me a full stack Rails developer who knows OO Javascript." Then I'd just drill into why they asked for that until I didn' have manh questions. I'd be able to describe roughly what projects needed attention, how the tech stack helped solve that problem, and ask the candidate to help me sell them as someone who can do that. It wasn't perfect, but it worked better than most recruiting attempts I've experienced so far. Now as a developer with a few years of experience, I feel I have no idea what I am doing, and am winging it at all times :)

pklausler 10y ago

OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community." The companies constitute the community. The community comprises the companies.

tdumitrescu 10y ago
"In addition to its original senses, dating from the 15th century, “to include” and “to consist of ” ( The United States of America comprises 50 states), comprise has had since the late 18th century the meaning “to form or constitute” ( Fifty states comprise the United States of America)." http://www.dictionary.com/browse/comprise http://www.dictionary.com/browse/comprise
- pklausler 10y ago
  This is like legitimatizing incorrect usage of "literally" or "unique" because some people don't know their definitions. It is ambiguous and sloppy to misuse a word as if it means its antonym.
clifanatic 10y ago
And: > as eluded in the following It "alludes" (to), not "eludes". And you and I are both complete jerks for being literate in at least one natural language.
- pklausler 10y ago
  It literally kills me how performant and impactful your code is to the many unique users that comprise the community. :-) Seriously, though, the original attempt at writing actually does mean something -- if the companies do comprise communities somehow (perhaps of users or shareholders), then it makes sense to reference the subset of companies that comprise a particular community. But that's not what the author intended to say -- they just wanted a pompous way to say "all the companies" or (better) "the companies". (And don't get me started about misusing "community" to mean "group" or "collection" or "lame way to make the preceding word plural", as in "the developer community".)

sssilver 10y ago

This is what I don't understand. During technical interviews, why don't we just give the potential employee a laptop and ask them to solve the problem as they would during a regular work day? Why can't they search Stack Overflow, and perhaps reach out to a friend or even a random person on IRC for advice? Isn't this how the real life works? They may not know anything about min heaps, but perhaps a 15 minute research will help them solve the problem better than anyone who actually memorized Cracking the Software Interview by heart? Isn't it better to measure discipline and ability to learn and solve problems instead of measuring existing knowledge?