Live data from Hacker News

How I Interview

rkoutnik.com

121–129 of 129 posts

Re: How I Interview

#121
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

I can't upvote this enough. In the age of Github, if a candidate has an impressive body of work and can "talk the talk", a coding interview is wasteful, potentially misleading and insulting. As soon as enough candidates balk at them, companies will stop doing them.

I don't have a github account. All of my work previously was academic research, in which I have 10+ years of writing software, and currently it is all industry/proprietary. I thought the process I went through at my current company was great. A short phone screen, a coding test (~1 hour, with a week to complete), then an on-site, which took 1 day. The first two hours was a coding test, then I met with several teams, which were mostly high-level discussions and a few problem solving questions.

We're not architects, and nor do we have a certification system. There needs to be SOME way to probe a candidate's abilities, and it's not easy.

Re: How I Interview

#122

Earlier quoted context omitted.

> Why shall I still prove myself? Because we see candidates claiming that level of experience that cannot construct a simple for loop.

This. We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer, who can't explain the difference between a list and a vector (or when to use each), or give even a ballpark estimate for search/insert/remove times for a basic BST. At the same time, there are candidates who are technically good at coding, but terrible problem solvers. We do u…

> We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer...

Sounds like your expectations are part of the problem.

Why do you expect someone 15 years out of university, working in the now enormously wide software space to have your pet questions memorized? C++ is well known for being too big and needing to be subset(-ed). And, why not realize that such a person could become an expert in those questions in less than an hour of googling and reading?

The bigger problem is that companies are not willing to invest even four hours of training into employees!

Re: How I Interview

#123

Earlier quoted context omitted.

Two way street... assuming the guy was legit and confident, he'd have other offers lined up, and your company may have been the loser. I for one commend "whiteboard refusers."

Maybe so. We use whiteboarding as a jumping off point for discussion, not to implement trees or graph traversals. It is usually apparent within a few minutes if the candidate knows their stuff, and we move deeper. Additionally, there is always going to be an onboarding period, where the new hire is learning how our team does things. We spend a lot of time communicating and drawing out ideas on whiteboards. We need to…

Yes, the key is whiteboards are for diagrams, not coding.

Re: How I Interview

#124
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

This is why I prefer dating contracts to deep technical interviews. If someone shows enough promise in their CV and portfolio, and they're personable enough to sell themselves reasonably, then a 1-2 week contract to cover some real work is low risk and a better measure than trivial whiteboard problems.

... and you are guaranteed to only get people with nothing else going on in their lives, such as their current job or degree program.

Re: How I Interview

#125

Earlier quoted context omitted.

> Why shall I still prove myself? Because we see candidates claiming that level of experience that cannot construct a simple for loop.

I assume you're exaggerating slightly and that you mean "couldn't code as well as the resume suggested". How certain are you that the pressure of the interview (which often means broken concentration, poor sleep the night before, etc) and the unfamiliarity of the setting (even typing in a Google doc without proper spacing, syntax highlighting and auto completion can be incredibly disorienting) aren't a major factor?…

I don't think he's exaggerating; for the past 4 positions I've had to fill (at six figure comps) 80%+ of candidates with extensive resumes couldn't solve a simple recursion problem. We give the a notebook with an IDE and access to the language docs.

These folks with many "senior" level positions on their resume can't manage a task our last hire did in about 6 minutes.

Re: How I Interview

#126
post #100

Earlier quoted context omitted.

Native advertising ... in the comments.

I sincerely believe that living and working in Switzerland is nicer than anywhere else in Europe. With my comments I raise awareness for my side-income but primarily I try adding value to HN discussions.

I was joking. You are entirely entitled to give your perspective and advertise your services as long as you are transparent about it, which you were. No apologies or explanations needed.

Re: How I Interview

#127
post #50
post #31

Earlier quoted context omitted.

Homework exercises are a large burden on the candidate, so expect to half your pool for that reason alone. I only do about half or less of these, as most are crappy an unrelated to the job. I prefer to plan and do things thoroughly, not rush a solution out in a couple of hours. And to be honest asking for more than a couple of hours is more than you should be asking unless you are willing to pay.

We've had a pretty good response rate when asking people to do this. Of course, I totally understand why someone would say no. I'd love to find a better way to evaluate someone's skills, but absent a good public FOSS portofolio, what are my options?

Ask them to bring in a sample of work and discuss it? I have plenty of work I could show people, but I don't have on github. Admittedly that won't work for everyone.

Re: How I Interview

#128
post #38

Earlier quoted context omitted.

From the article : "but for many jobs there are too many variables involved day‑to‑day to allow the construction of a representative work sample. All our technical hires, whether in engineering or product management, go through a work sample test of sorts, where they are asked to solve engineering problems during the interview." Plus a number of other things according to the article. Sounds like they are agreeing wit…

> Plus a number of other things according to the article. Yes, combining methods works even better! It's far from saying that the best way is "to just talk to them".

It won't work better if you give candidates so many tasks that they think, "why bother?" and go for another easier job application process instead. People have other commitments, and we are often told there is a shortage of developers.

I have told potential employees as much after they asked for a sample of my work (which I had made available for that purpose), and they after that, they still wanted a three hour exercise done before I had even spoken to anyone.

In fact I am about to start a new job in the new year, I had a few interviews, and a couple of jobs that interested me sufficiently. One involved a three hour test, the other asked for a sample for my work. Guess which one I took? Guess which one the interviewer said they were struggling to find candidates?

Re: How I Interview

#129
post #64

Earlier quoted context omitted.

> doesnt result in a truely random distribution. It evenly distributes over 0-1. Removing .5, just distributes it evenly between -0.5 and +0.5. Sort basically says >0, the first option should come first and if I believe this still maintains a random distribution and is quite a tidy solution. Thoughts?

It can be extremely biased, and the results can depend on the sort algorithm, because what you're randomizing is the comparison results, not the order. Consider insertion sort: https://en.wikipedia.org/wiki/Insertion_sort As the list is sorted, elements are inserted from the back by finding the first element that the new element is smaller than. The last element to be inserted is the one at the end of the unsorted ar…

Ah, yes; that's a great point about the sort algorithm!
Post reply on HN