8 ms·

This whole hardcore quizzing and testing during interviews has to go. As far as I can see, all it does is create selection bias for people who memorize things o

• throwawaysbdif 10y ago
  I have been interviewing the last couple months and have the same opinion. I've been coding for years and have some pretty complex stuff up on my GitHub. I quickly found out that nobody looks at your GitHub, maybe 10% max. didn't matter that I had code from two weeks ago that did complex segmented locking on a concurrent hashtable. still got asked "what is threading" level questions at every place. After botching my first spate of interviews to stupid trivia I gave in and and read through a bunch of CSCI 100 course notes and "beginners guide to language x". My performance improved significantly. Ironically the most useful tutorials were the most basic "write a string to a file", as I had forgotten the classes for opening raw files in my three languages of choice (since nobody in their right mind has any business using those classes in a well designed WebApp). Doesn't matter that I could look it up in 5 minutes, they want it on the whiteboard with no googling. It's really easy to game such interviews as they require very little domain specific knowledge. If you say you know Cassandra or MVC, they'll just take your word for it... as long as you remember the classes for opening a raw file in r+w mode
  • steve-howard 10y ago
    I'm not shocked that nobody looks at your GitHub. Reading other people's code takes time and energy that a lot of people aren't going to spend if they have a ton of candidates to sift through.
    • throwawaysbdif 10y ago
      I'm not too surprised either, but I marvel at the amount of time wasted preparing and asking all the stupid questions when they could just look at my code for 5 minutes. Like, the main file in one of my libraries clearly uses concurrent locking, it even says so in readme.md . These were all last round on site interviews and we spent maybe 30 minutes of 2 devs time going over pointless stuff when they could just skim 200 lines of code. I think it's just that they have a process built up over time like "interview process.doc" and the devs don't want to make any waves going off script
      • TorKlingberg 10y ago
        Github makes it hard to tell what code is yours and what is something you just forked from somebody else.
        • pbhjpbhj 10y ago
          I thought it showed on the page if a project was forked; perhaps it makes fraud possible but wouldn't it be spotted almost immediately when you started work, if it wasn't spotted then arguably it doesn't matter.
          • Bartweiss 10y ago
            "Almost immediately when you started work" is precisely too late, though. If you hire purely off GitHub and get someone who lifted their code (instead of forking it), that's a huge price. Bad hires inflict huge costs up front, in wasted interview opportunities and startup costs and lost training time and morale hits and a dozen other things. "Fire fast" is popular advice because it's better than firing slow, not because unsuccessful hires are a sustainable event.
          • tjalfi 10y ago
            Forks of GitHub repositories are marked as such, forks of projects hosted on other sites are not.
      • throwawayblah23 10y ago
        This. A company, that advertised here on the last "Who's Hiring" sent me a code project. Wasn't quite enough to be 'you're doing a sprint item for us', but merited decent effort: - write a log monitoring console program that consumes an actively written to file - parse out specific parts of the log and aggregate them every 15s, display summary data - generate 'alert' notification when log messages/second (over the last two minutes rolling average) exceeds a threshold - remove notification when fall back under this limit - continue to generate stats while doing so - develop some unit tests to demonstrate alert logic This is, at least to me, _several_ hours of decent work. Certainly was nearly 500 lines of code. Submitted. "Thanks for this. We'll review." Last I ever heard. Thanks.
    • st3v3r 10y ago
      Yeah, but everyone says, "you need to have a GitHub. You're not serious about coding unless you have a GitHub. That's how you get jobs now."
      • Bartweiss 10y ago
        This is the issue I see. Every CodingHorror post and list of hiring tips demands a GitHub profile, with the implication that it had better contain useful, quality code. (And with a bit of a threat that you'd better not put any hacked-together, one-off project in there, even though everyone has some.) That's good, I see the value of it, and I also understand why interviewers don't want to read it. But new devs have every right to be annoyed when the industry-standard wisdom says that you have to have a thing which is never used. (The real answer is probably "New devs, get ready for the interview gamut. Experienced devs, call a contact and have a GitHub profile." But somehow that never comes up.)
      • scaryclam 10y ago
        As a hiring manager, I wouldn't say people are serious if they have a github account, but having one, which actually has original work in it, can show that the applicant has some interest in the industry beyond the money. If you don't have a github account, that's fine but you've got to show something else that can fill in the gap. Perhaps you're on bitbucket or even source forge. Or maybe you did summer of code. Worst case, tell me you can bring in some samples to an interview.
    • VLM 10y ago
      You'd read your friends code, right? Get a relationship, however minimal, with an inside contact, who shows his boss your code or conference presentation or whatever, he calls you and schedules an interview, then HR is told to find two bodies off the street to interview to make the hiring decision look good. Their code doesn't get read. I'm always kinda pissed when I'm brought in for that kind of interview and I figure out I'm just a placeholder. I've never said anything unpleasant but I have mostly politely walked out of interviews like that. Once its clear they just needed a checkbox and my showing up was the checkbox, theres no point in continuing. This is why sometimes you get callbacks for the craziest jobs you can imagine, like seriously, what in my carefully resume made you think I wanted to program FORTRAN exactly? You're hiring someone who's 90% of the time a graphics artist and all I know about photoshop is I'm familiar with the name? You need a .net programmer and what in my resume made you think that was me, let me know so I can burn it off the page with fire? Or there's a massive experience or salary mismatch, etc.
  • grogenaut 10y ago
    If you call it out to me during your interview during my standard warm-up question of "what have you done that you are particularly proud of it was challenging" and you don't bomb the rest of the interview then I WILL go look it up. I use things like this to remove any coding skills doubts during a debrief. Just putting it on the resume means there's maybe a 20% chance I'll see it. I'm usually giving the holistic system design question which the interviewee can take any direction they like they just have to go all the way down in one area. Jr devs on my team give the algorithms question much of the time and I make sure they're looking for the right things. Problem solving not memorization... Comfort in a language not trivial knowledge or formatting issues... Etc. They get sent to the interview class if they ask anything that is a named algorithm... Like three sum, tortoise and hare, etc and expect a candidate to derive it in a 30 minute coding section of an interview. T&H for example took 10 years for industry to derive. On a side note don't use a language you're not familiar with in an interview because you heard the company likes it. Use what you are solid in. Python and ruby and the like make most interview questions trivial. I cringe on the inside when people jump for c/cpp in an interview esp college hires as it seems to take longer to get fluent in these languages.
    • grogenaut 10y ago
      Note I'm not saying to do interviews in Python and ruby but if you're solid in one of them it's like real working pseudocode compared to Java c# c++. But use your a#1 solidest language. Unless u have more than one and that language makes a particular problem trivial.
      • brutus1213 10y ago
        I am most comfy with Python but think it is the wrong language for me to do coding interviews. When I was in school, I was taught intro CS in C and Java. I got tripped by a fairly CS 101 question even though I use Python very productively and regularly at work. In C or Java, I'd be able to knock off that question easily.
        • grogenaut 10y ago
  • garysieling 10y ago
    How would the interviewer know that you wrote the code on your github?
    • throwawaysbdif 10y ago
      Because I can explain anything about it. because the module is published on maven central under my name with my private key, hosted on a domain registered to me, on a GitHub account that's literally my name and a domain that's my last name. My primary email is firstname@lastname.com. A common theme with employers not checking GitHub is that the code could be lifted but in some cases it's glaringly obvious that it is not. I mean what if I'm applying for jobs using someone else's resume? What's stopping me from having my coder buddy do the phone screen for me? Why don't I just list a bunch of experience at companies that went under... Unverifiable. Use a bunch of references that are actually my roommate and my dad with Google voice numbers. At a certain point you just have to take things at face value. A GitHub is just as verifiable as every part of your resume that's not a school you went to or your identity
      • garysieling 10y ago
        That's fair. I don't think I've really seen readmes on the github projects people list on their resumes, let alone seeing their stuff published to maven. I do think the original article suggests that if employers put a lot of stock in github, the coding academy people would quickly have the "best" github pages.
  • Bartweiss 10y ago
    The whole issue is a really weird mixed bag, where good interviewers struggle to weed out awful candidates without harassing strong ones. "What is threading" actually doesn't bother me, because it's shockingly easy to find experienced backend devs who have no idea - even when they've used MapReduce! The file I/O one is far more obnoxious, because low-level file interactions are so rarely a good idea in most languages. In general, the right way to handle that remains "scripting" right up until it becomes "framework". And if someone expects that file I/O as part of a larger problem, they should probably accept anything sensible-looking or offer you a couple of method names like "getTextLine" to avoid the whole issue. The whole process is broken, certainly, but its broken on both ends.
    • throwawaysbdif 10y ago
      It definitely is broken. If I had to point it to a specific cause, I would say the main problem is that the industry is overrun with charlatans. The reason appears to be, when comparing CS to other professions, that so many schools do a poor job teaching CS. Also a factor is that tech jobs are so hot that everyone and their cousins wants pie in the sky dev money without putting in the effort to go to school or self teach. In basically every other engineering profession, a degree is your boarding pass. Not so in CS. I've met guys myself with masters that have no idea what they're doing. Mostly from private school but some public universities too. This in controversial but I think bootcamps are just going to make the situation far worse, if they haven't already. You can't teach everything in a few months so they concentrate on teaching people the skills they need to pass interviews. The real solution to this is to raise the standards in school for CS. The end result would be better interviews for people with degrees, and a clear path through school that leads to an almost guaranteed coding job. This is how it works for every other engineering job. I've been the guy to screen candidates before and the number of unqualified applicants is astounding. Like, barely more qualified than a random sample of the population. This is for a junior position that simply lists c#,MVC, 1 yr exp. Like a paragraph long job description with 3 requirements. Also listed that we would take Java exp with Jersey or spring boot instead. Over 80% of our applicants didn't meet those requirements. A good portion ~40% had never been to school or written code in their life. Of the remaining 20%, we would call and ask basic questions relevant to the stack. Just to make sure they're not lying basically. Like for c#, I would ask "what is nuget?" Type questions. Same with maven type stuff for Java guys. 50% of remainder fail multiple questions that anyone who wrote a single app in that stack would know. We now have 10 people out of the 100 that applied. Half of those aren't local, or lied about being local. 5 people. 2 of them didn't disclose that they need visa sponsorship. We pick 1-2 of the last three. Rinse and repeat nearly that exact process every time we need to hire anyone. Finding people with experience was even more daunting.
  • onlyrealcuzzo 10y ago
    Can confirm. I interview candidates on a regular basis. Company policy that we never invest time in checking a candidate's GitHub. But I do anyway. Because of the startling amount of people unable to explain the code in their repositories, I've found code quality / problem complexity / stack similarity alone to be a worthless metric. On the other hand, I've found it to be invaluable to get candidates to explain their code and why they made the decision that they did. It's exactly how a practice assignment works, except candidates are much more passionate about the choices and have invested more time in the project overall.
• drewrv 10y ago
  I'm gonna put on my tin foil hat and say: maybe companies interview like this in order to filter out the people who are too old for this kinda crap.
  • jankedout 10y ago
    This style is really filtering those who "don't have time," not by age.
    • brutus1213 10y ago
      As you get away from CS101, you kind of stop getting excited by it. I honestly don't care to look up how to implement quicksort at this point and would rather hack on some deep learning code in my spare time. Friends my age frustrated by interviewing are in the same position. Guess we're too old for a software job :-p
      • fapjacks 10y ago
        One thing I've found to help me with this ennui is to get excited about implementing the quicksort in another language, or using some newfangled pattern I'm not used to. I interview for fun and this helps to keep me engaged with the same old stuff.
• ericmcer 10y ago
  I am pretty young and it seems stupid to me too, this guy wanted to be a React Dev. If he was ever at work writing a binary search tree by hand, or writing his own quick sort function, then he would be wasting his time and creating a huge potential problem point in the code. This guy claims to have worked ~6 days a week for 3 months not to become a great full stack dev, but to become a great interviewee. Seems kinda backwards to me.
  • jackess 10y ago
    This is what drives me crazy. I'm a bootcamp grad, and I've been interviewing for 6 months. I've spent EVERY single day of those six months, (besides applying and networking and interviewing), working on coding, design, projects, and leveling up so I can collaborate with a team. This guy spends all of his time working on stuff that is considered "level 2", and he will make double what I end up getting. Frustrating.
    • sfaf 10y ago
      As a former bootcamp grad, please prioritize interviewing skills over development skills. once you get a good job, you can spend your free time on side projects but until then you need to practice on interviews not coding. Sadly it's the reality of interviewing and I hate it but there is nothing you can do until you are an experienced dev and can leverage your power to say "I refuse to work or interview at companies with dumb interviewing processes."
      • jackess 10y ago
        Fair point. Drives me bananas though.
    • walshemj 10y ago
      I have seen that for internal promotions too on guy I knew spent months working his promotion my boss wryly commented of course he has not done any real work for 6 months.
    • eachro 10y ago
• dominotw 10y ago
  There is zero chance of this happening until google/facebook stop doing it. This comment appears in every single interview/hiring thread for past decade. Only change I've seen is actually the opposite now there are 5-10 "rounds" of these quizzes even in a no name enterprise companies.
  • endymi0n 10y ago
    There is anecdotal evidence they did: http://qz.com/378228/google-is-over-those-ridiculous-brainteasers-but-some-employees-didnt-get-the-memo/ http://qz.com/378228/google-is-over-those-ridiculous-brainte...
    • dominotw 10y ago
      whiteboard binary tree coding != brainteasers, more like memory testers :).
    • ubernostrum 10y ago
      They weren't "over it" by last fall.
• onion2k 10y ago
  It selects for people who have recently been through an intensive learning process like a bootcamp.
• jhawk28 10y ago
  Is anyone more than a beginner if most of our technology is less than a year or two old?
• sfaf 10y ago
  This is on the onus of mid / experienced level engineers. The community should decide collectively that we don't interview at companies like this.
• TACIXAT 10y ago
  My questions are just there to get people talking about what they have done. Sometimes you ask about malloc and people haven't used it. I think they serve as a pretty decent initial screen. You choose some basic things that people need to know, then some more advanced things that someone who uses a language regularly would know, and ask until you have an idea of where their knowledge ends.
  • fapjacks 10y ago
    The problem is that if you picture what you're doing as firing into the darkness to probe something, you can't be sure if the handful of shots you take actually indicate you've reached "the end" of what you're trying to measure, or just some arbitrary boundary. And that boundary may not actually even exist at the point you measured it, depending on some huge number of factors unrelated to the actual job (for example how much sleep they got last night, or if they haven't eaten this morning and are hungry, etc).
• Bartweiss 10y ago
  Honestly, I think the reason its still around is because it approximates "write FizzBuzz", which people should be asking. People ask the 'quiz' stuff, successfully throw out some bad candidates who talked a good game on experience/theory, and assume its a good way to go. The ideal middle ground is probably to offer ultra-basic code problems, ideally before an onsite. It's awkward, but it really is necessary to filter the non-programming applicants. And by not trying to be clever, you don't create an incentive to memorize Rabin-Karp and generally acquire useless interview-only skills. Even for those still doing testing interviews, that's a good rule of thumb: if it was a paper-worthy insight originally, it's a ridiculous thing to make someone derive in an interview.
  • cr0sh 10y ago
    During one time I was using a recruiter to get a position, he had me interview with a company that used an online coding test as a first-level filter. I didn't know what they were going to ask, but I asked if he had any idea - all he would tell me was that it was something like good-ole "fizzbuzz". So I studied a bunch of stuff. Anything and everything but fizzbuzz (not that I needed to study that). Then I decided to go for the test - which was timed - and... ...fizzbuzz. I'm sitting there a bit dumbfounded - seriously? So I coded it up from memory; I could have easily pulled a solution down off the net, but I figured "what the hell - let's go old-school" on it. Also - if I just cut-n-pasted something in, and they saw "it took the candidate one minute to code it" - they might suspect something, then google search the plagiarized code. No good. So - I coded it up; it was in PHP, but the job was supposed to be for javascript/node (???) - so I wrote it as a class, then I spent the remainder of the time optimizing it - making it the fastest FizzBuzz solver I could, complete with tests and demonstration code. I took up the entire available time, and submitted that. I made sure to add proper PHPdoc comments to everything. ...and I got an "in-person" interview as a result. At the end of that was an another "live coding" session - this one using javascript for a "single page" app. They left me to it, and I got everything coded up inside of 15 minutes or so (there was a paper document laying out what the challenges were in the example code). They were watching my progress via screen sharing. Apparently I completed the task quicker than other applicants. I later learned that some applicants just sat there unable to do anything (not even google around for help!), or they would take convoluted paths to implementing the changes; not necessarily wrong answers, just not efficient ones - and would be sitting there doing this for a couple of hours (at which point the interview would be brought to a close). At the end, I got the offer. Ultimately - those are the kind of challenges I like - give me a real coding assignment, something close to what you are really working on. In this case, it was also in two different languages - so I could also help to "bridge gaps" between a PHP team and a javascript team as needed (added value for the employer). I really dislike whiteboard coding - completely unrealistic, and while I gather why it is a widely used tool, I think there are better ways to gauge a developer's competence for the position - and actual coding challenges to solve problems seems like one of the best ways to do so (though I also understand that it is very time consuming - so an up-front online timed challenge might be a good pre-filter for on-site or further interviewing).