[HN Gopher] Routing the Technical Interview
___________________________________________________________________
Routing the Technical Interview
Author : zdw
Score : 100 points
Date : 2021-03-11 19:43 UTC (2 days ago)
(HTM) web link (lars.hupel.info)
(TXT) w3m dump (lars.hupel.info)
| k1t wrote:
| Terrible - which I assume was the point.
|
| The interviewer is clearly trying to do the right thing (own
| laptop, well known problem, your choice of tech) and the
| candidate is clearly talented, but the result is an unmitigated
| disaster.
|
| Obviously the interviewer should have provided more direction on
| the expected solution and the candidate should have focused on
| the simplest solution not the most unusual.
|
| But - I think these technical interviews are a lot more about
| "did the candidate approach the problem the same way you would?"
| rather than "did the candidate solve the problem?" than we would
| like to admit. (Again, probably the point of the tale)
| [deleted]
| Jaygles wrote:
| It read to me like a breakdown in communication. It wasn't made
| clear what the interviewer was going to get out of having the
| candidate solve fizzbuzz. The candidate demonstrated that they
| understood the question well enough. But it seems they wanted
| to demonstrate the technologies they were familiar with, rather
| than give a simple answer.
|
| From the interviewer's inner monologue it seems clear he wanted
| to prove the candidate had the most basic of skills for the
| job. It may not have been in the candidates mind that she was
| being asked such a simple question.
| runawaybottle wrote:
| The interviewer identified ego and arrogance very quickly,
| that's why the interview ended in his mind early.
|
| On a sufficiently relevant problem with reasonable difficulty
| and depth, I think these human elements would disappear as
| the problem set requires too much concentration.
|
| The interviewer wanted to end it because the question he
| asked was 'Are you too good for this?', and the interviewer
| replied 'Yes'.
|
| Which oddly, is an honest answer. I feel sad, if the
| candidate did the fizzbuzz as asked, they wouldn't stand out
| on any level compared to all the other people that did
| fizzbuzz as asked. God knows what the other evaluation
| criteria is. Clearly the resume and a background check is not
| enough, because they still fizzbuzzed her.
| milesvp wrote:
| Historically fizzbuzz was meant as a sanity check. Can this
| dev code a simple for loop with some conditionals in it? It
| was made up because some dev realized that too many poor
| candidates were making it to late stages of his hiring
| process. It's not meant to make candidates stand out, it's
| meant to be a practical filter. My personal experience as a
| dev is that my weakest teamates would visibly deflate
| anytime a work problem came up that required a simple for
| loop, so it's not a terrible bar to filter on.
|
| https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-
| de...
| runawaybottle wrote:
| I mean, we are saying that job experience doesn't mean
| anything based on anecdotes. The power of the narrative
| is intense.
|
| Some of you dealt with candidates that can't make it
| through a for loop, okay. This one ghost story dictated
| the entire direction of hiring.
|
| We are superstitious at this point.
| crescentfresh wrote:
| > these technical interviews are a lot more about "did the
| candidate approach the problem the same way you would?"
|
| honest question, I can only evaluate the correctness of a thing
| if I am familiar with the tech the candidate used to answer the
| question. Is this being unfair? Should I instead use the
| technical interview as a time to do as much information
| gathering as possible then take it back to the wider technical
| team for evaluation (provided I am not able to understand the
| technical answer myself).
| gumby wrote:
| If the candidate is using a tech you're unfamiliar with why
| are you interviewing them?
|
| In general* you want people who claim familiarity with the
| tech they will be using in the job. And if that is the case
| but you aren't familiar with that tech (you work on a
| different part of the stack, say) then you shouldn't be
| wasting their or your time having them code something up but
| instead you should be asking them about the parts which are
| the reason for you to be one of the interviewers.
|
| * yes there are several exceptions to this but they are
| exceptions.
| crescentfresh wrote:
| > If the candidate is using a tech you're unfamiliar with
| why are you interviewing them?
|
| did you read the article? Did you see the comment I was
| replying to? The gist is that a candidate may know other
| things that I don't and still successfully answers the
| technical question. Just because it wasn't using the tech I
| would have used to solve the problem doesn't mean they're
| unqualified. Not saying that's what you're saying, I'm just
| repeating explicitly what I only implied earlier.
| notapenny wrote:
| I wouldn't call it unfair, but if you're giving the candidate
| the option to solve a problem in their language of choice,
| you may run into this. You can either constrain the problem
| (we work with languages X, Y Z, so pick either of those) or
| still give them the option but use it in another way.
|
| For example, I work in front-end but I do most interviews
| across front-end, back-end, devops, always together with
| someone who's familiar with the domain or the specific stack
| we're recruiting for. In that case I'm there to test more on
| softer skills, but also its a good test to see if a candidate
| can discuss their domain with someone who isn't familiar with
| it.
| horsawlarway wrote:
| I think turn this on its head - You're not trying to evaluate
| the correctness of the thing, you're trying to evaluate the
| value add of the candidate.
|
| So instead of you trying to judge the value of the
| implementation based on some undefinable "technical
| correctness" have a discussion about the what the candidate
| has done/built.
|
| In this case - so many opportunities for great discussion
| around the tradeoffs of this approach:
|
| - What sort of load does it handle?
|
| - How portable is it?
|
| - What does developer setup for this environment look like,
| and what tools might you need to introduce the team to for
| them to be productive?
|
| - What might you do instead of this if we had requirement X,
| or challenge Y (ex: Network latency, computations/second,
| real time processing requirements, tooling/language
| constraints, etc)?
|
| - What are the scaling costs?
|
| - How do you put tests in place?
|
| - Etc.
|
| And then you expect to receive believable answers, and
| interesting conversation. Because at least in this case, it's
| pretty trivial to determine that the solution either does or
| does not work for at least a small subset of fizzbuzz.
|
| It can be really insightful to step back from the expectation
| that an interview is always "Interviewer is more experienced
| than interviewee" and instead just try to get an
| understanding of what working/talking with that person is
| like.
|
| For context - I've done about 150 software dev interviews
| over the last two years (principle/senior to junior/intern)
| benlivengood wrote:
| I think the point of the name Nephele (from Greek mythology) is
| that the candidate was sent to test the interviewer.
|
| > Obviously the interviewer should have provided more direction
| on the expected solution and the candidate should have focused
| on the simplest solution not the most unusual.
|
| The quote "The company does not need thinkers, they need doers.
| Mathematicians just examine made-up problems. But at this
| company, the engineers build real products for real people."
| from the interviewer suggests that the interviewer only wants
| to hire a devops person with a standard bag of tricks. The
| candidate has a bag of tricks in the relevant domain, but what
| a bag of tricks.
| davidw wrote:
| This industry is so screwy, sometimes.
| FifthSurprise wrote:
| "Nephele was a nymph moulded out of clouds by Zeus in the shape
| of the goddess Hera."
|
| /facepalm That's hilarious
| thaumasiotes wrote:
| Kubernetes is an intentional mistranscription of kubernetes
| (cybernetes), "helmsman". One assumes the spelling was chosen
| in an attempt to avoid the word "cybernetics".
|
| This is presumably why Nephele is confused when the interviewer
| interprets her self-reference "helmswoman" as a metaphor.
| hnedeotes wrote:
| the article is so good it just doesn't swoosh over, it beams
| little brains directly into the mothership
| dreamer7 wrote:
| This was the most engrossing article I've read in a while!
|
| Seeing the regex made me chuckle.
| Tallasatree wrote:
| "The interviewer couldn't help but notice her name, Nephele. It
| sounds Greek. But he didn't ask, not wanting to get off on the
| wrong foot with the promising candidate. He made a mental note to
| look up the name afterwards."
|
| Sad, I'm so guilty of doing exactly this - right away. I love
| etymology / genealogy, and am always curious.
|
| Its in no way negative, its literally just my curiosity taking
| over. Sometimes I hate how ridiculous we've become.
| acjohnson55 wrote:
| Sure, I have this curiosity, too. But in the context of being
| an interviewer, _it 's not about me_. My job is to fairly
| evaluate someone who's just trying to figure out if this is
| where they'll get their living from.
| gfaure wrote:
| This doesn't quite have the magical soul of Aphyr's ones,
| unfortunately. https://aphyr.com/tags/Interviews
| Ozzie_osman wrote:
| Not quite Aphyr but I found it witty and funny nonetheless. It
| was a fun read.
| madarcho wrote:
| It started off original enough I felt. It had an idea of its
| own, but very quickly just ended up copying the style, without
| really hitting home.
|
| Still, I can't fault the author for giving it practice, and it
| is amusing enough to read.
| Apocryphon wrote:
| It's like one of those "shooting your foot off in programming
| language" joke setups. Infinitely extensible for any
| roundabout way to solve FizzBuzz as possible. The ones
| imitating the originals' style might not be as good, but
| they're certainly welcome for capturing more types of
| unwieldy solutions.
|
| http://www.toodarkpark.org/computers/humor/shoot-self-in-
| foo...
|
| Alternatively, for a more tech interview specific, "how to
| measure the height of a building with a barometer?", fifth
| page from the end of this document:
|
| http://electroons.com/8051/ebooks/expert%20C%20programming.p.
| ..
| stitched2gethr wrote:
| I really wish someone like Joma Tech would turn this into a
| video. Hilarious.
| roland35 wrote:
| I am doing a lot of technical interviews, and it is very hard to
| find a good way to evaluate candidates. My current thinking is to
| ask a simple question which serves as a jumping off point to a
| bigger discussion touching on broader topics. I want to be fair
| to candidates and I certainly don't want the interview to be a
| trivia contest, but at some point I need to see if the engineer
| has a general grasp on how software works in a larger system.
| runawaybottle wrote:
| We've entered dating territory. I have to date you. I need to
| match you.
|
| Yeah, I'll just focus on Leetcode and focus on the big
| companies.
|
| I'm not dating you bro, it's just business. In other words,
| apprenticeship is dead (for awhile). We will not cater to you.
| josephg wrote:
| Yes; this can work well but its a little noisy as a signal.
| (There's plenty of room with this sort of assessment for
| personal bias based to creep in based on whether or not you
| like the person).
|
| My recommendation is to make a list of attributes you want in a
| good hire. (My list is something like: coding, debugging,
| communication skills, CS fundamentals, systems architecture,
| domain knowledge for the job, ...). Then spend 20 minutes with
| each of these areas brainstorming simple ways you could assess
| that skill in 20 minutes or so. (They're all assessable, but
| you need to get creative). Then after you've done that, design
| an interview from your notes.
|
| If you've got 1-2 hours for the interview, you'll end up with
| something much better than just having a chat. (Though on the
| flip side, if you've only got 10 minutes for an interview, a
| question like you suggest can be great.)
| acjohnson55 wrote:
| Totally agree. This is the basic approach I advocate for
| (https://m.huffpost.com/us/entry/us_7973484).
|
| I'd further argue that one of the best bets is to get someone
| to tell you how they have applied a skill in the past, rather
| than to try to figure out how you can get them to perform a
| facsimile of the skill in 20 minutes.
| jonstewart wrote:
| I wrote a regex engine, had to create a huge autogenerated test
| suite to flush out all the corner cases. The typical matching
| rules are fiendishly difficult--this is a nice illustration of
| how much deep magic there is in our quotidian stacks. I am
| looking forward to digging into the two complicated patterns to
| understand how they work.
| the_arun wrote:
| 1. What is fullstack mean in devops world?
|
| 2. Didn't her resume give enough information about her
| background?
| Apocryphon wrote:
| It seems like most of the commenters have not heard of Aphyr's
| technical interview series.
|
| https://news.ycombinator.com/from?site=aphyr.com
| CobrastanJorji wrote:
| Specifically, "Hexing the Technical Interview" has been a
| favorite of mine for a long while. The writing alone is a lot
| of fun, and the contents are appropriately horrifying.
| gostsamo wrote:
| What is more worrying, they didn't even click on the
| acknowledgement link at the bottom of the story.
|
| Though the prose is not at the level of Aphyr, the Cthulhu
| abominations in it are still admirably terrifying.
| smlckz wrote:
| What is left to do with the Technical Interview?
|
| I have yet to see anything more horrifyingly beautiful (or,
| beautifully horrifying) like this: mkanren in lisp in prolog ?!!
|
| https://gist.github.com/aphyr/4d41e7655b10a68e753f729bdc1c5a...
| phyzix5761 wrote:
| I hope she didn't get the job. She over engineered a simple
| problem into something hard to understand and maintain.
| thaumasiotes wrote:
| > hard to understand
|
| The "normal" approach is to define a function which takes some
| kind of input and exhibits side effects but doesn't return
| output.
|
| The approach here is to define a webserver which takes input in
| the form of a URL path and delivers output in the form of an
| HTTP response body. The differences are:
|
| - the input is considered to be a string rather than an integer
|
| - the output is returned rather than swallowed
|
| But I don't really see that one is harder to understand than
| the other.
| reshlo wrote:
| One is harder to understand than the other because it
| requires knowledge of YAML, Kubernetes, Nginx, httpbin, REST,
| and extremely complex regular expressions. It also has many
| dependencies.
|
| The problem can and should be solved in a handful of lines of
| code at most, requiring knowledge of nothing more complex
| than the modulus operator and simple Boolean logic.
| mnd999 wrote:
| I hope she did, it's a contrived problem and thus a contrived
| solution is okay. Sure, it's clever but you have to give some
| credit for having the "ovaries" to go with it.
| grumple wrote:
| She got the job, and she's been leading the team in scaling for
| the last 3 years in anticipation of getting their first
| customer.
| goatinaboat wrote:
| If you are asked a stupid question it is reasonable to give a
| stupid answer
| dotancohen wrote:
| This seems to be a case of "there is no such thing as a
| stupid question". That does not rule out stupid people asking
| questions, though.
| runawaybottle wrote:
| I'm trying to find out who the hero of this story is.
| cambalache wrote:
| Technical types should rarely, if ever, try to write fiction,
| this is a prime example. You could forgive the old masters in SF
| because the ideas were great and they have lots of practice after
| all so the prose was mediocre but tolerable.
| gumby wrote:
| You must be tough in a code review.
| josephg wrote:
| So much judgement. Just like with programming, The way to write
| good fiction is to first write a lot of bad fiction. Its not a
| matter of being a 'technical type'. Its practice.
|
| Andy Weir (author of The Martian) is a 'technical type' and The
| Martian was fantastic _because_ of his nerdy mind. His book
| drops with his love of STEM and all the research he put into
| it.
|
| The world needs more fiction by programmers; not less.
| weswinham wrote:
| This story would make a great culture test! "Would you hire this
| candidate?"
|
| You only want to work with team leads who agree with your answer,
| whatever that might be.
|
| Personally, I love working with folks who enjoy playing with
| technology, so I'm a Hell Yes. I don't see a lot of risk that
| this candidate would actually try to ship that regex to
| production.
| dasil003 wrote:
| I've worked with a few folks who are very talented, but only
| motivated by learning and working with new technologies. Even
| if they are enjoyable to work with in the short-term, they'll
| lose steam and saddle the team with doing the last mile and
| maintenance work. It may be okay to have one or two of these
| folks depending on team composition and sentiment, but
| generally I steer away from them.
| whatever_dude wrote:
| I would be a "hell no", because I know people like that are
| infuriating to work with if you're trying to get shit done. I
| love programming and discussing programming trivia and etc, but
| on a team you also need your coworkers to work with you towards
| a common goal in a rational manner, keeping in mind
| performance, maintainability, stability, team knowledge, time
| constraints, customer expectations, etc. These are not skills
| this hypothetical candidate displayed.
| [deleted]
___________________________________________________________________
(page generated 2021-03-13 23:02 UTC)