23 ms·

Senior devs. Is anyone else insulted by coding exams?

• shahbaby 5y ago
  I've accepted that real world development and interviews are 2 different worlds with little overlap. Like many things in life, best not to think too hard about how things should be and focus on making the best with how things actually are.
• billwear 5y ago
  yeah. coding is ubiquitous, and tests show it. dev is an art and a science, and tests can easily screen those out. but that's why dev is rare and valuable. and that's why dev will eventually find its place, without tests. meh.
• PaulHoule 5y ago
  I dunno. Personally I do well with whiteboard interviews and similar things most of the time, both in terms of being good at the subject and in terms of making up for my deficiencies in terms of bluff and bluster (I like to joke that there are two answers to any interview question: "look it up in the hash table" and "look it up in the literature") For all the talk that "hiring is broken" and that managers and candidates need to do something about it there is remarkably little talk about what to do once you've hired them (other than occasional threads that are fashionable from time to time such as "what to say in a 1-1 meeting when there isn't really anything to talk about") If the situation of vetting candidates for quality is so bad you might think labor unions for software devs would be good for management.
• gorpomon 5y ago
  Hiring manager here-- we send out a coding assignment to do a small UI component. It has its hits and misses. Hits: 1. We suss out a lot of people who've been a senior engineer on their resume for years but aren't up to date on practices we care about, like accessibility, semantic HTML, app architecture etc. That stuff is important, I don't want to hire folks who ship apps, but the apps aren't WCAG 2.0 compliant or poorly tested. 2. It can definitely help rescue a candidate that we're on the fence about. Misses: 1. Some candidates blow it off or phone it in, and out of fairness to those that did well, we can't advance them. It's a shame too, because often the reason they do that is because they have other offers on the table, or other companies they're further along on, not because they have an attitude. 2. We say it's a four hour assignment, but in truth people who do well take around 6-8. It's not because the work takes 6-8 hours, but people go above and beyond, you can tell from the git commits. Overall, I like it our coding challenge and won't hire without it, but I'm not saying it's perfect.
  • travisgriggs 5y ago
    Do you pay them for the 6-8 hours they put into it? I know back in the day when I travelled to interview somewhere, I got paid the mileage I drove and sometimes the time I spent there. Just curious if that kind of thing still applies.
    • gorpomon 5y ago
      Company doesn't, but I absolutely would be open to that, I had that in some other industries I was in and it was appreciated. FWIW, I advocate for strong comp for whomever I hire.
  • Dork1234 5y ago
    How can you tell from GIT commits, sometimes people with busy life's only get short periods of time every night and might have weird commit times.
    • gorpomon 5y ago
      That's an interesting one, I can't tell fully as the commit doesn't state when the coding started, but you can just take a look at the history and see short bursts of work. Generally it seems like people do the assignment in 2 bursts of work.
• suc_syn 5y ago
  I think it depends, I have been coding for about 15 years, shipped a lot of Java applications, a lot of Rails, shipped a react system so some Javascript, and done some Python scripting. I applied for a job that said it was heavy OO Python, I said I had some some scripting but hadn't done much large scale Python. I didn't quite complete the coding task as I didn't realize they wanted Python 3 and I was having a few weird problems as I was used to Python 2. If they needed somebody fluent in Python/Django/Flask from day 1 and didn't have room for me to learn then I wasn't the right candidate. If they did and wanted my other experience in the domain area then this was a pointless box check test that I clearly communicated I may not do well on. Funny enough that position is still open a year later and I am doing the same job at a different company in Python/Django. I said in the interview I would need time to learn and they said it wasn't a problem.
• falcolas 5y ago
  I got the chance to peek behind the scenes once while assisting with the hiring for a startup. It was painful to see how many folks applied who had zero chance of making it. As in, they wouldn't be able to actually write a "Hello World" program, let alone FizzBuzz or the types of exams you're mentioning here. The number of those kinds of applications was up in the 80% range of all application submitted. And HR (when you have them) are not able to filter them out properly, since all it takes is dose of buzzwords and sufficient confidence to get past them. So, yeah, code tests are usually stupid and insulting to experienced developers. But that's because they're needed to filter out the stupid.
  • hajile 5y ago
    Asking for fizzbuzz or a simple closure/curry add function (basically `a => b => a + b`) is far different than coding assignments. I did one "two-hour" coding assignment that took me an entire day (and I was by far the fastest according to the interviewer who later admitted they'd not done the task and it also took them an entire day when they tried). I don't plan on doing such a thing again unless I'm compensated fair market rates.
    • falcolas 5y ago
      > I don't plan on doing such a thing again unless I'm compensated fair market rates. That's entirely fair, IMO. Once you're past the "prove you can code at all" step, being compensated for doing work is legitimate.
    • shoppingaround 5y ago
      > I don't plan on doing such a thing again unless I'm compensated fair market rates. Was having drinks with a friend and a recruiter friend of his, and the recruiter began bragging about how her no-name, average-wage firm had the HARDEST coding challenge in town (not even close to true...) because it took candidates as long as 16 hours to complete. She then began regaling us with a candidate who applied, was supplied the challenge (before any in-person, or even phone) interviews. They rebuffed his request to have at least a phone interview with the hiring manager prior-to committing to such time, and then were aghast at his asking if they would be willing to pay for his time given the extreme time commitment necessary. You know how hiring works for my chef friends? A paid shop-test, show up on an off-day and work some station(s) to demonstrate you can walk the walk. You know how hiring works for trade friends? A paid shop-test, they show up on an off-day and work on a discrete piece of work or some piece of a project. Suppose one can only assume that firm's operational principle is to hire the easily manipulated... Personally, I never ask for more than a 2-hour commitment and these days have lowered it to less than 1-hour, providing a scaffolded project from which one could reasonably extrapolate, and typically on their time. To follow up, discuss what they did, why they did it, any differing opinions or approaches. Perhaps I am lucky to not have an LA/NYC/SF sized hiring pool, though.
• onion2k 5y ago
  Nobody who really works on software works on these kind of bugs. That's kind of the point. Coding tests are minimal test cases. They're the sort of thing you wish you'd get when someone reports a problem - a distilled reproducible example of something so you can focus on the problem and only the problem. That's how coding tests should be. Tests with huge blocks of "real world" code that doesn't add anything to the problem you need to solve are much worse. no programmer is going to write anything useful for you This is also kind of the point. Coding tests should not produce useful code. They're designed to assess someone's ability without asking them to do proper work. If you end up doing real work in a test situation without getting properly paid for it then you're being scammed. The problem is often not the test itself, but the failure to do the groundwork to explain why I should take the test. I have a policy that I will never take a coding test before talking to someone from the company - I don't want to waste a few hours of my time on a role I wouldn't accept even if it was offered. I need to talk to the company just to sound out whether the role sounds appropriate, whether the company sounds like somewhere I want to join, and whether or not they're willing to put up with me. If I sound like a reasonable prospect from my resume then the company should be willing to invest 30 minutes on a Zoom call for me to answer their basic questions, and for them answer a few questions I might have too, before I commit to a more indepth series of interviews. If they won't do that then they're not serious about employing me...
  • oriolid 5y ago
    Downvoted because it's true :)
  • binarytox1n 5y ago
    No idea why you're downvoted - these points all make sense: -I should speak to someone at the company before having to write code -Interviews go both ways -Coding problems should be appropriately sized, encapsulated, and reproducible -Coding problems should not be real work
  • nouveaux 5y ago
    "Coding tests should not produce useful code. They're designed to assess someone's ability without asking them to do proper work. If you end up doing real work in a test situation without getting properly paid for it then you're being scammed." You can pass coding tests without being able to do the work. I really wished that a person who can do leetcode well can solve all engineering problems. Unfortunately, someone who leetcodes well may not be able to do the job.
• throwaway984393 5y ago
  If you don't like it, that's fine, but they clearly are not trying to insult you. You're taking it personally. Just because you're the best developer in the world doesn't mean you need to take to HN to rail about their crappy hiring process. Instead try sending them a nice email explaining your concerns. Help them craft a better hiring process. Or find out from them why they made it that way.
• ravenstine 5y ago
  It depends on the exam. I would be at least somewhat insulted at this point to deal with l33tcode, brain teasers, and CS questions. A simple take home project can be okay depending on what it is. If it's a generic "JavaScript" quiz, I'd just walk out. Although this is tooting my own horn, I have enough of a background, enough references, and enough code on GitHub that the idea that I could somehow be lying to a company is more of a conspiracy theory than anything else.
• mooreds 5y ago
  > Also, hiring managers... Do you find these kind of tests useful? Why? How? Former hiring manager. It's unfortunate because it is a bit insulting. However, there are some people who lie. They lie about being able to code. I don't want to hire a senior dev who I then have to fire shortly thereafter. A simple, short coding test that any senior dev should be able to do quickly in their language of choice or a longer project that they get paid for are my two favorite options to filter out folks who say they are senior devs but can't code.
  • napolux 5y ago
    In Italy we have trial periods and nobody really uses them.
    • lbriner 5y ago
      Trial periods are pretty common in Europe, we call it "probation" in the UK but it is hard to objectively decide if someone is up to the job. If they are terrible or brilliant, it's not a problem but in the middle, I don't want to pay some new person £20K more than another dev just because they asked for it and aren't bad enough to be fired. Until there is something quite objective about measuring performance against some kind of qualifications, then it is in danger of being more to do with personality than genuine value.
  • xavor 5y ago
    How do you filter out hiring managers that can't hire?
    • nine_zeros 5y ago
      This is the question. To me it appears that hiring managers are incapable of filtering without exams -making the hiring managers skills questionable.
      • fancyfredbot 5y ago
        There is nothing wrong with a hiring manager recognising that an exam helps them make a hiring decision. What you really need to worry about are hiring managers are incapable of filtering without exams and not using exams.
• DyslexicAtheist 5y ago
  have my git in my CV, and the minute I hear I'm supposed to go through a technical vetting that includes coding I'm out.
  • akie 5y ago
    Thank you. I always click on the GitHub links, and they are really extremely revealing. If you just send me your GitHub and it's good, then you're in the next round.
• awb 5y ago
  > Do you find these kind of tests useful? I’ve hired dozens of Sr. engineers and given coding tests to almost all of them (after a 2nd round interview, never earlier). However, my tests are time-boxes (1hr) and are about greenfielding an app (like a ToDo app) to see how they approach a problem rather than programming knowledge. > Why? About 33-50% of devs that pass the two interviews fail the coding test. Of the ones that fail, they’re great at interviewing but probably oversold their skills. Some are really poor at time management. Some are really poor at simplifying problems. And some are really poor at following directions. It’s possible that they were on teams that carried their weight or possible they were exaggerating their capabilities or prior responsibilities. The opposite has happened too where I’ve been blown away by the code quality and approach. But overall it’s been a very helpful datapoint in hiring.
  • 71a54xd 5y ago
    This is a hypothetical, but how would you suggest engineers that have issues with simplifying problems, managing time or maybe don't realize they're overselling their skills work in a positive direction to correct some of these things? I've noticed many companies will give technical feedback if you don't pass a round, but seems like there has to be some kind of path to help people like this. Always been curious to me that "ideal" practices for managing time, communicating technically / in a business context never seem to really be written down. I learned some of this (albeit badly) at a few internships, but if there'd been some source to read even if it was only the first 25% that would've been immensely helpful out of college.
    • awb 5y ago
      > simplifying problems Practice rewriting personal projects. Once you have a working app, try to make it even simpler, clearer, more efficient, etc. > managing time If you’re on a tight deadline do the easy stuff first and if you’re falling behind get help with the harder parts or ask the team to scale back the scope. But if you bite off more than you can chew you run the risk of having nothing to show for it. If you’re building a proof of concept, then start with the hard parts to show the team that it’s possible and worth additional time to finish it off. > overselling their skills Be honest about your role in a project. Don’t hide the fact that another dev was doing the primary research or making the technical decisions. Just take credit for the things you did from start to finish, without help (because those people that helped might not be there at your next job).
• Apreche 5y ago
  Yes. I refuse to take them.
• moonchrome 5y ago
  This industry has no professional standards or relevant certification - what does a senior developer mean ? You say you have relevant experience - will you show them your work so they can review it ? I have a friend that has >7 years of experience - which was spent on obsolete stack in huge corporate contexts - you put him on a new project to bootstrap a generic app and he's basically a junior/mid with some debugging experience and knowledge of SCRUM. And this was made obvious to him by multiple interviews/tasks he had to do - after which he basically had to spend 6 months getting up to date to be able to work on modern projects.
  • LanceH 5y ago
    > what does a senior developer mean ? I'll give that a go: * They can work a problem independently * They can make newer developers around them better * They can speak to the product owner and provide feedback on rough development requirements and cost
    • porker 5y ago
      Agreed. I don't accept that someone who has, as another commenter wrote: "done the same old crap for 20 years" is unlikely to be a senior engineer. I'm one of those. I don't know the latest JS frameworks. Or the ones that came before. But I can spot the problems in the project (e.g. performance, authentication, authorization), the security holes in the design before it's built, and coach newer developers on how to solve them. And I can make the case upwards for time/funding and make business cases for work.
      • moonchrome 5y ago
        That really makes no sense at all. How transferrable is the experience of an embedded developer to web development ? Or game development to enterprise applications ? I've seen people stuck in very domain specific stuff/isolated on some small part of a huge project that doesn't really translate to much outside of being a junior developer. In my professional career I've went from C++/3D graphics -> .NET -> Angular -> RoR -> React -> Django -> Flutter -> .NET Core. I've also used Python extensively for scripting and personal projects, Clojure on a large personal project, F# and Rust on minor ones, Node.js and PHP side gigs, etc. Which is to say I've hopped a lot of stacks and technologies between jobs and side projects. And without a doubt I can say that the ramp up time, even between similar stacks was non trivial. It took me a year to get "comfortable" with RoR even when I had >5 years of experience with ASP.NET MVC and a year with Django/Python. You say you can give estimates for time and funding and yet you don't know the library landscape and what work needs to be done vs. what can be handled by the platform/libraries ? And that's not even mentioning stuff like cloud providers - where there's so many cloud specific offerings you can glue together that vary wildly between providers. You mentor people about best practices yet you don't have real world experience with the particular tech stack ? You haven't tested your ideas and how translatable they are at all and you're just assuming it translates - I've been bitten by this a few times. So yeah I disagree, when I interviewed people I like to go over some code, ask some questions, get a feeling of how much actually relevant experience a person has and how much potential they have in transferring skills/learning - but there's no replacing relevant experience. And being interviewed like this gave me some insight into their expectations so I could judge if I'm a good fit or not.
• xzyyyz 5y ago
  I am coding for 40+ years... My experience: * out of college people remember theory, cannot code. * mid-level engineers start to forget theory, can code, begin system-wide design. * senior engineers can design, forget how to code. If the position of senior engineer expects hands-on coding (mine does), coding exercise during interview is quite revealing (sadly). Personally I do not believe in engineers who cannot code.
  • mistrial9 5y ago
    as a multi-decade coder here, I believe this has stereotype-sort-of-truth, but is too restrictive in the labels.. look at musicians and think yourself a bit about how different kinds of musicians mature, and their interactions
    • Insanity 5y ago
      That doesn't clarify anything to me but I am curious, how do musicians mature / their interactions change?
    • xzyyyz 5y ago
      Very true. I totally agree with you. :-) I tried to highlight most common problem I see during interview, not judge specific people, or even less people category.
  • criddell 5y ago
    A senior engineer may be super rusty when it comes to programming but should be able to get up to speed relatively quickly. I'd be more concerned with their communication skills, their understanding of crucial concepts, and how they approach very difficult problems.
    • xzyyyz 5y ago
      It could be the case. The question is, how to distinguish one who can get up to speed quickly from one who cannot. In the end, there are expectations of the engineer, and expectations of the company. If the candidate is super-rusty, question is, why? For extended period of time this engineer did not code, and apparently was comfortable with it. Would such a person be happy in the environment, where 50% of the time goes to direct development (remaining 50% -- mentoring, project management, etc)? Note, I wrote development, not coding. But writing technical docs is not development either.
• caffeine 5y ago
  As a hiring manager, they are very useful. As an applicant, you should consider it a good thing. You work in one of the few fields where it is possible to easily and quickly test whether someone is incompetent. If it weren’t for the tests you would be in direct competition with legions of bullshitters.
  • justin_oaks 5y ago
    There's a difference between tests that use programming puzzles and ones that check for basic programming skills. I think the OP is opposed to the puzzle kind that have no bearing actual work. Consider if you're trying to see if someone plays basketball well. But instead of asking them to show basketball skills, you ask them to jump hurdles and juggle. Sure, the people who can do those well probably have good agility and coordination that's necessary for basketball, but you're probably filtering out a lot of great basketball players.
    • caffeine 5y ago
      The benefit of the coding puzzle platforms is as a hiring firm you get shown data about all applicants who took that test, and it’s standardised. You also get pretty high resolution data about how your applicant performed (like their intermediate submissions, editing history etc) and how their solution performs compared to other applicants. So all of that comparative info on a less directly relevant test can actually be more useful than n=2 or 3 on a direct proxy of your actual job. Also I disagree with the premise that these exercises don’t carry over. The ability to puzzle through an algorithm you haven’t seen before in under an hour is directly useful and a common task in any domain that is algorithmically complex and not just gluing CRUD frameworks together (and even that gets complex once the scale is big enough)
      • nouveaux 5y ago
        > The benefit of the coding puzzle platforms is as a hiring firm you get shown data about all applicants who took that test, and it’s standardised. You're arguing that standardized testing is a good indicator of candidate outcome. If this was the case, Universities would not be ditching the SATs en masse. When you test for programming puzzles, you're just filtering out people who have grinded leetcode, just like how the SATs filtered out people who took SAT prep classes. If that's your goal, great. However, we shouldn't pretend programming puzzles are a good way to filter for great engineers. I can guarantee you that leetcode is filtering out a lot of great engineers.
• spacemanmatt 5y ago
  one time some late-teenagers wanted to focus on FizzBuzz instead of the portfolio of code i wanted to walk through in full discussion mode. from a peer who already worked there, i should be glad i did not get an offer.
• exdsq 5y ago
  I kind of enjoy the puzzles. One time I was having a slow day at work and a recruiter called, I took a tech interview in the afternoon just to have some fun with the puzzles lol.
• MisterBastahrd 5y ago
  Only the one I took 2 years ago that had me implementing a marquee tag
• spacemanmatt 5y ago
  I think coding competency is really hard to assess in interview, and arguably the wrong goal in interview. When I evaluated the real goal of interviews, it was surprisingly not to discover the best coders, rather to discover the best fit for the team. Consequently a chemistry/collaboration oriented interview was the most predictive of long-term candidate success.
• spelunker 5y ago
  It used to bother me, but after getting an invite by a FAANG to do an interview I decided to go with it. Sure, I'm not a fan, but if you want to work at certain companies it's what you gotta do. So I swallowed my pride, took the test, and eventually got the job. Worth it.
• juancn 5y ago
  I've interviewed hundreds of programmers, and really, you cannot trust pretty much anyone. There's so many people that think they can code, or just say they do that really don't, that some sort of basic coding test is necessary if the job requires it. Our hiring rate for some roles is 200:1, but we pay handsomely for those. Think it the other way around, interviews are a two way process, you're also interviewing the company, and the way they conduct the interviews, in many ways also tells you what they value. What they're like. Take it as an opportunity to get to know each other. Bring this up in a constructive manner. It may make all the difference and provide a stronger signal to both of you, you learn how do they react to feedback and at the same time you show that you're capable of critical thinking and care enough about your craft to call bullshit when you see it.
  • maybenotafart 5y ago
    yeah I just dont get why we have to make the coding exercises algorithmic. I care more about like, do I have to hold your hand or not? no I dont. Okay we are cool.
    • hocuspocus 5y ago
      I'm not a fan of leetcode questions on a whiteboard, and I personally don't ask those. However for an online automated assessment, provided the question is reasonably time-boxed and not too crazy, I think that's fine, on both side of the interviews.
      • xtracto 5y ago
        The questions available at CodeWars page seem the best for me: They are no "gotcha," algorithmic questions (except the higher level ones) and they allow for a good amount of problem solving. The ones at LeerCode are asinine... oh, you dont remember Dynamic programming? Tough luck. Even if you really wont use it at all.
    • juancn 5y ago
      It has to be simple, not too hard. That first test is basically a screening. Will I invest an engineer's hour to try to figure you out? Then, if you get to a whiteboard challenge, in those the end result is not usually what matters, but the process of problem solving is what you typically look for. Can we communicate effectively? Will you thrive here?
• asdfasgasdgasdg 5y ago
  I haven't done any since I have not switched jobs in a long time. But I would not be insulted by them. I am not proud. I try to take an egoless approach to the work and try my best not to consider myself above anything. I would take the same approach to interviewing.
• kerneloftruth 5y ago
  I've been reading these stories of interview questions for 10+ years now, and it seems to get progressively worse over time. It all reinforces for me the decision to be an independent consultant all my career. I get hired because somebody needs help thinking about their product/design, a project completed, or a difficult bug solved. We talk about what I propose for them to do, and I'll explain what I've done in the past that's relevant or useful. I'm not there to join the family, so I deal with Purchasing and Accounting, not HR.
• HelloNurse 5y ago
  From the description, the test appears irritating for your taste but valid (if you pass you are able to reason about code in twisted, semi-realistic ways, and smart enough to win at multiple-choice exams). Considering the bigger picture, this kind of coding test signals that the company really cares about you being able to code, to the point of pissing off some candidates in order to be sure about the rest. Moreover, it's a more cost-effective and objective test than a whiteboard interview: the company shows some competence at hiring.
• renewiltord 5y ago
  Nope. I don’t see things as “insulting”, in general. It’s just cost-benefit. If it’s a great business with a great team, I don’t also need them to be great interviewers. I’ll just fix that when I join them.
• OmarIsmail 5y ago
  If I ever look for a job again my plan is to give the hiring managers my performance reviews from my previous company. There's enough information in them that speaks to the kind of engineer I am in the real workplace working on real projects with real people. I think that + a 1-2 hour conversation to verify that I know what I'm talking about (i.e. I didn't forge the perf review) should be sufficient for hiring manager to assess if I'd be a good fit in their role. I think that will be a lot better/easier for everyone.
  • binarytox1n 5y ago
    The problem with this is that your previous manager may be an idiot who can't accurately judge your skills. You have the same problem: your manager is no more trustworthy than you are, and it's much easier to just have you write some code in front of me to solve this problem.
• silverlake 5y ago
  I’d prefer to earn a badge from a single coding test on leetcode or similar. Then companies can have more confidence in applicants’ skills and skip the code tests.
• maybenotafart 5y ago
  If coding has taught me just one thing its.... keep your ego in a box. If you need a job, do the fucking exam. if you dont, tell them to pound sand. Its as simple as the dynamic of power.
• drenvuk 5y ago
  I find them fun. What's disgusting is when you solve the coding test with flying colors but the interviewer pulls the "candidate doesn't seem interested about X company" and still fails you. That should be illegal if the session you're in is called a Technical Screen.
• mywittyname 5y ago
  Interviewing people sucks. It's so hard to gauge the competence of a person in 45 minutes. Good code tests are a decent, standardized way of getting a read on a person. They are more fair and suffer less from the "confidence = competence" fallacy. My experience has been that good coding challenges correlate strongly with good team members. It absolutely filters out good candidates on occasion, but it also filters out ones that can't code too. From my perspective as a candidate. I just pay attention to what the recruiter says their interview process will be, and brush up on relevant skills.
  • justin_oaks 5y ago
    > Good code tests > Good coding challenges Now only if we can get a service which administers those "good" tests instead of testing using puzzles and algorithms. You mention that you have experience with good coding challenges. Can you give examples of what is in such challenges? Perhaps the folks reading here could get a better idea of what a good challenge is like instead of a puzzle/algorithm test.
    • mywittyname 5y ago
      Cracking the Code interview-style questions are what we are currently using. I'm not sure if that's where they originated, but that's the style of question. I think the key at my current gig is that engineers who interview regularly do the interview challenges. This ensures that the questions are reasonable to ask, and that effective guidance can be given to candidates. For those without large engineering staff, HackerRank is good, in my experience. I use it for practice. I've had bad experience with leetcode, we used it at another place I worked and some of the crowd sourced questions were wrong.
• malandrew 5y ago
  Personally, I find the algos interview to be the bullshit one. I've lost track of the number of people we've interviewed and hired that do well on it and then once they are working for us go ahead and design unnecessarily distributed systems (i.e. split some functionality across two or more services when there wasn't a scaling requirement that necessitated splitting things up) and thought nothing of all the extra CPU and memory that was now going to be used on serialization/deserialization between those two services and that's before you consider to all the added incidental complexity from (1) separate deploys, (2) separate on-call shifts, (3) separate logs and metrics, (4) more complicated migrations of interfaces between them, (5) increased complexity in testing that the services work correctly together, etc. In the last 7.5 years in my current role, I have yet to apply much if anything I needed to study for the algos interview for this role. I get that some adjacent roles in the company might occasionally need this stuff, but it's used rarely enough that it's a better skillset to be able to find the algo you need when you need it then study to be able to conjure one on demand only to have that knowledge atrophy while on the job.
• y-c-o-m-b 5y ago
  Insulted? Never. Annoyed? Many times, yes. It really depends on the type of test. If they give me the "this should take 4 hours" project, I usually tell them to take a hike because that's very disrespectful of my time and the 4 hours is complete bullshit if one is trying to deliver a perfect result. Coding puzzles are extremely annoying, but I can usually get through them. The best coding tests are those that demonstrate you know how to code applications relevant to the job; e.g. a UI component or an API endpoint that takes a parameter and body and returns a filtered result. Then the test is followed up with discussions around what else could be done with it in the real world (auth, performance enhancements, etc.). Seemingly this would be the easiest and most rational path for both interviewer and interviewee, so I'm not sure why the industry is still stuck on those stupid puzzle exams. "We can't find any good devs". No, your hiring method sucks and you're eliminating good devs because of it.
  • justin_oaks 5y ago
    > The best coding tests are those that demonstrate you know how to code applications relevant to the job Exactly. I am extremely confused as to why puzzle exams are common. Why can't the exams cover things that normal developers work through all the time? Things like reading existing code, improving error handling, debugging, basic performance optimization (e.g. don't do unnecessary work inside the for-loop), refactoring, etc. When I was an interviewer I gave some code samples to a candidate. The code would have all sorts of problems in it and I asked how the code could be improved. If the candidate couldn't identify basic problems then it was a red flag. For example, I made the code catch all exception types and ignore them. If you're a developer and can't tell me "You probably shouldn't do that" then you're not ready for production work. When I ask, "What can be done to improve it?" the minimum I expect is "Log the error" or "Don't ignore the error. Propagate it to the caller" or "catch only specific exceptions". Funny enough, I once had a boss who wouldn't make the cut based on my example above. We begged him to stop committing code.
  • sergiotapia 5y ago
    I agree, code puzzles suck. Our take-home assignment takes about five hours and we provide you with the skeleton project with a few schemas already there for you to play with. https://github.com/play-oxygen/takehome-fullstack-engineer https://github.com/play-oxygen/takehome-fullstack-engineer What you do in this take home assignment directly applies to what you're going to be doing full-time while working with us. However these kinds of take-home assignments only work if you have technical people on your team. If your founding team is non-technical and you are using an outsource shop YMMV. https://sergiotapia.com/your-interview-process-sucks-you-arent-faangm https://sergiotapia.com/your-interview-process-sucks-you-are...
• theamk 5y ago
  I am not in web, but at least in my field, the "sort" question seems reasonable? You cannot always rely on the debugger being present and working -- maybe this is a remote service you cannot connect to, or maybe deployment takes hours while sending a test case only takes minutes. As for programming questions in general, they are certainly annoying during interviews, but I would be hesitant to say they are net negative. We have hired a few people who just could not program, and this was very discouraging for the team: you spend month training them, telling yourself "I am sure they are smart, I just need to help them one more time" until you realize that no, you are just wasting your time. A few cases like those, and I can see why people want to ask coding questions on interviews.
• shagie 5y ago
  I have seen candidates present as a senior dev on paper, but clearly aren't senior dev based on interview performance or code. Without testing the code, there is a risk of hiring a senior dev (and passing on a more qualified one). The disconnect between what is done day to day and the types of things asked for in an interview is because some candidates may refuse to do what could be seen as work product for the hiring company. There are companies out there that have taken this further and give a long "interview" that is actually work product. Making sure that the code being written is clearly demonstration / contrived examples reduces that potential conflict. So yes, I do find coding tests useful as it allows me to put my best foot forward as a candidate demonstrating that I can write clean and well crafted code. Likewise, on the hiring side of the table, coding tests can help separate the candidates who don't care about the interview or will be a net negative after hiring from the ones that are willing to put in some effort. Excessively long code projects are to be discouraged though - there is too much time that can be consumed by them and it biases to people who have an excess of time available to work on them.
• TameAntelope 5y ago
  Convince the rest of the world to stop applying for senior+ positions and I'll happily stop giving coding exams. Hiring is opening yourself up to complete strangers, literally anyone on the Internet can just submit an application saying whatever they want. Even people with a decade or more of experience end up getting stuck on their specific tech stack and are utterly useless on every other stack. How do you propose filtering through all of that, and why aren't people already doing it?
• jriggs 5y ago
  There seems to be a fair amount of hiring manager in this thread, so I wanted to ask a related question: Is my current tech adjacent role preventing me from getting interviews as a developer? I have been working in technology for over 15 years now. I am looking to switch but into software development and applying to roles that align very well with my past experiences and current ambitions. I've probably applied to 100 jobs and had 5 follow ups from companies! What could the issue be? My resume? Ageism? Current Role? My current resume for context https://joe-riggs.com/resume/ https://joe-riggs.com/resume/
• mkdirp 5y ago
  I'm an individual contributor, but I've helped conduct quite a few interviews at my current place (where we have coding tests) and in previous places (where we haven't had them). I totally understand where you're coming from. The coding test I had to do at my current place took me few hours to do. The company is great, and I'm happy at the place, however, I would be lying if I didn't think twice when I got told I'd have to do a coding test after the initial screening. Certainly, I did feel insulted. The reason I ended up taking it was because it was very obviously just a test (i.e. they weren't trying to get free labour out of me). In the end, it all worked out, and I'm glad I did end up doing it. On the flip side, sadly I've worked with a lot of people who just don't know how to code. Coding exercising aren't perfect either, but it certainly weeds out a whole lot of bad hires. I've worked with individuals who have essentially become "the documentation person". This is fine if you're in an enterprise, but in a small 3/4 person team, that one person holds back the rest a lot. I think having a _set_ coding exercise that doesn't get free labour out of the candidate, it can help a lot towards having a stronger team. As a candidate, do be careful whose coding exercise you end up doing. There are still quite a few companies that try to get free labour out of candidates. So yes, I think it is insulting unfortunately, but it is a necessary evil to build better teams, and avoid those who are, quite frankly, lying and are going to hold the team back.
  • AnimalMuppet 5y ago
    > The coding test I had to do at my current place took me few hours to do. > The reason I ended up taking it was because it was very obviously just a test (i.e. they weren't trying to get free labour out of me). But it still takes the same amount of my work. Let's say I'm looking for a new job at a time when I still have an old one. I send out 30 resumes. I get 10 responses that want me to take a coding test, and each one takes me 4 hours. That's 40 hours, at a time when I already have a job, and while I'm still trying to have a life. So, no. Just no. I won't take your multi-hour take-home coding test. I mean, if one of the places was my dream job, I might for that one. But if you're a run-of-the-mill employer? No.
    • mkdirp 5y ago
      I totally agree, and you should be selective with take home tests. I do very few and the potential role would really have to be worth my time if I were to get hired. I don't believe dream jobs exist. I see a jobs as a means to an end. It's a tool for me to live my life the way I want to live it.
• harles 5y ago
  I’ve been a hiring manager at both startups and FAANGs and code tests are absolutely useful. The only candidates who I have ever heard complain about them were ones that couldn’t pass and blamed others for it. Things like forgotten return statements in C++ causing stack corruption were blamed on the boilerplate test code, and every time we dodged a bullet by discovering bad candidates. I honestly don’t get how anyone could be offended by a coding test. It’s what we do as programmers and I’m deeply suspicious of those who refuse.
• gedy 5y ago
  It's insulting when a company is the one to reach out to someone who is senior, and already employed, but then added to some pipeline where you are expected to first jump through hoops like technical quizzes. Demonstrate you've done "preparation" for interview, asked why you want to work for company X, etc. Smaller companies shouldn't delude themselves they are some FAANG type company with huge comp that thousands of people want to work for.
• kragen 5y ago
  I agree that understanding the problem space is exponentially more powerful than just being able to make code do what you want (or figure out why it doesn't). However, I don't find this kind of thing insulting. Unfortunately "how do you work with garbage code written by shitty programmers" is a pretty important question, though not one I have to worry about quite as much when I'm working on my own projects where I've written all the code. You might think that at a startup the garbage code wouldn't've had time to pile up, but that isn't my experience. Often founders have a better grasp of the problem space than of the solution space (I mean, they're often shitty programmers), and even their grasp of the problem space is weak at first; this can lead to multiple rapid pivots in which code that was good for one thing is patched as quickly as possible to be barely suitable for something else, with the expectation that it will probably be thrown away anyway, and if not, they can hire someone else to rewrite it. I'm surprised by your thoughts on the bug test. Usually when I fix a bug, any bug, my first step is to construct a test case that reliably demonstrates the bug, which is what it sounds like they asked you to do. But you say, "this diagnostic technique of arbitrarily working backwards ... is probably the worst method of programming." What do you do instead? Or have I misunderstood your description? My experience with hiring programmers (18 years ago) was that a short emailed test with a few simple programming problems I could do in a few minutes was enough to easily rule out about 90% of applicants, including people whose credentials looked great on paper. Of course it tells you almost nothing about their understanding of the problem domain or their ability to design code to be maintainable in the large, but if they can't program then they can't do the job even if they're good at those things. One deficiency in our process at the time was that we didn't test for the ability to read code, just write it, and we generally spend about five times as much of our time reading code as writing it. The debugging question sounds like a useful technique for giving some insight into that.
• ryandrake 5y ago
  One thing that I always thought would really help, which "senior developers" as a group seem to be largely against, would be a basic competency test like the medical board exam or law bar exam. Do it once, and demonstrate that you can know some minimum standard amount of knowledge and can do the bare minimum of software development. It wouldn't test every development skill out there. It wouldn't test particular language competency. It wouldn't test for business domain knowledge. And it would not replace the interview or prove that you were the right fit for any particular job. But it could weed out 90% of the fakers who literally cannot program or know nothing about software that all the hiring managers in these threads are complaining about. It would help to prevent our current mess where every company in the world has to waste time doing FizzBuzz again and again for every candidate. I don't understand why we are against this basic, minimal gate. We have this unreasonable fear of regulation and gatekeeping in our profession, which is ultimately to everyone's collective detriment. I'm not calling for 20,000 pages of federal regulations on software engineering. A minimal gate. Nobody benefits from the current world where anyone with no knowledge or skills can simply claim to be a software engineer. Nobody except the fakers.
  • tomc1985 5y ago
    While I'm also for some kind of standard competency, if it were an exam it would create a market for test-prep books that cover just the material and nothing else.
    • JohnHaugeland 5y ago
      that market already exists
  • MontyCarloHall 5y ago
    A certification scheme like this could work, but it would need to be regularly renewed (every 5 years?). Passing it a single time early in one’s career is no indication that coding proficiency still exists later in one’s career. In my experience, basic coding skills can really atrophy in senior developers who quit writing code years ago and are full-time architects/managers. I’ve interviewed more than a handful of highly accomplished people with decades of experience as developers and then engineering managers who couldn’t answer extremely basic coding questions (I’m not talking about Leetcode-esque BS, I mean stuff closer to FizzBuzz).
• marginalia_nu 5y ago
  This will probably make me come off as a diva, but I don't want to interview for companies that don't want to hire me for my abilities. I'm not interested in being just another index in the developers array. If that is what you are looking for, then you are quite bluntly looking for someone else. I have an internet search engine on my resume. I have implemented a C compiler. Don't give me FizzBuzz.
  • oriolid 5y ago
    How do you demonstrate to a complete stranger that you just didn't make up the resume, or wasn't pure dead weight in the teams who did the work?
    • marginalia_nu 5y ago
      There is no team. I did these things alone, for fun. If you doubt me, ask me any question about them, any implementation detail, I can explain it to you. I can discuss parsers, stack frame optimization and calling conventions for days, weird edge cases in the C syntax, trigraphs, whatever; I can tell you not only how to implement a search engine index in minute detail, methods for compressing a lexicon, but how to implement a crawler, how to extract keywords from a website, how to identify the language of a website, we can discuss ranking algorithms, we can discuss absurd number of different ways a web server may tell you which character encoding a page has, I can tell you why some websites have the DTD "-//SoftQuad Software//DTD HoTMetaL PRO 6.0::19990601::extensions to HTML 4.0//EN", we can discuss the absurdly inconsistent usage of the lang tag, we can talk about how sequential writes sometimes are still faster on SSDs, we can talk about how to make a SQL query perform well on a table with half a billion rows, we can talk about blackhat SEO, we can talk about how to implement a hash table on disk and when that is and isn't a good idea, we can discuss B-trees. I also have the finished product to show. It's not open source, but if all this fails to convince you, I can bring my laptop and we can walk through the actual code. If all of this is bullshit, I'm the greatest bullshit-artist alive, and you can just put me in sales instead.
      • dtagames 5y ago
• lumost 5y ago
  I recently spent some time talking to other teams internally at a FAANG. I have 12+ years as an SDE and 4 in the company. One commonality I've found is that teams who do not ask coding interviews tend to become crappy over time. Even in an environment where you can look at individuals code history, product releases, and talk to their coworkers. I've taken it as a sign that the team values their own employees enough that they ensure that new hires won't be a drag, or have unreasonable expectations e.g. "I lead, I don't code" etc.
• yodsanklai 5y ago
  I'd be curious to see the data, but I think these tests are overall good predictors of SWE in the company. Companies who use these types of tests (including FAANG) aren't stupid. Yes, these tests aren't perfect but no recruitment method is. There are many other constraints to consider and overall they are an acceptable solution. I'd recommend to practice and take these interviews with an open mind. Otherwise, there are companies who use different type of interviews.
• undecisive 5y ago
  Senior developer here. I've been on both sides of the process. Firstly, let me say that I hate the idea of take-home tests. I don't consider myself particularly woke, but it seems obvious that forcing people to find a two hour slot in their personal lives to produce their best code for a throwaway project, which may not even get them the job... that's going to discriminate against parents of small children and those caring for loved ones. Statistically speaking, females and BAME applicants will suffer more. So if you feel you have to offer this, always allow a path for people to opt out (WITHOUT them giving you a reason. Just don't.) And as an applicant, if you feel this part of the process is going to be difficult for you due to your circumstances, always ask the question. How they treat your request will be one of the best benchmarks you can get of whether the company's equality and compassion policies have teeth, or whether it's just lip service. That said, for some people it does work. It makes it easier to determine a person's skill level. It weeds out those who can't code or don't have any experience of best practices. So when I had to quickly find myself a new job recently, I was asked to do a couple of take-home projects. Knowing that the roles all had an element of knowledge transfer and mentoring, I set up a screen recorder (with audio) and narrated my solution. It felt completely weird. It was totally unnecessary. But it meant I could watch it back with fresh eyes, and see whether I justified my decisions well, whether I explained myself cogently, and what I would do in the future. So no, don't be insulted by the process. Use it to your advantage.
• johnnyb9 5y ago
  Just curious, has anyone ever had a candidate actually fail FizzBuzz in front of them? I think the original statement was something like 90% of candidates can't do it. In my experience, every single candidate I have ever given that question succeeds. When I am asked FizzBuzz on an interview, I am actually insulted.
  • boring_twenties 5y ago
    Not FizzBuzz, and not me personally, but from someone I worked with and I have 0 reason to believe is lying: After a few disappointing responses to better questions, interviewer decides to give a "freebie" and asks for a function that determines whether an integer is odd or even. Candidate produces something that loops from 0 to the provided integer, incrementing two separate counters, then comparing them at the end. Interviewer manages to stammer out something like "are you sure there isn't a more efficient way to solve this?" Guy furrows his brow for a few minutes more, then a light bulb of sorts goes on, and he declares "Of course! ..." "... I only need one counter!"
    • Apocryphon 5y ago
      That seems more like a failure of mathematical reasoning than in programming.
      • kragen 5y ago
        I would be amazed to meet someone who, if asked whether 3042041 was odd or even, would follow this exponential-time procedure manually. Unless the candidate was such a person, it's a failure of programming.
        • Apocryphon 5y ago
          They just seem numerically illiterate to the point of not realizing how to determine odds or evens. Though perhaps, if they were more competent as a programmer, they would skip decimal math altogether and use the ol' bitwise operator trick.
• igetspam 5y ago
  We do a take home for every role. Managers do a presentation. Engineers do a coding challenge. We let engineers opt out of our challenge and offer up their own code. For the latter option, we review the code and do a live Q&A. We need a way to get candidates and just trusting a resume isn't enough.
• mmazurki 5y ago
  I find that coding tests are a huge red flag. I usually stop any conversation as soon as I know it will be required even for freelance side jobs. As hiring manager I do not disagree with basic tests for junior roles but for senior roles it definitely does not assess where the value is, coding is only part of the equation. I believe that a short call with a peer from the team to review a merge request/architecture decision is far more interesting.
• SnowingXIV 5y ago
  I've been conducting interviews, we've experimented with adding some coding challenges and it's helped. Not live. But simple pass/fail write some methods to do a thing. This typically will filter out brand new folks. But I do think you can have discussion, a technical interview back and forth - I'm talking details around guarding against nil classes, backwards compatible migrations, scale problems, real-world issues the interviewee has encountered. Types of tests they need. Maybe a situation where they missed a use-case. If they are able to articulate a discussion like this, I'm pretty confident I don't need to run them through leetcode doing BFS/DFS binary tree junk.
• Clubber 5y ago
  >Is anyone else insulted by coding exams? Yes, I refuse to take them. Fortunately I've built a pretty good network and reputation over the years so I get hired over a lunch meeting. I haven't done a serious cold code interview in years. The last one I did was around 10 years ago and I kinda wanted to do iPhone app development full time. I had several apps on the Apple App Store. They were live/downloadable and the published by was obvious it was me. One was in the top 10 list of its category at the time. The company still wanted me to "write a quick Twitter client app by tomorrow." I did it and they kept asking for more. I finally told them I wasn't interested anymore. There wasn't an HR department or anything, it was a small startup with funding. That company is out of business now. I'd have to be pretty desperate to do that again. I've been on both sides of the hiring table. I suspect most good senior devs won't put up with these type of shenanigans, so but requiring this sort of stuff, you're limiting your candidate pool to poor or mediocre or rising star that will leave in a couple of years at best. You should think of a question that any senior developer would know but someone who's never coded wouldn't. Something really simple like, "when declaring a method, what keyword do you use to denote that it will return nothing?" I say this every time this comes up, but the cargo cult is strong.
• PragmaticPulp 5y ago
  If you get a chance, spend some time helping out with recruiting, interviewing, and hiring candidates some day. It will make much more sense from the hiring side of the table. You may be fully qualified for this job and the test may be an unnecessary obstacle for you. If you only consider this job in the context of your own experience, requiring testing is going to feel like a dumb move. However, not all candidates are like you. The hiring manager will receive a range of candidates from people far more experienced than yourself to people who aren’t able to write any functioning code without Googling for even basic syntax questions. Back when we did in-person coding interviews many years ago, it was shocking to see how many candidates would arrive charismatic and confident, only to fail because they couldn’t remember the syntax of a for loop in a language they (wrongly) claimed to be an expert in. Look at it this way: If you work at a company that hired everyone based on their resume and nothing else, you would eventually be surrounded by a significant number of people who don’t know what they’re doing, or perhaps don’t care. They reach this point in their career by shifting work to people who do know how to do it and by draining the productivity of people around them. It’s terrible, and the good developers will leave.
• phendrenad2 5y ago
  > It makes me not want to work at places that do this. I won't work places that do this. It's inconsiderate of my (highly valuable) time, and it makes me think that the company has trust issues. You'll especially feel this way when you look at The hiring process for CTO[1], which is more conversational. I believe senior engineer interviews should be something like this, but with more heavy technical questions. [1] - https://www.karllhughes.com/posts/cto-interview-questions https://www.karllhughes.com/posts/cto-interview-questions
• markb139 5y ago
  I interviewed for a 6 month contract and there was a programming exercise. My first question was, what unit test framework is available for the Python code they wanted me to write? “Errr, there isn’t one”. Ok, let’s create a simple one first then. I was offered the role, but I declined it.
• asklwww 5y ago
  Coding interviews are why I always consider leaving this industry despite the pay. I've spent 10 years accumulating a large body of knowledge regarding product and system design, various tools to do it, and a mastery of a few languages. Yet, instead of being asked things relevant to my abilities I'm asking coding questions that are designed for junior fresh grads. No, I don't remember all of my algorithms. No, I don't know the newest technology google has released. Do you want me to build you something? Great. I'm in my mid-30s and I cannot see myself learning every new tool some edgy start up or FAANG vomits out unless it's so abundantly useful I cannot help myself. I don't want to spend weeks grinding leetcode. The last time I interviewed was 5 years ago and while I have gathered a vast body of knowledge on engineering and am extremely capable none of this would ever show in a leetcode interview. ... and don't get me started on the 8 tier 1 month long crucible interviews where I'm subject to several coding interviews, an architecture interview, a personality interview, and several other meta-meta interviews. Oh, and this is of course on the company's schedule so it's always inconvenient, sometimes requires travel, and is always an incredible pain. I'm convinced 99.9% of hiring managers are failed engineers that failed upward into management. They themselves could not pass the tests they give, so it's being used a cudgel to have one over on the poor sap who needs to pay rent. I mean this to be insulting. I have very, very little respect for engineering management vs ICs. IC roles are earned through actual talent, engineering management is political. The entire industry is built this way and it's insulting. I can understand thoroughly interviewing someone with a questionable pedigree but a simple call to any of the half dozen references I have in my resume will confirm my ability. Being treated like a liar and a salary thief and given the 3rd degree is an insult, absolutely.
• qxmat 5y ago
  Lots of timed algo ones in my city - i.e. time-space complexity. Completely unrealistic for a DevOps cum full-stack role. If they were untimed - like homework assignments - I'd probably say yes to more but as it stands I've no issue securing work with top end rates after a f2f conversion (no technical vetting at all - people seem thankful to have me onboard). I've seen reviewers reject 8-hour assignments because the submission uses a certain library or something contrary to the house style so I've stopped doing these too. Opinions matter but they shouldn't be a f2f filter. Right now my hard and fast rule is no code on paper - sure we can whiteboard but I'm not writing as much as an if-statement unless I can hit F5 on my keyboard in my IDE. (My second rule is no interviews in lobbies)
• kutenai 5y ago
  I'm a Senior Dev. I dabbled in some coding in Jr. High, but go more involved in my early 20's. I'm now 60. I've interviewed many engineers. My process involves asking open-ended question about important topics, and let them explain. Write down about 20 or 30 tidbits about the language you expect them to know. Include a range of simple, medium, hard, and, hard-core expert stuff. See where they fail, or where they struggle to explain or discuss. You can't "practice test" your way into that, and it's always obvious where someone is knowledgable, and where they struggle, or don't know anything. Further, I ask probe them for their 'problem solving' approaches. How do you learn new things? Name some of your favorite books on programming/development/design. Oh, that last one, that may date me, cause I come from a time when they had these things called books. We would buy them, and read them. I've found so many developers that just say "oh, I google for it". Sure, that's great, and I google the crap out of things also.. but, here is the fundamental issue with "learning" that way. "You only get the answer to the question you knew to ask." The other answer, the one that says "oh, there is a totally different, but superior approach" you learn from reading and getting a solid background on the capabilities of the language/library/module/environment. Books (and online courses or comprehensive material is equivalent) teach you that stuff. The best programmer I ever hired read books. She (yes, she) was far younger, and unlike her peers, had discovered that reading and keeping some books in your library is valuable. My advice, ask them what they read. If they "just google it", kick them to the curb. "Next".
  • justin_oaks 5y ago
    You've described a solid method to interviewing. I think your point about people who read books could be better described as people "intentionally learning" and using "self-directed learning". The sources of that learning are extensive and not limited to books or online courses. You could learn from a mentor, by trying out things yourself, by reading source code of open source projects, reading programming blogs, etc. The underlying theme is that the person is intentionally trying to learn and doesn't require hand-holding or pressure to do it.
    • kutenai 5y ago
      I agree with you @justin_oaks. I overly simplified that point. My main point is that learning should be as comprehensive as possible. Learn what your tools can do, then apply that to the problem, realizing that multiple approaches are possible. Know the tools well. It does not matter so much how you get there. I've worked with engineers that do things a certain way because this is what they learned at some point, or saw, or googled. I show them "did you know you could just do this", and they are blown away. I too am blown away that they don't even know the capabilities of a language they have been using for years in some cases.
• ratherbefuddled 5y ago
  As a candidate, coding exams are really useful for identifying companies I don't want to work for. As a hirer, they're useful for not very much at all. They don't tell you if someone can produce working software, they don't give any insight into how someone thinks or how quickly they can learn, and they will rule out many candidates who are better than most of those they rule in. They might help you whittle very large candidate lists down to smaller ones cheaply but if you have that problem you should be using a different approach. With code exams as part of your hiring process over time you will skew your hiring towards presentees who have crammed and rote learned and are there for the wrong reasons. Hire people you think are smart, try very hard to stamp on your unconscious biases, aim for a broad variety of experience levels and types in your team, give them all the support and help you can and make sure that you quickly fire people who turn out to have misled you about their skills.
• Apocryphon 5y ago
  To rewrite a comment I posted earlier: There are always stories of senior candidates with years experience who fail painfully simple coding interviews. If these candidates were gainfully employed, maybe that indicates their roles, perhaps their entire careers, didn’t require programming? Or perhaps it means that it’s possible to write code without having a deep understanding? Or could interviews be simply that nerve-wracking that experienced people fail easily? These widespread anecdotes should inspire reflection, not just on the utility of technical interviews, but on the very nature of the work that goes on in the software industry. What exactly is going on?
• mrh0057 5y ago
  The tests are close to worthless. It is easy to check if someone truly did what they claim on their resume by asking questions about projects they worked on. Caught way more people misrepresenting on their capabilities by doing that but you have to have people doing the interview who has both breadth and depth in multiple areas. I rarely see interviewer(s) asking questions to try and discover the person level of knowledge but instead ask questions showing theirs.
• paxys 5y ago
  Whether the tests are useful or not, if a prospective employee - no matter how senior - felt insulted or thought it was beneath them to answer simple questions, I don't really want them working for me in any case.
• codingdave 5y ago
  I'm not insulted by coding tests. Not even simple bug fixing - those silly bugs may not be production bugs, but I cannot be the only one who makes mistakes on the fly as I code, then self-correct immediately afterwards. How many times a day to you self-correct something in your code? Stupid tests for bugs show you can do so, so I'm not insulted by them. What I am insulted by is the leap from "have a conversation" to "go take these tests". I want that conversation to know if I am even interested. It is not respectful of my time to make me jump through hoops just to have that first 5 minute conversation to see whether there is even any potential here.
• SavageBeast 5y ago
  In my staffing/hiring experience (about 40 people) I find its very easy within about 10 verbal questions on a standard voice call to determine some one CANT code. How well can they code? That takes more than 10 questions but is equally easy to determine. Keep in mind this is only useful on mid to senior level people with a lot of experience. You'd never interview a fresh bootcamper or CS grad this way. For example - Im hiring for a position where I know the job and the tech requirements because I've done the job myself. Im only phone screening candidates who's resumes paint a picture of someone who works in this area, in these languages, in this tool chain etc. I'm not screening randoms off the streets here - Im actually bothering to qualify people before I bother to screen them. Lets say its full stack web development and I expect the candidate to be a producing team member in 30 days (because if nothing else, nobody off the street knows about our business domain, what the hell a TR-111 device is or a domain specific message format etc - not even to mention where all the bodies are buried in our codebase). Theres a certain baseline set of things a full stack web developer has done more times than they can remember. These questions are intentionally vague. 1) Whats the difference in using the standard GET/POST Request/Response style of web page vs a page that does the same thing via invoking a backend API? Tell me how you build one vs. the other? 2) Someone asks you to build a screen that fetches some data from the database - walk me through the various considerations and how you do this - Give me step 1, step 2, step 3 etc? What if there are search parameters the user can enter? What if this stuff is sensitive and I don't want it showing up in any log files? Obviously theres more than one way to do this so any real answer is a good one. This question covers a lot of ground and almost does the whole job for you. 3) How do I debug Javascript in a running page? 4) What are the most common Bash commands you find yourself using? Any automation scripts you've written? 5) Why cant I rely on developing with some whacky font on my local machine? 6) Talk to me about CSS media queries. What are they for? When do you use them? 7) Language specific stuff like when to use a Hashtable vs. a List? Whats a linked list? 8) Say I give you a hostname and some creds to a remote machine and I tell you theres apparently something going wrong on the prod web app. Where are you going to look, what are you going to look for and how are you going to look? ("I'm going to ssh to the machine like user@hostname ... then dig around /var/log ... ") - bonus if you can tell me where to look next and the likely problem as a result of this search. 9) A junior dev is having trouble getting a server running - some error about a port conflict. How can you help? 10) You get a ticket that requires you implement code requiring a new dependency - tell me how you get all that running locally. Does this have any deployment implications? If the candidate gets this far you can be pretty sure they really have done the work specified on their resume. Now you know they can code. One does not come by knowing answers to questions like this without having written some code. Now - how well can they code? This takes 1 hour during an onsite interview. I recall one interview where this was done very well - the Product Owner handed me a stack of printer paper and some pencils. "I want you to write as close to full syntax as you can without an editor, an end-to-end login page where I get a login failure or a page that shows my address from a database. Think of every page as a file you'd write for your solution. This shouldn't take more than an hour." It didn't take more than an hour either. I had a job offer by the end of the week and I joined a staff of people who had done the same thing. Turns out we could all code just fine. Now, this is an easy kind of interview if you're talking to a person with your desired qualifications. If you're not then its a very short interview. From the candidate perspective, the ones that represent themselves accurately in their resumes knock it out without issue while having spent the bare minimum of time with the process. No take home assignment. No obtuse CS topic that a senior dev hasn't thought about in literally a decade. No contrived problem with a bar, 2 billiard balls and a fulcrum, etc. Just simple, fast and to the point.
• sickygnar 5y ago
  They filter out positives, though according to hiring managers, that's the point. I had a frustrating experience with a hackerrank recently. My code was passing all of the public test cases, but failing one of the hidden test cases, and there was no way (that I could find) to debug it. Incredibly frustrating. Even if you're a long time senior developer who can code, don't be fooled into thinking you can pass one without practicing on the particular platform.
• catpants 5y ago
  As a senior engineer I have a very comfortable good paying job. When a tech recruiter or a job listing entices me to an interview they have a lot to overcome to get me to switch jobs. The recruiters especially often frame this as "Company x is so excited to talk to me!" and that I am going to be a great fit. At this point it seems like the company wants me more than I want them. Then they give me a coding test and they have completely sunk any of the inertia needed to get me to leave my current job. Add to this hours and hours of interviews and I am like "Nope, I will keep my cushy job. Thank you." It's even worse when these companies make me do a coding test before even talking to me. Companies need to get me interested and excited to work for them before I am going to spend my valuable time jumping through their hoops.
• jimcollinsworth 5y ago
  Senior dev here, yes these tests are pretty useless for experienced hires. They only test a fraction of the skills a senior dev should have. Senior developers don't work on problems that can be defined in a paragraph, coded and finished in a few hours. Their projects will often involve a very large, complex, aging system sometimes with documentation and tests. They are given assignments immediately, have to dig into code and data with little help or supervision. Find the spot in these million lines of code where I can add 10 more lines. Their experience allows them to learn large code bases, manage risk, fill gaps in knowledge, proactively communicate with others and much more. For interviews I've done code or design walkthroughs with the candidate. Have them open up their code and talk about it. And also I'll show some of our code, and have them read and explain it. Lots of good questions and discussion will come out of it.
• mmansoor78 5y ago
  Yes. An algorithm is not a valid test of your skills and experience. e
• matthewmacleod 5y ago
  As a rule they aren't insulting – but as with anything there are good and bad implementations. I've been on both sides of the fence, as both an applicant and the hiring manager. I personally hate "leetcode" nonsense, "find-the-bug"-style quizzes or algorithmic white board challenges. I'd consider going through with them as an applicant, depending on the organisation, but I don't think they're useful tools and it would be a bit of a red flag that suggested they didn't have a great hiring process. But I realise that people have different views on this and try not to take it personally. We have settled on using a compact take-home coding exercise, which is a pretty representative example of the sort of thing we do day-to-day. There are obvious downsides to this, in that it requires a few hours of commitment, but we've tried to be as flexible and light-touch with it as possible. My experience is that roughly 50% of people totally flunk it – and this is post-first-interview, after we've had a decent chat and decided that they can communicate and have the right level of apparent expertise. And our analysis isn't that harsh – it's basically "did you write code that I could read and which does something in the ballpark of the spec". It's pretty surprising to see so many don't hit that bar. I am very much aware of the requirement to be respectful of everyone's time, so I figure this is probably fairer than having people waste effort continuing with the process when they've no chance. Any approach you take is going to have a set of tradeoffs, and all you can really do is make sure that whatever process you put in place is checking for the things you want.
• s1gs3gv 5y ago
  Actually I'm also insulted by coding exams, and even more so by the entire hiring process. Anyone who has worked two or three decades in our field like you and I have knows that the key skill needed today is the ability to learn quickly. In our information rich field, knowing how to develop a solution to a particular problem often reduces to knowing how to search and utilize information effectively. Effectiveness comes from experience and isn't easily measured by assessing our knowledge of this or that programming language or algorithm. Current hiring practices are often mediocre and managed by people with limited understanding of the nature of what we do as coders. You are right in feeling that you should avoid working for these kinds of places.
• dboreham 5y ago
  Obviously answering the question: can this person that we're considering hiring to write code, actually write code? Is worthwhile trying to answer. Whether you can reasonably do that in a 1-2h interview by asking them to type stuff into a computer, I'm not so sure. I suppose it's a not bad approach but it seems likely to produce false negatives. e.g. candidate may have been working in a non-coding role for the past year and might therefore perform poorly in a coding challenge, but when hired would get back up to speed in a short time. I came from a hardware engineering background, and we had the same concern there: does the candidate know how to design hardware? We didn't ask them to design a circuit in the interview, but somehow it worked out ok to just ask them questions and listen to their answers.
• WkndTriathlete 5y ago
  Ugh, so many bad practices being defended in the comments here. I've been on both sides of the table: - As an interviewee, my experience is that companies that use coding exams are not places I would want to work - companies that use these exams have a poor hiring process or any technical interviewers themselves either are not proficient with the technologies they are interviewing for or cannot discuss the technologies effectively. Any of those cases is a big red flag for me. - As an interviewer, there are two problems with coding exams: either they are so short that they can only test CS knowledge instead of the actual required skill (which is translating the business problem domain into code) or they are so long they impose too great a burden on the interviewee. ("Oh, don't spend more than 4-8 hours on this project" is not an acceptable burden in my book.) Further, the hiring manager is not the one that should be evaluating the technical ability of candidates. (Well, unless the hiring manager is hiring Employee #2 for a start-up, but that should be more about trust and hiring someone with a track-record of success.) The technical staff should be evaluating the technical capability of the candidates, and the technical staff doing the interviewing should have both the technical knowledge and communication ability to easily screen any candidate in 30-45 minutes of casual conversation, tops. The hiring manager should be looking for team fit, communication ability, and other soft skill abilities the candidates have. Anecdotally the businesses I've encountered in the Upper Midwest that do actual interviews instead of coding exams all have solid developers as employees. The businesses that use coding exams have the second-rate (and lower) developers writing code. No other field in engineering, barring positions requiring the professional engineer's exam, requires candidates to go through an engineering-specific exam. The employment contracts that are drawn up usually include a 90-day probationary period in which the hire can be fired again for non-performance. I don't see why software positions should be treated any differently, since that hiring process has worked (and worked well) for other engineering fields.
  • sasquatch_9 5y ago
    >The businesses that use coding exams have the second-rate (and lower) developers writing code. So FAANG has second-rate developers? I would say the opposite anywhere that does not test has second-rate developers as they let anyone who can talk the talk in. E.g. I have seen senior 5+ years tenured engineers at non-FAANG companies with weak coding tests, write O(N^2) code in production; then I took a look at it and reduce it to O(N) and N was not small it was pushing 50,000 and was only expected to grow...
• mitchellst 5y ago
  Hiring manager of hiring managers here. This thread is full of managers pointing out it's hard to work without the tests and IC's who don't have much empathy for the constraints managers are under. Basically, getting a job for a senior developer is the easiest thing ever to require so much work. You're in hot market demand, but if you spread your search out to include multiple companies, the hours of screenings, interviews, paperwork, and coding challenges start to really add up. Clearly that's frustrating. For managers, hiring a bad fit is simply disastrous. Turning around and firing them is never easy. Yeah, it's slow, and that person drags your team while it happens. If you can make it fast, that has its own affect on your team culture. I understand this is an unsympathetic observation, but: firing people is emotionally hard on managers. So, yeah, we'd rather pick right the first time than play a "fire fast" iterated numbers game. I'd propose that the existence of the test isn't the problem, it's all the stuff around it. As a hiring manager, my job is to ask you to do this thing you don't want to do, and to explain why it's important for the company and the team. This is the first time, but not the last time we'll have a conversation like that. You should note whether or not I'm good at it and whether you'll tolerate that kind of thing from me. Because as an employed engineer you'll end up tolerating those requests from someone. As a candidate, you can stand out by making a deal. "Hey, I'm really excited about this opportunity. But I have several companies in my process plus I'm still employed at my current job. I understand your side—a resume doesn't always tell you if someone can code, and I definitely don't want to work with other people who can't pass something like this. Still, I need to manage my time well, and this is too much. Is there any way we could cut the size of the challenge in half? Or, I've got an open bug on an open source project I contribute to. Can I work on that, put in a PR, then discuss that in the interview? Trying to get us both what we need here. Thanks." Personally, I'd respond really well to a discussion like that, and I think all my hiring mangers would. And the discussion itself would make me want to hire you more: you're a team player, you're transparent, you aren't dismissive of me but you'll advocate for yourself.
• kodah 5y ago
  Candidates lie quite a bit and the rest of the interviewing nightmare trickles from there. I've had two candidates show up for interviews, who used the title Software Engineer on their resume, who couldn't write any code. That was a shocking discovery at the time and I'm someone who has worked in SRE alongside Operations folks who faked their way into SRE titles. That said, the state of interviewing is completely unacceptable. The algorithm tests ensure that mostly college attending candidates pass them. Take home exercises are very burdensome for people with kids. The company LightBulb that did a LaunchHN recently I think gives us the best hope for improving interviewing going forward.
• geebee 5y ago
  Oof. The online test. Probably the auto-graded kind. The kind that pushes all the inefficiency of the process out on to the developer. Well, take it if you want. I'll never do it. But then again, I have missed out on what might have been great opportunities because of that.
• gdfgjhs 5y ago
  I find it insulting but that's the way it is. The problem is it is very hard to fire a bad hire, sort of joining a fraternity or sorority. So they add rituals before you join them. If you can take the abuse for joining them, then you should be able to conform to their way of life/work. Unfortunately, you have to play the game or start your own company.
• drewcoo 5y ago
  Frankly, I wish there were a way for me to give a coding test to devs at companies when I'm applying. The gates to company entry are huge and solid and golden. The court inside the gates is often unkempt and dirty and strangely vacant.
• dennis_jeeves1 5y ago
  Just putting it out there: Are their companies out there that do a cultural fit/assessment (it's nonsense of course, they just want to make sure they like you) BEFORE proceeding to a technical interview? Why not save the candidate's AND interviewer's time? Agreed that this might be a legal minefield, but for fucks sake, look at all the anguish the widely practiced interviewing practices creates.
• muzani 5y ago
  Interviews are two way. 80% of people in the applicant pool are hopeless. And so are 80% of companies hiring for these spots. You should probably expect to turn down a number of companies you applied for. If you're at a senior level, the dynamic is reversed. There's probably more rejection by applicants than by companies. Interviews filter for a certain kind of candidate. If an interview is all leetcode problems, then you end up with an engineering culture that only knows how to solve leetcode. If the process favors people who get shit done in 2 hours, then the engineers will mostly be people who only know how to hack things in 2 hours.
• rvba 5y ago
  If you dont know that lots of people lie in their CVs then you are not a senior engineer. (Also how come a senior engineer never did any recruitment to learn this?). Also you must be very lucky to not know that often the senior engineers are a problem - they got promoted duebto seniority, not any actual skill.
• rcarmo 5y ago
  There is a burgeoning culture of “automatic assessments” (and startups racing to develop and sell them to other startups) that mirrors the old aptitude tests thwt HR firms used to do when screening candidates for, say… accounting jobs (back before computers were a thing). HR people love them because it saves them time and thins out the herd, some tech companies believe it sets up a minimum threshold to cull out inexperienced candidates, and, let’s be frank, many hiring managers are too lazy (or powerless) to either understand how these things work or fight the VP who’s been told “spend X and save X times 1000 in hiring the wrong people”, because who designs these things pairs them with a massively advantageous risk/savings model. And most orgs will just spend the money on these tests instead of hiring people properly. It’s like Hackerrank and their zillions of wannabes, who’ve spawned an entire subculture of cheats and people who can code just barely enough to solve canned problems, instead of actually understanding what the computer is doing. (I politely back down from anything that even resembles something like this - like the old Google quiz interviews - because it tells me a lot about how the hiring process works and how much of a meat puppet HR would like you to be in that kind of company.)
• pyjarrett 5y ago
  I hate timed coding exams. The "Here's a thing to write, send it to us in a week, it should take a few hours to do" sort of thing seems reasonable. As an interviewer, I do a code review of that (or of GitHub code if there's enough available without an exercise), and then send the interviewee the EXACT QUESTIONS based on that review, that I'm going to ask, a day or more before the interview. I explicitly tell them that they're allowed and encouraged to research and can even bring prepared notes. This process turns random questioning into, "OK, I saw some code, think through my questions about it and let's have an interesting discussion about it." This gives people time to look things up like you normally would when working on a project. It also seems to ease the candidate's down quite a bit, because some people are super great at their jobs and just don't interview well.
• spazmoose 5y ago
  We had a conversation about this a short while back in a local Slack channel, and my personal opinion is that I have never been fond of coding as an exercise for a technical interview, especially if it is a whiteboarding exercise in front of others or a timed event. Due to their simplicity, they offer little beyond basic syntax or entry level abilities if you're looking at a short timespan, and anything more complex is probably prohibitive if you're interviewing multiple candidates, because the code has to be reviewed. Take home coding exercises are a bit better, but someone still has to review it, and who has that kind of time if they are interviewing a lot of potential candidates? Instead, if a coding exercise is necessary, I would lean toward having the candidate perform a code review on a known bad piece of code, looking to see how they spot inefficiencies, and then have a separate technical conversation, akin to refining a project that someone would work on. It would be more real-world, and I think you could gauge their thinking process better, and still get an idea of the complex thought processes involved with senior development.