13 ms·

Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hir

• heartsucker 10y ago
  I've had the same experience. Someone listed 2 years Scala experience on a resume, but couldn't explain Unit, None, null, and Nothing to me. Or the guy this week who had several years of ops experience and when asked "how can you tell what indexes are being used in a SQL query" didn't even know about EXPLAIN. Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map implementation," because sometimes "you put a thing in the map and then get it back out later" is good enough for 99% of startup engineering tasks. Somewhere out there is a sweet middle ground, but it seems not one agrees where it really is.
  • coredog64 10y ago
    That latter bit in the Amazon interview really pissed me off. They saw my resume, and it didn't include a degree in CS. They had a cheap opportunity to ask me questions about data structures (phone interview). So why the hell do they wait until the "fly me across the country" interview to ask questions about implementations of priority queue?
  • Chris2048 10y ago
    To be honest though, just because you can get by without knowing how hash maps are implemented, doesn't mean it isn't useful to know - and if another candidate does know, they would sooner hire them. Further, they may be looking for factors that correlates with other, hard-to-measure factors. Even such as reading a "common interview questions" book - it correlates with focused pragmatism...
    • heartsucker 10y ago
      I'm not saying it's not useful to know or that having that knowledge might make someone a better candidate, but it seems like that alone shouldn't be reason enough to reject someone. And I disagree that looking up the answers to common interview questions is focused pragmatism. I don't bother, even with the knowledge that it would help me get a job. I spend my time working on side projects or learning practical things. I think I will never in my life have implement a hash map, and that knowing it's all O(1) operations is sufficient. But also I guess I don't want to work for a company that is interested in my ability to jump through hoops. (shrug)
• CSMastermind 10y ago
  I honestly can't think of a time I lied during a job interview. Am I doing it wrong?
  • Clubber 10y ago
    It's usually over-promoting a skill on your resume. It might not be nefarious or intentional, but it's a communications gap. What you mean by "experience in," and what the manager wants you to mean by "experience in," are two totally different things. Example, if you read a SQL book a couple of years ago, you would say you have experience in SQL. You've forgotten most of it, but you are familiar. If a manager reads that same thing, he or she might think, "Oh, proficient in CRUD queries but not overly complex ones." Manager gives you a quiz on SQL, but since you don't have Google in front of you, you flail because you haven't messed with it in a long time. It's not really lying, it's just a communications gap. I'm not saying there isn't outright misrepresentation of skills, but most of the time it isn't intentional.
    • hanginghyena 10y ago
      With a truly technical manager, this is honestly one of the fastest ways to torpedo your credibility. Anything listed on your resume is fair game for questions, especially if you claim it as a skill. "Reading a book" is not a skill; reading a book and using the contents in that book for several real world projects probably qualifies. Especially if you can describe what you did in detail. Harsh reality: I value everything in that section of the resume at the value of the weakest component that I find. So when we discover that your knowledge of SQL is reading a few tutorials on w3schools ten years ago, I rate EVERYTHING ELSE in that section at the same level (ouch!). So the safe way to play this is don't list anything that you can't hold a 5 - 10 minute conversation about and explain at least the basics of how the technology works, citing real examples of where you used it (paid or unpaid, I don't care about that, as long as you're clear about what you did). Yeah. Most of your competitors won't do this. They'll fill out the bottom of their resume with junk. But um... there's a reason they're still looking.... Incidentally my own (technical) resume has exactly two lines of IT skills... each of which I can do a 30+ min speech on. Never had a problem in that area during an interview...
• MrLeftHand 10y ago
  Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying. The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, done that). "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN. Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything. The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow. That's the sad truth about software development. Well one of them at least.
  • jsudhams 10y ago
    Agree with you MrLefHand, But would it not be responsibility of sql programmer to keep himself update? even if it is not possible in company. Like we never get to touch AD in any company because most of them already have it setup but we still go and test in VM with eval editions and such?
    • MrLeftHand 10y ago
      Yes you can and you should. Sometimes it's hard to get ahead to learn stuff by yourself when you have a mind numbing job to go to. But then maybe the person doesn't belong in to the world of software development. Another problem is, when you learn something outside of work it wont be enough, because they want "commercial" experience. Like when they are hiring mobile developers and ask: "do you have any successful apps on the store?" If I would have any successful apps on the store would I be here doing this interview with you?
    • lmm 10y ago
      Sometimes you don't know what you don't know. I was completely torn apart the first time I was interviewed for a Scala position, because the guy didn't believe I could possibly have spent three months doing Scala professionally and didn't know basic List methods like fold (we'd been avoiding using Scala collections because we knew the migration was coming, and had just been writing Scala with the Java collections).
• deleted 10y ago
  [deleted]
• Waterluvian 10y ago
  I hear you. I'm terrified by the kinds of interviews that want programming trivia. In the last three years I've never had to code a binary search tree. But I should be able to show you I'm very comfortable with Python.
  • efaref 10y ago
    How about you show me how comfortable you are with python by coding up a quick binary tree implementation?
  • strickjb9 10y ago
    As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it. Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.
    • huehehue 10y ago
      That's usually not how it works though. You're more likely to be laughed out of the room for asking such a silly question, despite the fact the (presumably technical) interviewer could do no better without the teacher's copy in front of them. An aside, but I think interviews like this should allow Internet connections. Give the candidate a minute to look something up and digest it in their own way. It should be obvious whether they'll get the concept or just recite the Wikipedia definition. Just as important is how they do their research, and how they draw connections between foreign and familiar concepts given a blueprint of the former.
    • cableshaft 10y ago
      They might not be trivia, but they're not presented in the same manner as someone would be doing on the job and/or the candidate isn't given the same access to tools they normally have when working and/or there's an 'on the spot' requirement to answer the question. I don't store everything in my head anymore. I have a general understanding of the concept and a mental pointer in the form of the search term to put in google to refresh how to implement the thing. I have to implement 10-20 concepts across 5-10 languages or APIs or technologies every single day usually, my brain doesn't work like a database where every record that's inserted is there permanently until I update or delete it. The stuff I'm not using regularly gets fuzzier and fuzzier and goes back to "general concept mode" if I'm not actively using it. So when someone asks me to write a full iOS app during an interview when I've been making Microsoft business apps for the past year, even though I've written and released multiple full iOS apps at previous jobs, I can't just sit down and produce a perfectly working app like a robot, especially if I didn't have much time to prepare for the interview (that recruiter contacted me three days earlier and didn't tell me he set up an interview until 8pm the night before). With technical questions it's even worse, because I could have been spending days and days refreshing my knowledge but you happen to choose one of the things I didn't think to refresh my brain on. And so I waffle on the answer and you go "oooh, looks like he doesn't know anything". No, I've got a full decade of making apps and software, in lead roles, in multiple industries with a bunch of different technologies. I know plenty. I just didn't have that question fresh in my head. Then you pass, and lose out on someone you would have benefited from greatly in favor of the recent grad student that hasn't made anything but toy programs yet got tested on all those concepts within the past six months so it's fresh in their heads.
• singingfish 10y ago
  I've recently got into the interviewing for devs game. Now we're a perl fairly specialised shop, and we only hire experienced people so that makes things relatively easy (candidates need to demonstrate a depth of knowledge, and . The pool of people around is relatively shallow too. We don't actually need to ask people technically detailed questions about specific algorithms. We have a conversation. From that conversation you can learn a lot. How do you do async programming (answer you structure the code to make it easy for it to scale)? What experience do you have with RDBMSs? (we're looking for higher level answers). What's the difference between jquery and prototype? How do you deal with conflict? What's the most important thing about coding style? And you let the conversation flow depending on what they say and how they answer the questions.
  • _asummers 10y ago
    One of my favorite questions is asking people their least favorite and favorite languages then asking people to give one of their favorite features in the least favorite language, and least favorite features in their favorite language. Shows that they've actually spent time thinking about their tools. You get a surprising amount of insight from it, depending on the answer.
    • maxerickson 10y ago
      This question would throw me for a loop because I don't have anything I think of as my least favorite language. I could pretend that Python was my favorite language, but that's more that I'm comfortable with it than any sort of actual feeling that I should prefer it over others. That is, I use it out of inertia and familiarity, not out of some sense that I've found something.
      • _asummers 10y ago
        See, but that's a reasonable answer. I might take that and pivot to like "if you had to design an ideal language, drawing from the strengths of the ones you've worked with, what would you think most important?". The idea is to get you talking about things you've worked with to show familiarity and critical thought about your tools.
• IanCal 10y ago
  I've been on the interviewer side in the past when this was the setup: People are given a basic coding challenge. On the level of "parse roman numerals" or similar with some tests, standard kind of basic things that rosetta code will list implementations of in every possible language. The code was to be written in any language the person wanted. This was not timed, and was to be done at home. 50%, easily, didn't work. Many did not compile, or were totally incomplete. One was a broken implementation in C# submitted as a single function pasted inside a word document. Only one person out of I think 20 sent a zipped copy of all the code, a short instruction of how to actually run it, and included some tests. After that, I started to understand just why these kind of little programming tasks were given. > And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict. Hah. I've had someone who didn't know the difference between local and global variables trying to come in as a fairly high rate contractor.
• sokoloff 10y ago
  > in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard That's one of the most inadvertently funny things I've read on news.yc in a long time!
• deleted 10y ago
  [deleted]
• seanwilson 10y ago
  > As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. Yeah, many of these kinds of blog posts strike me as being out of touch with what hiring is like. So don't ask about algorithms, don't ask to write code, don't ask to use a whiteboard and ignore if the candidate can't handle the pressure of a standard interview? How are you expected to weed out unsuitable candidates?
  • woud420 10y ago
    It's quite easy, just use bias. (No, not really)
  • ubernostrum 10y ago
    How are you expected to weed out unsuitable candidates? Here are my rules: 1. Phone screen coding is optional. If someone is vouched for by a reliable source, you don't fizzbuzz them. 2. The phone-screen question, if used, should not presume any type of formal university CS education (i.e., asking for algorithm regurgitation is right out). Not every good programmer has a university CS degree (many of the best don't), and even among those who do, the longer they've been out of school the less of that stuff they'll remember. Their brain has long since paged the CS 101 algorithms out or even cleared them entirely to make room for the working set of things that actually turned out to be relevant to coding for a living. 3. Good phone-screen questions have solutions in under ten lines of code. Ideal phone-screen questions have solutions in under five, or may even be one-liners in your company's preferred programming language. 4. Once a candidate is past the phone screen, or once you've decided they can skip it, you get to ask them exactly one more question that involves writing code. 5. The final code question must be realistic both as a problem and as a set of conditions. Your employees write solutions to real problems, in editors or IDEs, so to find out whether someone could succeed as your employee that's what you should test. Being able/unable to solve contrived problems by coding on a whiteboard is a completely unrelated skill and does not indicate or rule out ability to solve real problems in an editor or an IDE. 6. The final code question should be a "homework", designed to take a baseline-qualified candidate approximately an hour or two to complete, but to be completed at the candidate's leisure (i.e., set a deadline a day or two after you give them the problem). They should not have to solve it perfectly in 20 minutes on a whiteboard. They should be able to use common/standard libraries. They should be able to use Google or look things up in books they have lying around. They should be able to try running their code and correct errors that turn up when they do. They should be able to do those things because those are job-relevant skills and job-relevant skills are the things you want to test, remember? 7. The interview portion of the final code question should be a collaborative review of the code, discussing design decisions, tradeoffs, and areas where it could be improved/expanded/etc. Being able to present, discuss and review code with others is a job-relevant skill. 8. In a real dev job, at most 15-20% of a developer's time is spent in directly writing code to accomplish a task. The remaining 80-85% is spent in determining requirements, researching approaches to problems, making design decisions, soliciting feedback from peers, reviewing existing or new-but-peer-written code, writing tests, writing documentation, and performing all the other mental and bureaucratic tasks which accompany the act of coding. In light of which, time spent directly writing code to solve interview questions is not permitted to exceed 15-20% of the total time taken by the interview process. The remaining 80-85% should be focused on getting to know the candidate well enough to determine how they'll do with the tasks that will take up 80-85% of their time on the actual job. I've done my best to phrase this politely. It's based on (as of this point) 15 years of getting paid to write code and having been on both sides of the interview at multiple companies and for multiple positions at multiple points in that time span. But if it helps, feel free to put it in terms the typical tech interviewer is familiar with and think of this as a sort of fizzbuzz for interviewers/managers: anyone who can't figure out how to implement these things may not be qualified to be an interviewer or manager.
• mattzito 10y ago
  At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to: - read that file in - store it in some sort of data structure - allow users to run commands to retrieve movie titles based on name, release year, etc. Command-line was totally fine, you had access to the Internet, and as much time as you wanted. At least 50% of people couldn't do it. One candidate spent hours staring at the screen before slipping out with a note left behind, "I apologize for wasting your time"
  • tayo42 10y ago
    How would you do this without basically writing your own database from scratch?
    • tetromino_ 10y ago
      By implementing only that 1% of a real database's functionality that this task requires. Consider: you have only one table, no updates or deletes or transactions, fixed schema, and very, very simple queries. So it's just a matter of parsing the CSV into some native data structure in your favorite language and then computing sort indices of the columns by which rows might be queried.
      • infinite8s 10y ago
        And sadly you don't even need to create sort indices. Just reading the data into a list of tuples and a few list comprehensions would provide all the querying needed (it wouldn't be efficient but most candidates can't even get that far)
    • cloakandswagger 10y ago
      Store it in memory? I doubt the amount of data they provided for a test problem was so tremendous that it required a database. In itself this is a good (dis)qualifier; if I give someone a problem and tell them the data will never exceed 10k rows, I expect them to be practical and not waste time setting up a database.
• saiya-jin 10y ago
  > Everyone lies, sorry. I have an issue with this - i don't lie. Not in CV, not in interviews. We're not managers, we cannot talk our way out of tasks given to us, and most of us who are worth at least a pinch of salt are not desperate to get job X. But I understand that if your experience is as it is, this is probably correct approach.
  • marcosdumay 10y ago
    > I have an issue with this - i don't lie. Well, I don't either. That makes it much better for me that people use a test that separates liars from honest people. Yes, the phrasing is bad, but it is a very understandable hyperbole.
• fweespeech 10y ago
  > Hiring Manager Perspective: Everyone lies, sorry. Yeah, and honestly, that includes hiring managers. I've rejected offers because the hiring managers level of deception exceeded my tolerance for bullshit. > About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Yes, I don't remember the syntax from 5+ languages well enough to write it in on a whiteboard. Yet somehow, I'm able to use 3-4 on a daily basis to handle millions of dollars in transactions. So...I really think whiteboards, once again, are really the wrong way to test people. Code samples and discussing them work much, much better for everyone. I may be biased...whiteboards, I get rejected 50% of the time. I also find, honestly, that if I ask two technical questions of the people giving the whiteboard test of similar difficulty...they rarely can answer more than 1 acceptably so I've found the failure rate to be pretty consistent with the rate they fail me. Code samples? I get offers 90% of the time.
  • SilasX 10y ago
    >Yeah, and honestly, that includes hiring managers. Not just the example you gave -- they also lie whenever they list something as "required" and then hire the go-getter who's missing some of the skills.
• reitanqild 10y ago
  This has other sides as well: * Excelling through the test never to hear from the company again. * Being (as admitted by the manager in the interview) one of two qualified candidates, the other one being from a somewhere a few hours away by plane, and then get a really cheap offer. * being asked in a disbelieving tone if I can still code after working as a system engineer for a while. (yeah, give me an assignment already.) I'd love to be in more interviews where I could win just by coding small small samples or discuss code on the whiteboard (that is as long as nobody is nitpicking about things that any decent IDE will catch.)
• seldo 10y ago
  Doing what you're doing will probably work, in that you'll get decent candidates. But this approach only works for one kind of good developer -- the kind who can survive this kind of interview. Silicon Valley's diversity problem is made worse by interview styles that give false negatives for excellent candidates who lack confidence or just don't think the same way. My thesis is that this test, by giving frequent false negatives, is resulting in a worse pool of final hires than a broader process.
  • bradleyjg 10y ago
    What would you suggest instead that would decrease the false negatives without allowing the false positives to explode? The parent poster named a couple of different things s/he tried that didn't work. Sometimes the best available option is mediocre. ("It has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.")
    • seldo 10y ago
      You make a good point. In practice, we've not found a reliable way to weed out the false positives that result (I would not characterize it as an "explosion", but there are definitely some). However, we've stuck with this process because we firmly believe that the benefits of having the excellent people we've hired who would not have passed a standard interview outweigh the costs of getting rid of the others.
• uremog 10y ago
  Don't feel too bad, once HR sent a guy to one of my tech interviews who was a male nude model with no programming experience or knowledge - or anything core to the company for that matter.
• qaq 10y ago
  Hmm now I feel bad about asking questions on transaction isolation levels.
• FussyZeus 10y ago
  We do interviews in person where I ask a few basic questions and listen for the answer, then assign a somewhat complex problem to be solved in a pre-prepared iOS project. Google fully allowed. I'm not even looking for a 100% functional solution or even particularly elegant code, I want to see how a candidate reacts to pressure and how resourceful they are. I would say the majority of our hires don't complete it and I always explain that's fine, the point is to observe the process they used to create whatever they created.
• lsiebert 10y ago
  Unless handwriting is a big part of the job irl, it shouldn't be for the interview. White board for drawing a db schema or something, maybe, but programmers type. Also, it can be hard to generate code on the fly in an uncomfortable situation, and breaking the ice is important. I've often wondered if asking individuals to debug, test and fix, or to refactor code, might not be a use way to get a high level look at their product, and ease them into programming mode so when they get to actually writing a function for your next question they are tuned up and ready to go.
• ubernostrum 10y ago
  Tech interviewing is awful. Don't give me excuses for why you do awful things, or try to say "well, it's candidates' fault for having to lie and dissemble to get through the process we created". Plenty of known-smart, known-qualified people are criticizing tech interview processes. They're criticizing the dehumanizing approaches. They're criticizing the way it wastes the time of everyone involved. They're criticizing the way it produces huge false-negative rates. And they're right. Many of the people criticizing tech interviewing are precisely the kind of people you say you want to hire but then design processes to exclude. You don't get to shift the blame on that one; if you're really a hiring manager, you should be finding ways to fix, not ways to make excuses for, the tech interview process.
  • dimal 10y ago
    It's possible to do technical interviewing well. I've done a lot of terrible ones, but at my current job the technical interviews were highly relevant to my work, and not trivia or puzzle questions. We used a laptop instead of a whiteboard. And even though I didn't get everything 100% "right", there was plenty of discussion, so they could see that I knew what I was doing. So they offered me a job. It wasn't an easy interview, but it worked well in my case. And since the other members of the team are very good at what they do, it looks like it's worked for the rest of the company as well.