Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical interview performance is kind of arbitrary

blog.interviewing.io

Post reply on HN
Print view View original

211–220 of 246 posts

Re: Technical interview performance is kind of arbitrary

#211

Post by arjie »

maxaf wrote: post #100
superuser2 wrote: post #90

Earlier quoted context omitted.

Option B is explicitly prohibited in your employment agreement for most salary workers. I would never consider working for a company that required me to violate a contract just for a chance to work there.

In my experience this hasn't been the case. The closest I've come was an employment contract that required me to notify my employer of any work on the side. This has happened only once over more than a decade of work in this industry.

GitLab has an employment offer example up on their website¹.

Here's the part that's relevant to the discussion:

> While you render services to the Company, you will not engage in any other gainful employment, business or activity without the written consent of the Company. While you render services to the Company, you also will not assist any person or organization in competing with the Company, in preparing to compete with the Company or in hiring any employees of the Company.

I'm sure we can have both charitable and strict interpretations of "while you render services to the Company" but only a lawyer can probably tell what that means. Did you not have such a clause?

¹ https://about.gitlab.com/handbook/contracts/

Re: Technical interview performance is kind of arbitrary

#212

Post by arjie »

maxaf wrote: post #62
eropple wrote: post #48

Earlier quoted context omitted.

> 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. The approach you describe strikes me as shortsighted as well as to no small degree selfish. I don't do take-home tests, as a rule, for one overriding reason: my time is too valuable, and I have so much less of it to expend in discretionary fas…

I have one major disagreement with you: > I have a Github profile with more than enough stuff on it Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not…

Well, there's a pretty big difference between 2 hrs and 4 hrs. Most people are applying to multiple places when they are looking for a job. So let's say 3 places a week. Now this is the difference between 6 hrs (already a lot) vs. 12 hrs (practically insane) per week on this stuff.

And at the end of all that work, the candidate receives a binary yes/no. 1 bit of information. On the other hand, the 6 hour 'beatdown', as you term it, gives the candidate an incredible wealth of information. They see what their prospective coworkers are like, what the office is like, how people interact with each other, maybe what people talk about over lunch. So 3 interviews with 1 bit of information (12 hrs) each or 2 on-site interviews (12 hrs) with a hell of a lot? What's the rational choice?

And I'm not against programming assignments, but 4 hrs each?

Re: Technical interview performance is kind of arbitrary

#213

Post by superuser2 »

maxaf wrote: post #100
superuser2 wrote: post #90

Earlier quoted context omitted.

Option B is explicitly prohibited in your employment agreement for most salary workers. I would never consider working for a company that required me to violate a contract just for a chance to work there.

In my experience this hasn't been the case. The closest I've come was an employment contract that required me to notify my employer of any work on the side. This has happened only once over more than a decade of work in this industry.

"During your Employment, you shall devote your full business efforts and time to the Company. During your Employment, without written permission from the Chief Executive officer, or one of his direct reports, you shall not render services in any capacity for any other person or entity and shall not act as sole proprietor or parter of any other person or entity..."

As I understand it, this is pretty much the nature of being salaried (as opposed to hourly).

Re: Technical interview performance is kind of arbitrary

#214

Post by brianpan »

turar wrote: post #98
maxaf wrote: post #71

Earlier quoted context omitted.

Would you have preferred to spend a whole day on an inconclusive onsite interview? Or perhaps a phone screen during which you're asked to implement a hashtable for the umpteenth time? As I said in another comment somewhere in this thread, one day people will learn to do this right. Hopefully this will happen before programmers as a profession have decided to never take code tests again.

Yes. The onsite means the company is investing just as much time and effort into the process as the candidate.

It's not just the investment. In a 4 hour take-home I learn close to nothing about the company I am applying for. In a 4 hour on-site I see the workspace, talk to employees, etc.

Re: Technical interview performance is kind of arbitrary

#215

Post by kevan »

TallGuyShort wrote: post #11
staunch wrote: post #6

Most interviewers don't ask enough technical questions to have any idea what a candidate knows or doesn't know. If their one or two questions happen to be something the candidate knows well, they'll call them a genius. If they happen to not know, they'll label them an idiot. You can learn a lot more from 20+ rapid fire questions than forcing a candidate to eek out an answer to something they're not familiar with. And…

Along these lines, I start out with very broad questions. Something like, "tell me how you'd troubleshoot a web service that's suddenly not accepting connections / suddenly performing badly." Different candidates will focus on different aspects of that problem depending on their background: low-level networking, cloud environments, application-level problems, databases etc. Based on their resume, I like to see if the…

At my favorite tech interview we debugged a real prod issue they had a few months before. The interviewer spent a few minutes sketching the basic architecture of the system on the whiteboard and then started with the customer complaint:

"Sometimes users stop getting chat updates, refreshing the page fixes it."

From there I went explained my debug steps and he acted as an oracle when I took an action

Me: "Have messages been lost or does a page refresh always fix it?"

"Messages haven't been lost"

Me: "I'd check our logs for anything obvious errors"

"Nope, everything appears normal"

...

Me: "What sort of logging do we have with the websocket vendor?"

"They have a live console but don't provide any persistent logs"

Me: "Can we scrape that to get logs we can correlate to the errors?"

"We did that, didn't find any errors around the time a user had an issue"

....

Me: "Can we try X Y Z to reproduce?"

"When we did that we discovered that the disconnect only happens after a user has opened a navbar menu."

... "As it turns out there was a click handler on all navbar buttons that disconnected from the websocket. The buttons used to directly link to different pages, now some of them had submenus and opening that submenu caused chat to hang."

Re: Technical interview performance is kind of arbitrary

#216

Post by tarsinge »

splintercell wrote: post #170
muddyrivers wrote: post #155

Earlier quoted context omitted.

The current common interview practice is more like a programming contest. The candidate has to figure out a problem and finish it within ~30~35 minutes. Very competitive, but with little engineering involved. I like the "Software engineering fizz buzz" idea. For backend engineers, I usually ask the candidate to implement a commonly used API in a language she/he is most proficient at.

The way I envision "Software Engineering Test" as a 20 questions exercise. The interviewer will give a simple user story to the user. "As a user I want to be able to add two numbers". After the candidate implements that, "As a user I want to be able to subtract two numbers". At this point look how the candidate continues. If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if h…

It looks like a test for how good you are at over engineering things. Making classes for data processing functions is OOP wrongly done in my opinion. Simple functions or even a lambda seems more appropriate, ability to make it simple is seems less impressive but it takes experience. Plus what if your language is functional and doesn't even have classes?

Re: Technical interview performance is kind of arbitrary

#217

Post by [deleted] »

turkishrevenge wrote: post #205
marknutter wrote: post #115

Earlier quoted context omitted.

I once was called into an emergency meeting by the CEO of the company I was working for the time. When I entered the room, all of the top brass were seated around the table, some visibly agitated. The CEO proceeded to hand me a single black whiteboard marker as he stated "the fate of the company depends on you". The problem was outlined by a fellow engineer and it was explained that I had 10 minutes to solve it, or w…

I believe you, but this really reads like something on /r/thathappened.

[deleted]

Re: Technical interview performance is kind of arbitrary

#218

Post by codeisawesome »

turkishrevenge wrote: post #205
marknutter wrote: post #115

Earlier quoted context omitted.

I once was called into an emergency meeting by the CEO of the company I was working for the time. When I entered the room, all of the top brass were seated around the table, some visibly agitated. The CEO proceeded to hand me a single black whiteboard marker as he stated "the fate of the company depends on you". The problem was outlined by a fellow engineer and it was explained that I had 10 minutes to solve it, or w…

I believe you, but this really reads like something on /r/thathappened.

I had the same reaction as you - until I realised it was sarcasm.

Bravo, parent, bravo.

Re: Technical interview performance is kind of arbitrary

#219

Post by acheron »

grillvogel wrote: post #135
dms105 wrote: post #120

Earlier quoted context omitted.

I like the law/programming analogy, but theres probably more of a margin for error when your job is to convince some people, depending on if you're prosecuting or defending. If you make even a small mistake when programming, it could break your entire program.

if you make one "small mistake" while lawyering an innocent person might get sentenced to death. why do so many programmers think their job is inherently more special and difficult than everyone else's?

There are easily many more programmers who work on potentially life-or-death systems than there are lawyers who litigate death-penalty cases in court.

Re: Technical interview performance is kind of arbitrary

#220

Post by dragonwriter »

acheron wrote: post #219
grillvogel wrote: post #135

Earlier quoted context omitted.

if you make one "small mistake" while lawyering an innocent person might get sentenced to death. why do so many programmers think their job is inherently more special and difficult than everyone else's?

There are easily many more programmers who work on potentially life-or-death systems than there are lawyers who litigate death-penalty cases in court.

> There are easily many more programmers who work on potentially life-or-death systems than there are lawyers who litigate death-penalty cases in court.

But potentially life-or-death cases are not limited to death penalty cases, they are just the most obvious class of cases that are life-or-death.

There are far greater numbers (and proportion) of lawyers who work on potentially life-and-death work -- not limited to death penalty cases -- than programmers who do so.

Post reply on HN