[throwawaysbdif]

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

[grogenaut]

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]

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]

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]

As I said, it depends. If it's text heavy, python or ruby (or perl) is likely the best. If it uses a lesser known data structure, maybe java with it's massive set of libraries. If it's bit twiddling or memory intensive, then maybe c++ is the right answer. But a lot of questions are trivial in ruby or python. 3sum can be done in 2 lines of ruby (how I wish it was one, would be cooler).

[steve-howard]

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.

[VLM]

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.

[st3v3r]

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]

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]

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.

[throwawaysbdif]

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]

Github makes it hard to tell what code is yours and what is something you just forked from somebody else.

[pbhjpbhj]

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]

"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]

Forks of GitHub repositories are marked as such, forks of projects hosted on other sites are not.

[throwawayblah23]

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.

[kafkaesq]

Last I ever heard.

By all means, please do "out" this company. Preferably as a response their next "Who's Hiring?" posting.

You'll be doing not only your fellow developers a huge favor, but the guilty party as well. Being as they need to get their heads around the fact that it's not in their interest to keep pulling off bad behavior like this -- and if they need a good dose of public shaming for the message to sink in, then so be it.

[Bartweiss]

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]

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]

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.

[garysieling]

How would the interviewer know that you wrote the code on your github?

[throwawaysbdif]

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 [e-mail]. 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]

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.