Live data from Hacker News

The Technical Interview Rift

blog.techmasters.chat

41–50 of 97 posts

Re: The Technical Interview Rift

#41

Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is…

If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?

I am not filtering anyone. I use the signals that are available to me and which I can proof-check. Candidates who don't have public software forges (whether it is self-hosted Git, Gitlab, Github, or Bitbucket etc.) go through the usual (tedious) interview cycle.

Those who have don't because that would be redundant and a waste of time. This is simple.

Re: The Technical Interview Rift

#42
post #37

Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is…

Question for you: is your judgement of the applicant affected by whether or not they have an active GitHub repo?

Do you mean does it matter what version controlling tool they use or if they self-host? or if I would favour a candidate over another because of an active Github repository?

Re: The Technical Interview Rift

#43
post #37

Earlier quoted context omitted.

Question for you: is your judgement of the applicant affected by whether or not they have an active GitHub repo?

Do you mean does it matter what version controlling tool they use or if they self-host? or if I would favour a candidate over another because of an active Github repository?

The latter. Are you pre-judging a candidate because you can look at an open source repo instead of spending your day trudging through a tech interview?

Re: The Technical Interview Rift

#44
post #43

Earlier quoted context omitted.

Do you mean does it matter what version controlling tool they use or if they self-host? or if I would favour a candidate over another because of an active Github repository?

The latter. Are you pre-judging a candidate because you can look at an open source repo instead of spending your day trudging through a tech interview?

Mmh possibly, there might be a slight bias favoring them. The shorter the recruitment lifecycle and the quicker I can go back work on actual software engineering.

But then again, I hire lots of software engineers who have 0 OSS contributions but a shit-ton of industry experience. It does not matter if your last contribution was 4 years ago by the way. I am not looking for a full green activity graph (though it demonstrates consistency and discipline which are good) but rather for non-trivial, significant and well-crafted pieces of software so I can rest easy.

I don't go in trying to shoot down candidates. That's what whiteboard interviews are for. (:

Re: The Technical Interview Rift

#45
post #20
post #14

I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you ha…

I have tried using take-home tests before. The level of plagiarism was astonishing. And that's just the plagiarism I could detect. Even with a problem that's unique to my organization, I don't know how I could trust that the actual candidate themselves was the one who completed it, and that they completed it without unfair assistance (e.g. from other people). Similarly, I have a habit of looking over someone's resume…

We give take home problems and have no issue with plagiarism. In fact we actively say use the internet, books, etc..., and we still get solutions that are wrong or do not even compile.

The ones that do come back and look good, give us a starting point for the interview. If the person did just copy it from somewhere else they have will have a hard time talking about the solution and various pros/cons.

Re: The Technical Interview Rift

#46

From a Silicon Valley perspective, I didn't even know that this was something that companies considered not doing. 'Round here, a technical interview is guaranteed, it's more a question of if/when there will be anything else involved in the interview. Also, will it be a mundane technical interview, or more like 6+ hours doing Top-Coder style questions on a whiteboard? It used to be only Microsoft and Google were know…

Re: your last sentence, it's been common in my experience for at least the last couple of decades: that is, interviews for most of a working day, including at least one each focused on coding and design. Maybe my experience is unusual, but there were both big companies and startups.

Re: The Technical Interview Rift

#47
post #14

I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you ha…

"Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss." Out of curiosity, what type of developer position were you interviewing for?

Not quite sure how to answer that. Do you mean what was the label on the job req? I don't remember. I think it was "Senior software developer" or something like that. Is that what you meant? (And if so, why do you ask?)

Re: The Technical Interview Rift

#48
post #6

I view technical interviews that require algorithm solving and coding on a whiteboard as ridiculous. Primarily, because I am deathly afraid of them. And here is why. I own and operate two online businesses in the Radio Communications space that are the de-facto standards for our industry. I've coded both of them from the ground up in PHP/MySQL and manage all the day to day administration of these sites. Our infrastru…

You're argument is exactly what I call the difference between a "trade programmer" and a "computer scientist". You are describing the former, while all the Google-copycat interviews with algorithms and data structures are designed to hire the latter. As you said, trade programmers typically glue together existing components and frameworks. Sometimes, this is really all that's necessary, as you have proven with your b…

Part of the issue we have in software is that many companies interview for computer scientists (which they sometimes/often think they need) when they actually are looking for trade/craft software developers (but don't realize/admit it.) So many discussions around this topic reveal this fundamental mismatch in expectations/perceived needs/skillsets.

Re: The Technical Interview Rift

#49
post #14

I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you ha…

"Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss." Out of curiosity, what type of developer position were you interviewing for?

> what type of developer position were you interviewing for?

A square-root estimator developer position, of course.

Re: The Technical Interview Rift

#50
post #47

Earlier quoted context omitted.

"Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss." Out of curiosity, what type of developer position were you interviewing for?

Not quite sure how to answer that. Do you mean what was the label on the job req? I don't remember. I think it was "Senior software developer" or something like that. Is that what you meant? (And if so, why do you ask?)

I'm trying to figure out what software development job that would ever come up? graphics?
Post reply on HN