Maybe that's just me being too old for that kinda' crap.
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
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
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.
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.
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.
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.)
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.
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.
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
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.
"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.
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.
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.
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.
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."
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.
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.
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).