21 ms·

How To Hire Me (or any other programmer)

• RandallBrown 14y ago
  I can't even begin to describe how worthless I think most coding interviews are. Here's a contrived problem, that will never come up in our work. Now solve it by writing your code by hand without a compiler or any other tools that you would use in real life. I understand that these questions are often about seeing how you think and how you solve problems. Throwing annoyances like writing code on a whiteboard into a high pressure situation doesn't help that at all.
  • niggler 14y ago
    Writing code by hand reveals far more than you give it credit for. Someone omits a semicolon? Bam, conversation about semicolons or ASI. It's not about the fanciest solution. And anyone who does it that way is foolish. It's the purest test of Language facility, and a really good springboard for all kinds of questions. Downvoters: have you actually tried to hire someone?
    • gambler 14y ago
      I didn't downvote, but I disagree and I did try to hire someone. Whiteboard questions are next to useless because they are, essentially, a guessing game. The candidates need to guess what behavior the interviewer wants them to exert. Some interviewers simply use it as an idiot filter, while others want the person to explain their reasoning, wile yet another group is stupid enough to think it's representative of real coding habits of the candidate. If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade. In short, interpretation of whiteboard questions is too damn subjective.
      • lessnonymous 14y ago
        That's bad interviewing, not bad practice. Get rid of the guessing. Make sure you explain to the candidate exactly what you're looking for. I use whiteboard coding .. and it's not to catch you out on semi colons. I even tell my candidates that they can use any language they want or even mix them together or make up their own. What I want to see on the whiteboard is a logical, working solution to a simple problem. And if your brain freezes up because it's an "interview", I'm going to push you in the right direction. Once you have an initial working solution, we're going to chat about how it works. If there are cases where it would fail. What assumptions we've made about input. Maybe we'll (both) even jump over to another whiteboard and write a new version based on our discussion. (Do your eyes light up when we've found a cool optimization??) The only language caveat I use: you can't have a call a function called doitforme() (If you or anyone you know is looking for a senior PHP job in Melbourne.AU, I'm hiring. Hit me up and I'll send you to the ad on Seek)
      • niggler 14y ago
        "others want the person to explain their reasoning," I think far more people use whiteboard questions in that context than the article's author thinks. " If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade." I don't know about your experience, but in my experience candidates actually ask questions if you properly set up the problem and present an inviting atmosphere. And in my experience the best programmers are those that aren't afraid to ask good questions.
    • xyzzyz 14y ago
      Conversation about semicolons? During a job interview? I'm sorry, but this is a waste of time. Why don't you talk about, you know, algorithms? Concurrency? Databases? Testing? Or anything that is more than remotely relevant to the job?
      • niggler 14y ago
        "It's the purest test of Language facility" None of your alternatives "algorithms? Concurrency? Databases? Testing?" really test language facility. Those are important, and they have their place in the interview process, but so does language awareness.
        • lessnonymous 14y ago
          Your whiteboard doesn't have an inbuilt syntax highlighter or linter that points out when I miss a semicolon. It's such a contrived situation that to expect perfectly written code is madness.
          • niggler 14y ago
            While it makes no sense in a language like C, in languages that do have automatic semicolon insertion (like JS) the question is far more interesting
        • nollidge 14y ago
          Personally, I'm vaguely aware that JS does ASI, but rather than waste brain space trying to understand it, I just use semicolons with everything. And anyway, what better test of language facility is there than having the person code something? Or looking at code they've written? Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild.
          • niggler 14y ago
            Putting someone in front of a computer gives them the freedom to google (true story: I used to do a paper exam, and then I found one person was googling when I was in the bathroom and left the guy unattended for a few minutes). "Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild." You don't use a whiteboard when you code? I love them. The whiteboard is a nice tool for doodling and free exploration. I used to print out code and write on it, but I found that process to be much slower than the whiteboard.
    • mgkimsal 14y ago
      I'll go one further. I had an interview several years ago. Talking with the owners, small shop (6 people? 8?). We get to a "let's code something on the white board" segment. Fair enough. "Write me some code that does XYZ" (I honestly don't remember what it was - something basic but not trivial). I took the marker, went to the board, put the marker to the board, then turned around and asked a couple questions. They answered, I sketched out a few lines of code, and that was that. I sat down and one of them said that I was the first person ever to ask a question before writing. Everyone else had started writing, got part way through, then asked for clarification on the ambiguous parts (or worse yet, never realized part of it was up for interpretation). Everyone handles whiteboard tests differently, but it was interesting to me to get that perspective shared with me about asking questions before writing on the board.
      • lessnonymous 14y ago
        I wonder if I interviewed you. I've only ever had one or two people ask for clarification or want more detail about inputs BEFORE they start writing code.
        • bcbrown 14y ago
          I find that surprising. The advice I've gotten from everyone when interviewing at the big tech companies in Seattle is always "make sure you clarify ambiguity before writing any code". I always assume that part of the evaluation is on my ability to resolve ambiguity, and always try to clarify anything I can, sometimes including writing out an example or two and verifying we agree what the expected output should be.
        • mgkimsal 14y ago
          to be sure it wasn't writing code - whiteboarding code/pseudocode. it was a bit of an ego stroke, i think, but given the state of their company at the time, and how they advertised the position, i don't suspect they were getting many sr-level developers applying. i applied mostly cause it was close to home.
  • run4yourlives 14y ago
    The problem is that at least 60% of people that call themselves programmers, and seemingly have no issue getting by HR, can't code fizzbuzz, let alone whatever it is you're working on. Issue one for me as an interviewer, whenever I've needed to be in such a position, was just to figure out whether or not I was talking with a programmer. After that though I tend to agree with you. Beyond demonstrating basic competence - which I think in the future I will look to put into some for of pre-interview screening - code writing tests don't do much. Personally, I've found bringing my current work in with me and talking about different ways of solving the issue seems to work pretty well.
    • Falling3 14y ago
      I've heard various numbers like this thrown around, but I'm having a hard time seeing how it could possibly be that high. Is that figure coming from personal experience? I also struggle with that idea since I'm very capable of programming fizzbuzz and a lot more, but am still having a problem finding a new position.
      • run4yourlives 14y ago
        Is that figure coming from personal experience? Actually, if I went purely on personal experience it would be closer to 90%. I tempered it because I can't believe it could be anywhere that bad. It's sad, but from what I've seen, applicants fall into two major groups, for the most part: 1. People who seem to know how to code (as in, actually use a keyboard) but who don't possess any type of critical thinking skills and can't actually figure out how a piece of code can solve a real world business problem - or even care - unless you tell them exactly how it should work. These people tend to live in big corps and stop coding completely at 4:59 everyday. 2. People with computer science degrees (the more the better) that can think up wonderful and complex solutions to the most basic of problems but can't seem to figure out a syntax error, or understand that a landing page does not require a $40K investment in the latest oracle database software, or that it doesn't matter how wonderful their design is if nobody can figure out how to use it, or that yes, it was more important to have it out last month than it was to make it run 30% faster. Both of these hires are disasters. Unfortunately, the third group, the ones that can understand what a user is saying, design a simple way to achieve the goal, and where appropriate link it to other related features in a meaningful way, are few and far between. Most of them are working in small shops and never have the need to apply for a position via interview, since they get scooped up on reputation before that.
  • Falling3 14y ago
    Not too mention that many of those contrived problems are recycled, so a little studying goes a long way. What exactly does that prove?
    • lessnonymous 14y ago
      It's not a test of your ability to recollect something. It's a conversation. If you're just regurgitating the greatest code solution ever but can't explain why it's so damned good then you're not very impressive. There ARE contrived problems that you can just regurgitate an answer for. (Why are manholes covers round? Because manholes are round duh!) And if anyone asks you one from the lists that are on the interwebs, they're probably just asking because that's What Google Does
• ttrreeww 14y ago
  Cash, lots of cash!
• mooreds 14y ago
  Wow, full of great advice. The biggest one for me is: acknowledge applicants. I've hired and know what a hassle it can be, but use a system, and respond to everyone. Set deadlines, and if you miss them, acknowledge that. Look, this is a possible team member--why would they believe you'll treat them with respect when they are employees if you don't treat them with respect when they aren't? Basically, it's the golden rule. It's not hard!
  • illektr1k 14y ago
    If you give me a few seconds of your time to say thanks, I probably won't mind spending a few minutes staying late to get a task completed.
    • mooreds 14y ago
      Or thinking of a friend who might be a better fit for a position, or trying your product/service, or recommending your product/service, etc. The dividends of being kind and humane are pretty amazing.
• kailuowang 14y ago
  As a coder, I couldn't agree more with the last paragraph (Let Me Code). Other than paring interview, I also like code submission. The company gives you a problem and couple of days and you write the code like you would in a real project. IMO, nothing reveals a developer's coding capability more than that.
• brian_wendt 14y ago
  Wow, can't tell you how much I have seen and experienced the BS that you mentioned. The company I'm with right now may be hiring soon, fwd this article to my boss. Thanks
• Mc_Big_G 14y ago
  Want to get my attention? Tell me you don't use email as a project management tool. Tell me you won't send me 5 emails a day. Tell me you don't want two status updates/meetings per day. Tell me you understand that the shotgun approach to adding features is stupid. Tell me that you don't randomly change features without any kind of data to back up the reason for making that change. Tell me you follow through on promises. Convince me you're not a fucking liar. Tell me you're offering benefits packages commensurate with your senior engineer position. After that, in addition to what OP said, I'll consider responding.
  • zem 14y ago
    honestly, if i got a recruiting mail that emphasised a strong commitment to tool-based programming best-practices (dvcs, review, continuous integration) it would raise my interest in the company significantly.
  • Glyptodon 14y ago
    I find sarcastic naming conventions can help the pain just a little. But yeah, otherwise completely agree.
• ryderm 14y ago
  > If you don’t have genuine passion for where you work and you do the hiring, you’re committing some kind of moral fraud. You might want to see to that. Never really thought about this before, but I totally agree.
  • pekk 14y ago
    Almost everybody is playing some minor role in making someone else a lot of money. That also includes people doing hiring. All this kind of statement will do is make companies extract faked workgasms from their employees every day.
• cliftonmckinney 14y ago
  We've been working to solve this problem for a long time at https://workforpie.com/ https://workforpie.com/. I completely agree with everything OP says, but I'll tell you what the real problem is: time. This is especially true in early stage startups and consultancies, where oftentimes the founders are still building stuff 95% of the time. Recruiters are easy (as are, by the way, the new wave of non-recruiting recruiters like Developer Auction). Pay the man his money, and get a candidate in return. The founder doesn't have to spend time communicating with candidates or really doing any of the stuff OP mentions. That's why a lot of companies still hire recruiters. (Some of the companies) don't care what happens before the viable candidate walks thru the door, they just care that he/she does. It's like buying an iPad. Most of us don't think about, and don't care to think about what it took for that iPad to make it to us. We just care that it did and that it works as advertised. Recruiting: the most important thing most companies don't have time for... There's absolutely a better way, and in the end it's less time-consuming than what most companies do now. But the up front work is harder and more time-consuming. Convincing someone who's time is worth more than his money to adopt the better way is a hard thing to do.
  • Glyptodon 14y ago
    I wonder if it's possible to move from employer to employer getting paid more and more by spending all your time answering questions on Stack Overflow instead of working...
• littlespark 14y ago
  A few years ago I was flown 3 hours first class and put up in a nice hotel for 2 days by a potential employer to interview in a white room with a white board for a few hours. I spoke with their development team which went great. Everyone was awesome and were very helpful. I was then instructed to solve a problem on said white board. After I solved the problem I asked them what they were measuring with this test. Their reply made me question the morals of said company. They wouldn't tell me what the test was for. I asked them why. They said it was for internal review and I didn't need to know. I then asked them why I wasn't allowed to know. They had no definite answer other than that it was for their review. After all was said and done I wished them a good day, thanked them for everything and I walked out. I got a call back a few weeks later informing me that I had another interview in a few days. Long story-short. I turned them down. Something didn't sit right. I told them and they pretty much said, "welp, too bad for you." Now I work at my dream job. I'm very happy I turned them down.
• deleted 14y ago
  [deleted]
• gambler 14y ago
  Thank you for putting this into words. I wanted to write something similar for a long time, but didn't get around to it. Not only these things are frustrating for us as developers, they also decimate IT recruiting for companies. I've seen it from the other side too (while conducting some interviews). It's quite incredible, really. It's like a game. Both sides go through all the usual motions, but gain next to no useful information about each other. In the end it all boils down to unsubstantiated personal impressions, coated with some generic BS that makes it sound "objective". (Before you ask, it's very hard to change interviewing process when you're a part of an established process with a lot of people involved.)
• Glyptodon 14y ago
  I've got to agree with you. I recently started getting serious about changing positions and I've become completely convinced that much of the so-called 'talent shortage' is caused by the job search process, from job listings through to interviews. Every step is unintentionally outrageous in a new way. The first step, finding open positions that are appropriate to your skills and abilities, is overwhelming and impossible. The only way you have any hope of short circuiting it is to have connections with the right people who can open the maze from the inside. Or to become famous in a community. Otherwise, it's a slog of browsing through hundreds of job listings, finding the one in 20 that isn't for .NET or MS-SQL or C# or Oracle, and the 1 in 50 that's not from a recruiter who's listed the same job 5 times, realizing that you aren't qualified because you haven't used the all 4 languages they care about, or maybe because you've only dabbled with some key piece of tech they're convinced you need 3 years experience with, or they won't look at candidates who need to relocate, or you absolutely need to know Red Hat when you've pretty much used Ubuntu derivatives or Arch or whatever. Then you waste time adjusting your resume, and never hear back. Those you do hear back from will often mis-represent themselves and their businesses in an attempt to get hires. In fact, I was a victim of this at my current job. Oh well. All I need to do is start spending all my evenings and weekends on side projects while building an impressive blog to talk about coding and technology. Once it's popular with the Hacker New digerati all I'll need to do is wait... After all, we all know 'talent' is code for 'marketing.'
  • resu_nimda 14y ago
    If my recent experiences are any indication, the secret is to go to hackathons and developer meetups. In the past I've gone through that whole painful and impersonal process you've described. It has actually shocked me how effective this approach has been, and I wasn't even trying (I was just there to hack and learn). You get to have real conversations with people who understand you, and you can easily walk away a couple of those inside connections. Also, the companies that send people to those events (more accurately, those that hire people who will attend of their own volition), seem to be more likely to have sane hiring processes. The two that I have been in talks with have actually made me feel "recruited," and follow most of the points in the article, which is a nice change (and I certainly don't have rockstar status or really any public image).
• meerita 14y ago
  I did an interview 2 week ago. I'm not a programmer, yet, they gladly asked if I code wich I answered yes. What made me go nuts after show them all my work is, fill a questionary? one question was: "Tell us what you understand by "pixel perfect"
• CurtMonash 14y ago
  I love that he just assumes people know the Heinlein quote. ("Specialization is for insects.")
  • ibudiallo 14y ago
    I did not know what it was, and i am glad you brought it up :)
• listaware 14y ago
  The problem is that recruiters carpet email (bomb) programmers, for many of them it's a numbers game. They aren't interested in taking the time to get to know you and frankly I don't expect that they do. The best way, in my opinion, to get a new job is to be proactive and search for it yourself. Contact companies directly, use your network and see how you get on. Recruiters sadly aren't interested making friends.
• eksith 14y ago
  Thank you! That no recruiting recruiter email is such a buzzkill. Even if the company itself looks interesting, just the fact that they sent some brocruiter to flood prospects with emails just makes me question the wisdom of the folks behind the company. I can appreciate a lax attitude at work up to a point, but beyond that, there's no real productivity. It's like the days before the dot com bubble when VCs were dumping cash on a potential product sold on hype. Even if I were to get hired, what's the point if the company folds in a year?
• edw519 14y ago
  How to hire me: 1. Tell me about the 3 biggest things you must accomplish. 2. Tell me why you must accomplish them. 3. Tell me when you must accomplish them by. 4. Tell me how you intend to accomplish them. 5. Tell me what you're already doing to accomplish them. 6. Tell me the role you envision me playing in accomplishing them. 7. Tell me what you expect from me. 8. Put me with some of the key people already working on them. 9. Tell me what you'll do when things change or go wrong. 10. Take me to a Chinese buffet.
  • padolsey 14y ago
    Hmm, 6 & 7 are the same. And I think you meant Thai, not Chinese.
    • mgkimsal 14y ago
      They're almost the same, and it probably wasn't intentional, but they're worded differently enough that you might get some surprising answers from someone if you ask them a few questions apart.
      • lessnonymous 14y ago
        I think they've very different: 6. Architecture, TDD, code 7. 8 hour days, but available in emergencies at night.
      • joshrotenberg 14y ago
        Actually, I think they are pretty different. I've never seen Tom Yum Goong at a Chinese buffet.
  • pasbesoin 14y ago
    A good Chinese buffet. If you can't tell, or don't want to pay for, the difference, well... P.S. (The secret is that good and cost are not in direct correspondence across the population of Chinese buffets.)
    • 14y ago
• fduran 14y ago
  To companies hiring: explain who you are and what you do, what you are looking for and what the hiring process is, extra points for a FAQ. Here's an excellent example: http://www.matasano.com/careers/ http://www.matasano.com/careers/
• csmatt 14y ago
  Excellent! Very well written and expressed. There was an interviewee here today and I heard my boss tell someone to quiz him on big-o notation. I rolled my eyes. Yesterday I had an interview that started off with "Tell me a bit about yourself." No direction as to what the interviewer wanted and, the worst part, as soon as I said I was done, he went right into asking me what the difference between "overloading" and "overriding" is. How many years of experience do I need to have for them to stop asking me things like this? Most of my work lately is in JavaScript and Python. I had trouble answering "What's the difference between an abstract class and an interface?" That doesn't necessarily come up in those languages in a distinct way, so I'm out of practice in my vocabulary. I have neat personal projects with source code on github. Do you really need to screen me with a phone interview?
  • mgkimsal 14y ago
    "How many years of experience do I need to have for them to stop asking me things like this?" It will never stop. "Do you really need to screen me with a phone interview?" Meh... I'm kinda split on that part of the process. I understand the frustration, and too often it's wasted time that doesn't gain anything you couldn't get from the CV itself. If done right, it can tell you if the other party is good at verbal communication, which is an important skill in its own right.
  • deleted 14y ago
    [deleted]
  • chollida1 14y ago
    > Yesterday I had an interview that started off with "Tell me a bit about yourself." To be fair, alot of well meaning interviewers start off that way. It's supposed to be a chance for you to mention all the good things that we may not ask about. In fact that question is so common its a good weeder question; if a person can't blow your socks off with 5 minutes then you can probably predict how the rest of the interview will go. I mean the interviewer basically says to you a golden opportunity to say why they should hire you. If you don't know what to say that pretty much says it all:)
    • 14y ago
• bcoates 14y ago
  What am I supposed to do instead of the cookie-cutter technical interview? Right now I do "Ask any question that starts with the phrase “tell me about a time when”." for most of the interview. I'm trying to give them an opportunity to describe technical things they've done so I can drill into details and suss out if they're exaggerating their skill-set and/or incapable of communication. For perspective, I'm a schlub at my company they grab out of the hallway to give technical interviews, not the founder or a full-time HR guy.
  • csmatt 14y ago
    Just came up with this, but you could ask the interviewee to teach you something programming related that he/she learned recently. That should tell you how well they communicate, can deeply show you their level of experience (and interest), and it doesn't require that they recently revisited their notes from academia. Another option would be to keep notes on programming challenges you hit (and the attempted and final solutions) while doing the job this person is interviewing for and ask the interviewee to walk you through how he/she would go about solving the problem.
    • rhizome 14y ago
      The first one might be funner for people-persons, but I'd say the second approach would give you a much higher degree of confidence in the candidate's skills.
  • larsberg 14y ago
    Completely agree with you - I frequently used to ask experienced candidates questions of the form, "tell me about one very difficult bug or performance issue encountered during your two years working on X." Unfortunately, the number of flat-out liars on resumes is extremely large. Heck, I've even seen resumes from people I worked alongside at Microsoft who now claim to have done things that I did while there. <shrug> Sussing that out is part of the interviewer's job, at least if you care about 1) whether you're hiring a liar 2) the skills that should have been gained if they actually spent two years working on X.
  • logn 14y ago
• stonemetal 14y ago
  I think my ideal way to land a job would be 1) contribute to some open source project. 2) get a beer with the company's dev team at a hackathon. 3) job offer.
• supervillain 14y ago
  Number 1 rule for hiring geeks. - Do not ask for a .doc Microsoft Word document resume Because we might be scrambling and downloading LibreOffice and converting our .latex resume to .doc, if you want to get our attention, ask for TXT, PDF or LaTeX format.
  • ghjm 14y ago
    Unless you're trying to hire geeks who can fit in to a standard office environment without weird platform demands. In which case, insist on .docx.
    • disgruntledphd2 14y ago
      Well, yes and no. I write everything either in LaTeX or markdown these days, but its ridiculously simple to output either of these formats to docx, so normally that's what I do. I'll always send them the PDF version of my resume first though, as good typography can make you look better. If a job requires me to write in Word throughout the day, that's a job I don't want (in fact, writing grant proposals in Word was one of the most frustrating things about working in adeademia).
  • bluedino 14y ago
    To be fair, a lot of recruiting companies or hiring companies only do that because their HR system will only import a .DOC file. The absolute worst place I ever applied to required to you upload a version of your resume in Word format. After you hit submit, the next page wanted a plain text copy. Then, I bullshit you not, the next page was a web form in which they requested you fill out educational background, work history, references. Something you just uploaded twice!
• up_and_up 14y ago
  “Node.js V8 Korean-language backend optimization engineer” Thats hilarious. I recently was job hunting and I ignored prob 20% of position due to that fact alone.
• segmondy 14y ago
  He who is getting hired is at the mercy of the person doing the hiring. That's just how it plays out. If I'm getting hired, I have no say on how a company should conduct their interview process. Their interview process is a window into how they operate, and if it's terrible, I won't want to work for them. i would hate to have a great interview process only to find out that the company is terrible. There is a need for terrible interview processes, so long as it matches the company. The last time I had a bunch of interviews, there was a company I interviewed at, they were so terrible I knew I didn't want to work for them. At the new company, I ran into people who interviewed at same company and refused to work for them, and into two more who use to work for that company and were glad to leave. With that said, the biggest motivation for me is compensation. I don't care what problems they are trying to solve, I don't have to love it. Want me to write in COBOL? Fine, I'll learn it. Want me to work 10hrs a day? Fine, compensate me accordingly. Everything has a price.
  • pekk 14y ago
    I find that people don't respond well to this 'mercenary' attitude. They usually want you to act like you love it, even if it's stupid. They want you to commit long-term, even if you are a temporary contractor. Etc. Every company is like an oversensitive lover who has to be the best ever.
    • segmondy 14y ago
      Of course. I'll feign the love for it.
• signed0 14y ago
  Can someone explain what a "resume wall" is.
  • lessnonymous 14y ago
    A job board has a 'resume wall'. It's like there's a very narrow slot in it you shove your resume through. Then you just hope. And hope. And hope. And then give up because that wall ain't talking. Anyone ever applying to me that sends me a legitimate application WILL get a response. And if you made it to a phone interview you WILL get a phone response even if we're not continuing. It's all about respect. (Plus, I might want to hire you next year for a different role. I'd like it if you thought highly of me. And it's not difficult to be polite) (If you or someone you know is looking for a Senior PHP role in Melbourne.AU, hit me up and I'll point you at the ad on Seek's resume wall :-P)
    • signed0 14y ago
      So it's like a firewall but for resumes?
  • softbuilder 14y ago
    Sorry I left you wondering! A resume wall is a third-party service that sits between applicants and an employer. In order to apply for a job with some companies you have to submit your resume through their service. http://www.jobscore.com/ http://www.jobscore.com/ is an example.
    • signed0 14y ago
      Ah, I was imagining a huge page filled with resumes in the same vein as a wall of text.
  • softbuilder 14y ago
    Sorry I left you wondering! A resume wall is a third-party service that sits between applicants and an employer. In order to apply for a job with some companies you have to submit your resume through their service. http://www.jobscore.com/ http://www.jobscore.com/ is an example.
• VikingCoder 14y ago
  When I'm involved in interviewing someone, one of the interviews will be cookie-cutter. I've seen with my own eyes applicants who had stellar resumes, had great conversations with everyone they talked to... and could not pass a Cookie-Cutter Technical Interview. You may think that it's insulting to have to pass a Cookie-Cutter Technical Interview, but we are not (generally) a Professional group - we don't have a Bar that you have to pass to be considered a professional programmer. When I give something that looked like a Cookie-Cutter Technical Interview, what I'm really assessing is, "How much of my time will I have to spend explaining to this person how to solve programming challenges they'll actually see in the code they'll be working on, and how hard will it be to have that conversation with them." The absolute best candidates were the ones who understood why I gave them the Cookie-Cutter Technical Interview, and related to me their own frustrations with similar oddities in programming... I concluded that they knew how to dig in to programming problems, and solve them on their own. The next best candidates, who I loved to recommend to hire, were the ones who didn't know the answer to my questions (which were purposefully challenging), but who had a great dialog with me. I would encourage them to ask questions, to think out loud, etc. I know this is very, very hard to do in an interview, and I tried as hard as I could to be encouraging, and patient, and give hints when they were needed. And if they responded by asking good questions, stating their assumptions, verbalizing what it was that was difficult for them... I concluded that they would be good at identifying when they were over their head, which I hoped meant they would know when to ask for help, and I could also assess whether they'd be able to explain their problem succinctly. Let me circle back with an anecdote: we had a candidate who looked great on paper, spoke well in all of his other interviews, had lead impressive teams at competitors, and who couldn't solve FizzBuzz. Hiring someone like this is incredibly expensive. Spending one hour of time with a candidate to make sure they can... program... is well worth the time. And I'm sorry, but it's a Buyer's Market. People trying to Sell themselves as good candidates are going to have to put up with one hour of demeaning technical questions. Hopefully they'll turn that hour into a fun discussion about how programming is challenging, and relating their own stories of the oddities of the languages and libraries they use, and why they have certain preferences, etc. - a whole meta level above why ++i is different from i++, and how it's burned them in the past when someone didn't know the difference, etc. You say "Let Me Code, Dammit," but most of your job will be READING code that other people write. I know what the code looks like here, and you don't. If I show you the warts, I can tell how you'll react to them. Do you call ugly code "ugly"? http://www.osnews.com/story/19266/WTFs_m http://www.osnews.com/story/19266/WTFs_m Do you know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result? Do you cringe when you see a %s with an int in the param list? Do you tell me that printf functions are inherently unsafe? How do you recommend making them safer? If you code C++, do you know Boost? Can you spot a new without a delete? Will you tell me to use shared_ptr or auto-ptr, or just use the stack? Typing code is generally having good habits, using safe but powerful libraries and language constructs the right way. But maintaining code is a bit of an art. If you don't agree about what's "ugly" and why, you're probably going to push the body of code in a direction that I call unmaintainable. And there are different strategies in how to make code more maintainable over time, but within one company, we should probably all be pushing roughly in the same direction. "Let Me Code, Damnit" doesn't help me assess that as well as something that looks - at first blush - like a Cooke-Cutter Technical Interview does.
• NateDad 14y ago
  Man I hate getting recruiter emails... I get this vague description of the job for a "hot startup" or "well funded startup" or "established startup"... and I have no idea what they actually make, what the company is about, etc. STARTUPS: STOP USING RECRUITERS! in fact... everyone stop using recruiters. Look on monster.com and dice.com and stack overflow careers and whatever else. I guarantee you, recruiters aren't going to magically find people that don't have their resumes listed there. Anyone who wants a job has their resume listed up there. Find some people that look good, and email them. It's not a full time job, and the quality of candidates you get will more than make up for the lost time in actually reading through resumes. I pay 100x the attention to an email from a real person at a real company who can actually talk about what they do, how they do it, and what I would be expected to do, than I do an email from a recruiter who just wants to place me at whatever company they can get me into. Recruiters don't care about you and they don't care about me. They want a quickie - wham bam, thank you ma'am. Maybe it's just Boston, I don't know, but you look on all the big sites, and it's 95% recruiters. Do you think job applicants are dumb? That they won't do some basic searches to find the job your HR guy posted on dice.com? Which of these do you think I'm more likely to click on? Job #213 from TechRecruiterz.com Full stack engineer for SomeAwesomeStartup.com One is a position at an actual company, one is an advertisement for a Recruiter who doesn't give any identifying information about the job, and doesn't actually care if I'm a match for a job so long as I take A job... any job, so he can get paid.
• nollidge 14y ago
  Also stop with: interviewing based on rote memorization. Yesterday I had a really crappy (third-party!) phone screen assessing my ASP.NET and some general web dev knowledge. Questions included asking me what the stages are in the ASP.NET page life cycle, how to create Web Control in ASP.NET, what elements are new in HTML5, and how to pop up a new window in Javascript. None of which I know off the top of my head (except I know <canvas> is new), each of which I can learn in about 100 milliseconds, and none of which assess skill and intellect. Did you want a skilled programmer, or someone who memorized their Foobar Enterprise Framework cheat sheet? Because you're only interviewing for one of those.
  • taytus 14y ago
    I think that's the problem, they don't know what they want.
  • rhizome 14y ago
    I recently got the question, "explains what happens when you type a URL into a browser."
    • nollidge 14y ago
      Ugh. See, and if my mom asked that, I know she's looking for a barebones high-level explanation that she can grok, so I can be a bit fuzzy. But when an interviewer asks me that? I can't tell if they're just screening out the dummies, or if they actually want me to talk about packets and handshakes and DNS protocol.
    • willismichael 14y ago
      Typing it in isn't really that interesting... but when you submit, now that's when the magic happens.
      • rhizome 14y ago
        Believe me, that answer was the first thing that came to mind. "With or without the enter key?"
• michaelochurch 14y ago
  This is a great post. One issue here is that a (possibly deeply-layered) "neural network" model applies to many industrial processes, which means that there are a lot of interacting components, but in many of those the input/output relationship is almost binary-- a logistic curve close to a step function. Most companies have absolutely no need for exceptional people. They're looking for a process that can hire good-enough people at controllable volume. They have a mission to be fulfilled and want it done well enough. There's nothing wrong with that; it's just that most of them have no idea how to execute. They might over-hire and reject mediocre-but-good-enough people. They might come up with insane purple squirrel queries or HR-ish hiring policies ("we only hire NoSQL developers; it says here that you use Scala"). They might hire mediocrities (when they actually need strong people) and compensate by hiring a lot of them, which we know doesn't work. There's also a deep, bilateral trust sparsity in the economy. Most employers aren't doing interesting work and have shit cultures. Most programmers haven't been well-trained or motivated to grow and are incompetent. It goes both ways. I'm just as elitist and network-driven in terms of the companies I'm willing to consider credibile as they are in their willingness to fairly evaluate candidates. I can't come up with a good way to overcome this in the general case, but the OP gives a strong guide for recruiters to overcome trust sparsity and show capable developers (who can be selective) that they're not actually clueless.
• rhizome 14y ago
  "Be Interesting" As a corollary to this, I would advise companies to be OK with not being interesting. Not every business is exotic and innovative. If you aren't actually interesting, don't try to portray the company so. "Rockstars, etc...." This has been hashed over so many times, especially here on HN, but I do want to point out that there is a YC company (that has been trying to hire for A LONG TIME, here and on SF Craigslist) who uses this kind of lingo. In fact, they were the YC company that implied to me that the YC partners don't actually try to control their companies too much. This company will be allowed to create their own business (or not) via their own philosophy, which is a point in YC's favor.
  • stanleydrew 14y ago
    So just be yourself as a company then right? Of course put your best face forward, but don't lie. If you're 5'4" and balding it's going to be apparent to anybody you meet, so there's no point in lying on your dating profile. The same should apply to recruiting. Both are a "dating game."
• greenyoda 14y ago
  Very good article. I have just one thing to add: If you don't tell me a salary range up front, I have absolutely no incentive to even talk to you. I have no desire to go through an entire interview process just so I can find out that you'll be offering me a salary that's $100,000 less than what I'm currently making. It would be a huge waste of both your time and mine.
• renegadedev 14y ago
  I just got an email from a recruiter who's looking for a SQL DBA. The applicant must know (note the lack of mention of DBA skills): Java Script, jQuery, CHTML, CSS I also frequently get asked by recruiters "how much do you make?". How is my current salary any of their business?
  • blackdogie 14y ago
    Personally I don't think that recruiters are worth paying any attention to. At least not in the cookie cutter version. If they want to get in touch then that's cool, but if it's a generic email it will get labelled as SPAM.
• ruswick 14y ago
  I concur with the point about the ridiculous "rockstar" terminology. It's ambiguous and non-descriptive. However, the titles that truly irk me are "code artisans" and any variants thereof. I've seen this in use several times in the past few months, and it is the pinnacle of absurdity.
• electrotype 14y ago
  There is one main point that will help me want to work for you : - Show me your business doesn't considere developers as resources that are easy to replace. Because this is not true. I've never seen a successful project built by thousands and thousands of inexperimented or bad developers.
• jdileo 14y ago
  Hi Matt: I've been a sales/biz dev entrepreneur & founder for 15 years. Bootstrapped my last co. to $7-fig/yr net (this was non-tech, east coast). Recently moved to bay area to build tech startup grounded in sector I've lived & breathed for many years. Startup aims to tackle pain-points in enterprise relocation, $50+B market. I have a MVP & have been prospecting/selling 12-15 hrs a day. In 3 weeks since launch I have 2 large companies that have agreed to to direct significant percent of their business to us., this=profitability. I seek to recruit a talented developer that has product design experience as well as leadership & network capability to become VP product. I'm attending meetups, contributing where able and working hard to connect to SV ecosystem. But developers still seem to see me as the "biz guy" enemy.
• anonfunction 14y ago
  The biggest thing I took away from this is that you should treat potential employees like employees.
• ghjm 14y ago
  Ok, so here's the problem. None of the recommendations in this are actually actionable. Consider: - Be Interesting Well, the company either is or it isn't. If you're an auto parts distributor who needs to convert your application from Cobol on AIX to ASP.NET on Windows, then well, you aren't really very interesting. And there's not one thing the recruiter can possibly do to change that. * Care Perhaps you genuinely care, but what if you don't? The recruiter is human too. Maybe they just want to do their job and go home. You can't decide to genuinely care. You either already do, or not. And we're saying they absolutely must not pretend to care. So ... the only remaining option is not caring. * Acknowledge Applicants I don't think Matt appreciates the sheer volume of resumés that come in for an advertised position. I know some HR departments that insist on sending an acknowledgement for every received application, and they spend a lot of man-hours on it, and are constantly having to defend this practice to executives. And honestly, why does the typical badly-formatted, ungrammatical resumé actually deserve a response, anyway? Matt may be a special unique snowflake, but trust me, all those other people aren't. * Get to Know Programmers You can't do this without getting to know programming. And the whole point of specialization of labor is that you shouldn't have to. You can hire a doctor, lawyer or plumber while knowing nothing about plumbing, doctoring or lawyering. Why should it be different for programmers? As a profession, why should the rest of the world bow to our desires, instead of us creating a better product for them to buy? * Let Me Code, Dammit This is the one piece of good advice. The best way to interview in any field is to engage the applicant in job-related task behaviors and observe the results. With programming, we're lucky that this happens to be pretty easy. But I don't understand how this squares with the earlier rejection of having the applicant code a Fibonacci function.
• coditor 14y ago
  I've said all of this many times on my blog as well. Sadly the only people who read my blog and live on this site are the hirees. The hirers never visit and remain ignorant.
• tibbon 14y ago
  Another thing that bothers me about some positions: - 5-10 years experience with all of the following: PHP, Python, .NET, Javascript, C++, Perl, Erlang, Haskell, Ruby, IronPython, Lua, etc... Seriously. Please god tell me you don't actually use ALL of those all of the time.
• gavinflud 14y ago
  This is an excellent post. I'm soon-to-be fresh out of university and the company I'm joining had a hiring process very similar to what you've described. They were in constant contact throughout the process, sold themselves very well and - although they did carry out a cookie-cutter technical interview - it actually made for an interesting hour where I was able to solve their pretty simple sample problem and we ended up going off on a tangent talking about how to optimize the interview process. What differentiated them from countless others was that personal touch. I always felt like they wanted me on board and they were able to sell themselves and their culture very well.
• michaelpinto 14y ago
  Having survived the first dot.com crash reading stuff like this always makes my "smells like a bubble" detector go off. Although to be fair I don't really sense that in NYC, so maybe this is more a reflection of silicon valley.
• jwwest 14y ago
  > Assuming I Am Only The Last Thing I Was I can't tell you how much this annoys me. I've been programming professionally for over a decade now, and I've done a lot of things: C#, PHP, PERL, Ruby, Python, Javascript, etc, etc, etc. Taking a look at my resume, you would assume a rational and logical person would say: "oh, this guy's been in it a while, he could probably pick up anything" -- but this rarely happens. I get it, you need deep technical expertise in X framework working with Y platform. Actually, no, I don't get it because a decent developer will pick up and run with anything you hand them, regardless of what they've worked on professionally in the past. > Care Passion != Success. Look, I know you're oozing passion for building Twitter for Barnyard Animals, but don't expect me to show enthusiasm for your niche. Honestly, I've probably never heard of it before now. Maybe in time I'd come to really understand it and be interested in it, but right now I'm more interested in the scaling issues and optimizing my productivity through my tools.
• freework 14y ago
  My best interview advice is this: Don't ask questions to judge, ask to learn. A lot of interviewers have an interview process that is mainly designed to eliminate candidates. Therefore, the process contains interviewers asking "fake questions" that are designed to trip up candidates and eliminate them. An example is a question like "How would you design a database engine". If I really had to build a database engine, the context and details of that situation would dictate how this database system should be approached. Instead you should ask questions to learn. If you ask me what a cache is, you better be asking me because you don't know what a cache is. If thats the case, I'd love to explain it to you, because I like teaching people things. Its very awkward to explain something to somebody that obviously knows that concept very well. When you ask questions like that, you end up subconsciously comparing candidates by their explanation of cache matching up with how you would describe cache. In other words, this process favors people who think the same. A team full of people who all think the same is a company that has many weaknesses. A strong company has people who approach problems differently. You need people who approach life differently. Diversity is extremely important, and asking fake questions during interviews leads to less diversity.
  • xtreme 14y ago
    I see three problems with this: 1. It would pretty difficult to judge whether you are correct or not 2. This approach favors candidates with a flair for speaking but may not have good programming ability 3. The interviewer would probably run out of concepts that he can reasonably expect the interviewee to explain.
• corwinstephen 14y ago
  Not that this information isn't good or anything, but how many "the hiring process is whack" posts are there going to be on Hackernews before the message resounds?
• graycat 14y ago
  Interesting thread. The tread is interesting to me because I'm a sole founder of a Web 2.0 startup with some relatively technical internals (in the server farm only), and have done all the work from the beginning to the present. If the startup works, then I will have to hire. But, for what is in the OP and this thread, I have a different view. Below I discuss the differences in three parts, software development environment, teams, and qualifications and add some comments at the end. Software Development Environment. I've been around computing for a long time, but I skipped over the big growth in Unix/Linux and C++. Instead my more serious software development has been on IBM mainframes and now on Windows with Visual Basic .NET, ASP.NET, ADO.NET, SQL Server, etc. Why Visual Basic .NET? It seems like the nicest way to exploit Windows, the Microsoft Common Language Runtime (CLR), and the .NET Framework (that is, the enormous collection of classes), and work with the rest of the Microsoft software for TCP/IP, SQL Server, IIS, etc. The syntax of C# is too close to that of C/C++ and, thus, is deliberately 'idiosyncratic' and 'tricky' and, thus, an obstacle and error prone; the Visual Basic .NET syntax is much easier to take. The idea of 'immutable' strings, each with maximum length 2 GB or some such, along with the ideas in 'managed code' and memory management seem terrific for my applications level programming. I've always typed code into just a text editor, one that permits writing good macros, the most capable I had access to, done operations with just command line scripts, never used an 'integrated development environment' (IDE), and rarely used any interactive debugging. Instead, I just put some checks into the code, have the code write a lot of tracing data, and then look at it with a text editor. Always worked so far! For my Visual Basic .NET code for my site's Web pages, I'm just typing into ASP.NET without any explicit use of model–view–controller (MVC) or other Web site 'framework', whatever such a 'framework' is! Once I looked at MVC for a few minutes, and it seemed that some of my code is similar! I looked at Visual Studio, didn't like the documentation or the many small 'panels' all in one window (instead of the 10-20 windows I use), never saw a description of what they meant by 'dockable', and concluded that my favorite text editor and some command line scripts were more productive. I've been surprised and pleased by how well Visual Basic .NET works for Web page development on Microsoft's Internet Information Server (ISS) -- e.g., just have a Web browser ask for the page using the loop-back IP address, and IIS kicks off the Visual Basic compiler, apparently for anything and everything on the site that needs compiling, does any 'link editing' on the fly or some such, and at the bottom of the Web page gives, based on options in the Web page code, lots of details on the compiling. Generally, if there are no error messages, then the Web page displays. It's nice. Microsoft should explain it someplace! So, I begin to conclude that the main things a programmer needs are good versions of a text editor, scripting language, programming language, and documentation on these and the libraries, APIs, etc. Teams. I've done some software development in teams and supervised some software development. In both cases, the work went well with no attention at all to formal methodology, 'team tools', 'repositories', etc. In one case, I was one of a team of three researchers in artificial intelligence at IBM's Watson lab at Yorktown Heights, and we did research, published papers, designed and developed software, and our work resulted in two, shipped, commercial IBM Program Products, IBM's highest quality software product category. For one of these two the code that was shipped was essentially just what we wrote. In the other case, we did all the work except the actual code was typed in by an outside company in Taiwan. In addition to our three researchers, and we all wrote code, we had several programmers. Really, it was a team of seven people. For a project that small, the lack of formality worked fine. Once I was the Chair of a computing committee for an academic institution and, thus, in part a supervisor of a computing group that served the institution. We had several programmers, former students, with no formality at all, and the work was terrific. I've never seen any formal approach to code 'building', testing, test 'buckets', 'quality assurance', etc., yet we had no problems. So, I begin to conclude that for groups as small as seven, with a good leader and some good people, can do well with no formality at all. None. Zip, zilch, zero. Programmer Qualifications. The people I've worked with have nearly always been plenty bright, knew a lot, learned quickly, worked hard, etc. And these people were selected with none of the interviewing ideas in this thread. Mostly the people were college graduates, but not all; some of the people had technical Ph.D. degrees; some were graduate students in technical programs and part time. It appeared that generally quite sufficient (but usually more than necessary) qualifications were a Ph.D. in pure/applied math or theoretical/experimental physics, some good computer usage experience, and some scientific/engineering programming in two or more languages would be fine. Then such a person could pick up Knuth's TACP, Ullman on database or compiling, Sedgewick on algorithms, artificial intelligence, 'machine learning', the elementary Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein, 'Introduction to Algorithms, Second Edition', The MIT Press Cambridge. etc. and zip through like reading a novel. Gee, Knuth's TACP has a nice list of binomial and combinatorial formulas, good coverage of heap sort and the Gleason bound, B-trees, AVL trees, and random number generation, and more that is useful ..., well, maybe if I got out my copies I could find some more! Yes, he has a very clever presentation of the fast Fourier transform, but the more specialized sources, especially for signal processing, are better even if less clever. Gee, guys, there are more tough technical ideas in several cases of just 30 pages in W. Rudin's books than in some stacks of computer science texts. For real technical creativity, R. Bland's proof in linear programming totally blows the doors off anything I've seen in Bachelor's or Master's level computer science or suspect is there or saw in technical talks at Yorktown Heights. Yes there are some other hiring criteria, but they are mostly by 'exception'. E.g., if a person clearly has a personality problem that keeps them from working effectively alone or with others, then can't have that person around. I begin to conclude that software is still a relatively simple subject, and for hiring the sufficient conditions I gave are fine. For more: More. If I hire someone with a lot of 'skills' in tools and procedures for team developed software and those skills seem to be worthwhile, then that person could be helpful and welcome! Compensation. For salary, guys, look, the first thing to check is, does the job pay well enough to let you buy a house and support a family in nice conditions? Large Software Projects. Next, I confess: I've never tried to debug or modify a 500 KLOC 'code base' developed over 10 years by 20 programmers none of who are still there with no documentation except some sparse comments in the code. My view is that such code is not a programming problem but a management problem: To fix the problem, need a lot of time, money, and people. Sorry 'bout that! Training. I've never seen anything very useful in formal training. Have to accept that major fractions of programmer time go to working through bad documentation, learning new material, migrating to newer tools, writing little tools, etc. For a 'training budget', no: Just budget the time along with everything else; for travel and fees for formal training sessions, sure, but likely mostly the training should be in-house without flying across the country, business class, limo service, fancy hotel, rental car, big per diem, big training fees, etc. Security. In some organizations, have to take security very seriously. Might have to hire some outside firms with tools, procedures, tests, etc. Okay, then do that. JavaScript. So far have yet to write a single line of JavaScript. But so far Microsoft is writing about 300 KB of it for me, and I have to suspect that I could cut that down by a lot and, thus, save on bandwidth. So, if I have to write some JavaScript, then I will. That is, get some materials and/or 'training', learn some JavaScript, and write some. Do something really complicated with JavaScript? I want to try never to do that! And I would generalize that approach to JavaScript to nearly everything else in computing, for me and any people I hire. Writing. Once someone in my company has spent a lot of time and, thus, company funds, learning or doing something that has some importance, then I will want them to document what they learned or did so that the company can have the work as a continually valuable 'asset'. So, net, one of the better abilities I want is the ability to write good technical material. Being able to give a good technical talk would also help. Net. Many organizations want a lot of detailed 'skills' that I get by without and, thus, won't require in people I hire. I prefer JIT skills -- learn the stuff as needed.
• scardine 14y ago
  "Micro Positions" are a known scheme to hire foreign workers under H-1B visas. The employer must, prior to filing the H-1B petition, take good-faith steps to recruit US workers for the position for which the H-1B worker is sought. For example, if you want to hire a Brazilian, publish a position for a "Python Portuguese-language backend optimization engineer". The Portuguese-language part is just to assure no US worker is qualified.
• zobzu 14y ago
  I'm not a recruiter but like everyone i do interview people from time to time. While I agree with TFA, of course, i think a few "quiz questions" are often necessary. While you can check if someone can code on his github/whatever page without asking any question, you don't just want to make them want to work for you. You also need to screen them enough to figure out if.. they're going to be able to work for you. They're not all well known. There's new fresh people graduating all the time, and even if there's people that aren't just well-known (the vast majority!) So, til there's better, i always have 25% of "quiz" questions, which are all 100% technical and all require either logic, either knowledge. (then 50% of discussion of the stuff there's to do, and 25% for candidate's questions). THEN if there's interest there's real interviews as in, come to the office 'n let's chat about stuff you'd like to do. Not before.
• lucian303 14y ago
  "Ask people to write code on paper or a whiteboard Ask someone to code a fibonacci function" Absolutely. Some try to do this on the phone. What a waste of time.
• wfunction 14y ago
  I beg to differ on the whiteboard part. Asking someone to code on a whiteboard is a perfectly legitimate way of seeing if they can code a few lines (with minor mistakes if need be) without needing a compiler to guide them through each step.
• ballostix 14y ago
  mindcrime is a total cunt