Hacker News Reader

Comment by 0xmohit | Hacker News Reader

https://twitter.com/thepracticaldev/status/71639058321702912...

So true. So, so true.

So true that I often question technical interviewing practices that look solely for ability to memorize complex algorithms exactly, vs ability to seek out an even better solution and apply it effectively.

At a previous job I put this in to practice. I would give interviewees a short list of questions on a piece of paper and after the interview they could use a browser and take as much time as they needed to answer the questions. Some were logic type questions that would be difficult to Google, some were just process questions that very few people would know off the top of their head but should be able to Google. The idea was to see if someone could find answers when they ran in to problems. Got some great hires using that technique (and avoided some hires that might have been disastrous!) HR killed it, though.

Open book exams are known to be tougher!

I don't mind giving candidates access to language reference manuals, man pages and such.

May be so. These were pretty easy questions, though. Like 'What steps/commands would you use to reset the password on a [Make] [Model] managed switch through the serial port?' Very easy to Google.

Surprisingly, some people couldn't get the answer right even using Google.

> Surprisingly, some people couldn't get the answer right even using Google.

Never underestimate anybody.

I've seen numerous examples wherein folks would copy/paste an obviously inferior answer (or even incorrect) from a Stack Overflow post that contains a much better answer.

You mean never overestimate anybody. Or maybe, "You can never underestimate anybody."

I meant what I read somewhere long time back:

  Never underestimate the power of human stupidity.

This rings a bell right now. :-)

Last week I integrated with a service using (shudder) SOAP.

I tried the XML call with curl and couldn't get it to work. I cursed, I frothed. The reply error was some Java dump, not helpful.

It took me embarrassingly long to realize I got the HTTP header fields for SOAP from something wrong I googled -- it worked when I copied the header line from old code I wrote before... :-) :-(

My approach with Stack Overflow is to never copy-paste but always re-type by hand. This forces me to understand each line of code and its behavior (and double-check any errors). I can't recommend this enough.

HR should have no input into technical hiring processes. I don't understand the thought process by which they feel they should have this authority.

HR interference was a MASSIVE pet peeve of mine at a previous employer. I eventually was able to strong arm them into forwarding me all resumes directly, but it was a battle.

Agreed, it was very frustrating. They required that we follow the exact same set of interview questions for every candidate, verbatim. We were not allowed to ask technical questions or do any kind of proficiency questioning / testing, etc. When pressed, they said that we could ask follow up questions to their set of questions, and that we should be able to determine technical proficiency by inquiring about past experience.

Giving your HR group the benefit of the doubt, in my experience, when the pendulum has swung that far to the "process" side, it's because the company has been burned in some way in the past.

... And retaliates by burning everyone in it every day. That said, ive read more positive HR stories in this thread than I've seen everywhere else combined.

Not being allowed to ask technical questions sounds like a big problem.

Asking everyone exactly the questions at least seems like an attempt to ensure a level playing field for all candidates and eliminate bias that interviewers might not even realize is occurring.

Before starting my development career, I studied quite a bit of HR as part of my business degree. There was a fair amount of emphasis on a uniform, structured interview process largely to help eliminate interviewer bias.

The tech industry, and software companies in particular, are often accused of discriminating on the basis of age and gender. And I think that it does happen more than people want to admit, but I don't think it happens intentionally. People are terrible at recognizing their own biases. It's often not even conscious.

If we, as an industry, want to do something about it, we might consider listening more to what good HR professionals have to say. Yes, there are some HR people who are narrow minded and care more about rigidly adhering to process than about getting the best results. There are plenty of developers who meet that description, too.

I've heard so many developers dismiss all HR people as "HR drones" which is ridiculously unfair. If we actually care about eliminating bias from the hiring process, there's a lot we can learn by talking to good HR professionals. And yes, there are plenty of good ones. Some of them care just as much about a technically (and ethically) sound hiring process just as we care about good development process.

This article, though it is short and only scratches the surface, gives some idea of what I'm talking about: https://www.recruiter.com/i/4-types-of-interviewer-bias-and-...

Technical questions are fine, and I'd argue that asking all candidates the same questions is one way to help eliminate bias. In combination with this, we could ask interviewers to rate the candidate based on their answers to the technical questions. If we wanted to go further, we could also ask people who didn't meet the candidate personally to rate the candidate based on their technical answers, without revealing any of the candidate's personal information (age, gender, ethnicity, etc.) and then compare these ratings. The comparison might help us see if our interview process is as fair as we think it is.

None of us want to believe we're biased interviewers, but from what I've seen of many technical interview processes, there are many tech companies who strongly believe their interview process is unbiased, but don't have much (or any) data upon which to base that belief.

But interviewing isn't about asking someone technical questions. It's about whether the candidate can get work done. I'll never understand the massive debate about the effectiveness of work-sample tests -- no questions, just "Here is some work. Can you do it?"

I've seen how effective it is. And how many people rebel against it. No idea why. Ego, sometimes. It's unfortunate.

I agree that tests like that can be a great way to determine how effective a candidate might be.

I think the same principle applies - if possible, giving everyone the same work sample tests provides a good basis for comparison between candidates.

As long as it remains a secret. Once it's out there it stops being that useful.

I've been lucky to have had good HR recruiters, though there was a time when some routinely sourced me really awful candidates and resumes. It got so bad that I started sourcing them on my own. I was so successful that - to their credit - the recruiters asked me to train them on how I did this. These techniques later became standard practice across the company. It was awesome of them to be so open-minded and adaptable.

I recently went through a final-round interview process, and a large piece of the technical part of the interview involved handing me a laptop connected to the internet and the interviewer saying "Build a REST API that can handle these 4 curl requests and respond correctly. Use any technology you want. You have access to Google and anything else you can find. You have about an hour, I'll be back to check on you in 20 minutes. Go!"

I felt like this was SUCH a better test of my abilities as a professional programmer versus remembering specific algorithms or reciting "best practices" for X, Y and Z.

That is a good way to see how someone goes about approaching actual work. Which company was this?

This was a great test - I just gave myself this test (I'm usually working in embedded systems so this wasn't something I do all the time) - completed in 30 mins, most of it waiting for installs or reading the web. I think it might be possible to add postgres and OAUTH2 into this as well (assuming one can grok OAUTH2 in 30 mins...).

Oh man, I'd probably spend the first half of that time adjusting to somebody else's development environment, and the second half troubleshooting all the runtime errors caused by various ':w's and 'u's scattered throughout the code (unless it were an OS I was familiar with, I'd hesitate to implement this in a language that requires configuring a compiler & build system. Fortunately, most web software seems to already be written in portable languages).

I've made this comment before, but people don't seem to understand how used one can get to a specific setup.

I've spent for example 20 years working with MY Visual Studio setup, with a normal desktop keyboard and mouse. Then I get handed that crappy flaptop that no one wants to use.

You do what you can, but still your effectiveness basically drops by 40%.

Kudos to the interviewer in this example though.

The better solution I've seen to this problem is for them to warn in advance that something like that will happen, suggest bringing your own machine with you, and point you at a skeleton git repository to start working on.

Reply on news.ycombinator.com