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

The Technical Interview Rift

blog.techmasters.chat

Post reply on HN
Print view View original

51–60 of 97 posts

Re: The Technical Interview Rift

#51

Post by tdumitrescu »

pklausler wrote: post #22

OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community." The companies constitute the community. The community comprises the companies.

"In addition to its original senses, dating from the 15th century, “to include” and “to consist of ” ( The United States of America comprises 50 states), comprise has had since the late 18th century the meaning “to form or constitute” ( Fifty states comprise the United States of America)." http://www.dictionary.com/browse/comprise

Re: The Technical Interview Rift

#52

Post by jdmichal »

Futurebot wrote: post #48
jdmichal wrote: post #31

Earlier quoted context omitted.

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.

Absolutely. This is a shift that would need to made in hiring just as much as education. I consider the split pretty analogous to drafters vs architects. Both jobs have roughly the same output -- drafted plans. But the architect is properly trained and licensed to determine things like feasibility, safety, regulatory compliance, etc.

Re: The Technical Interview Rift

#53

Post by jeffasinger »

Pyxl101 wrote: post #20
lisper wrote: 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…

At one company that did a take home, the first step of the onsite was some pair programming to add a few new small features to my submitted solution.

Re: The Technical Interview Rift

#54

Post by pklausler »

tdumitrescu wrote: post #51
pklausler wrote: post #22

OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community." The companies constitute the community. The community comprises the companies.

"In addition to its original senses, dating from the 15th century, “to include” and “to consist of ” ( The United States of America comprises 50 states), comprise has had since the late 18th century the meaning “to form or constitute” ( Fifty states comprise the United States of America)." http://www.dictionary.com/browse/comprise

This is like legitimatizing incorrect usage of "literally" or "unique" because some people don't know their definitions. It is ambiguous and sloppy to misuse a word as if it means its antonym.

Re: The Technical Interview Rift

#55

Post by soVeryTired »

jasode wrote: post #29
kafkaesq wrote: post #10

Some useful advice, but something about the overall tone seems a bit off: You are a manager and it’s time to hire a new developer to join your impressive team of A+ players. That's where things started to go of course. You're not an "A+ player", and most of your team aren't "A+ players" either. You're just human beings doing the best you can and (hopefully) trying to improve a bit each day -- like anybody else. No on…

>, but something about the overall tone seems a bit off: [...] You're not an "A+ player", and most of your team aren't "A+ players" either. I believe you misinterpreted the author's backhanded "compliment" about teams' _self-proclaimed_ "impressive A+ players" . His tone is sarcasm if you combine it with the repeated fixation on "Fibonacci" puzzles in the rest of the essay: - quote: , what possible insight does quest…

But he also says "After all, the primary purpose of doing technical interviews is to ensure A+ players are identified and are persuaded to join your team. If your process is preventing this, then you are doing it wrong."

That doesn't sound like sarcasm to me...

Re: The Technical Interview Rift

#56

Post by throw_away_777 »

AvenueIngres wrote: post #41
mancerayder wrote: post #35

Earlier quoted context omitted.

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.

You definitely are filtering people, unless you accept everyone who goes through the usual (tedious) interview process. This interview process is quite noisy, so being able to skip it gives a clear advantage. Whether or not this is a good thing is another question, but don't claim you aren't discriminating against people who don't code in their free time.

Re: The Technical Interview Rift

#57

Post by kafkaesq »

x0x0 wrote: post #34
kafkaesq wrote: post #16

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 (1) Better to say you were unable to "remember", rather than a "figure out". No one ever "figures out" things like the Newton-Raphson method over the phone -- not even people like Isaac Newton or Joseph Raphson (substituting whatever comparable…

figure out in the sense of discover? sure Figure out in the sense of work out the updates, particularly for f:R -> R, if you already understand NR? That's totally doable in 5 minutes with paper; it's just figuring out an x intercept. And remembering/finding f such that f(sqrt(2)) = 0 I've also been asked, in person, the derivative of x^x. Hope you remember logarithmic differentiation! It's not like, had you happened…

"Discover" in the sense of "derive ab initio, truly never having seen an iterative root-finding method, or anything analogous to it" -- like Newton and Raphson both did, separately -- I highly doubt it.

Re-derive your (or my) perhaps-more-than-a-bit-stale-by-this-point derivation, from way back when, under non-interview conditions? Yeah sure -- assuming we were actual math majors, or among the 10% or of CS majors who are burned-in math types.

But under interview conditions? Unless the role explicitly requires an actual math background (or a CS background with emphasis in numerical algorithms), really quite a silly thing to expect of someone.

Re: The Technical Interview Rift

#58

Post by jghn »

matwood wrote: post #45
Pyxl101 wrote: post #20

Earlier quoted context omitted.

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.

This is how we do things as well. When I walk around our office I always see people looking at SO, Google and others. Why would I hold a candidate to a different standard?

Re: The Technical Interview Rift

#59

Post by AvenueIngres »

throw_away_777 wrote: post #56
AvenueIngres wrote: post #41

Earlier quoted context omitted.

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.

You definitely are filtering people, unless you accept everyone who goes through the usual (tedious) interview process. This interview process is quite noisy, so being able to skip it gives a clear advantage. Whether or not this is a good thing is another question, but don't claim you aren't discriminating against people who don't code in their free time.

This is a hard problem to which there are no easy solutions, only trade-offs to be made. Here I think that I strike a reasonable middle-ground providing I act in good faith.

Re: The Technical Interview Rift

#60

Post by jghn »

bdavisx wrote: post #26
Pyxl101 wrote: post #20

Earlier quoted context omitted.

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…

>Similarly, I have a habit of looking over someone's resume and picking a few random technologies they mentioned to discuss. I'm surprised how often candidates claim experience with a technology and can't really describe what they've done with it or discuss it intelligently I know what you're saying, but there's different levels. Several years ago, I read a couple of books on Hibernate/JPA and played around with it o…

I solve this by not using a skills block or anything like that. Partially because I think they're stupid but also partially because IMO it's a no-win situation to figure out what it implies, you'll always mismatch with some interviewer.
Post reply on HN