Routing the Technical Interview
lars.hupel.info
lars.hupel.info
Though the prose is not at the level of Aphyr, the Cthulhu abominations in it are still admirably terrifying.
Still, I can't fault the author for giving it practice, and it is amusing enough to read.
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...
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.
Wiktionary:
> From Middle English governen, governe, from Anglo-Norman and Old French governer, guverner, from Latin gubernō, from Ancient Greek κυβερνάω (kubernáō, “I steer, drive, govern”)
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.
I’ve seen some people be at an employer for a couple of years with everyone mispronouncing their name because they didn’t want to correct people.
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.)
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.
(it had credentials in the source code, was mixing different concerns all over the place).
I don't know, I was quite a fan.
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.
I have yet to see anything more horrifyingly beautiful (or, beautifully horrifying) like this: μkanren in lisp in prolog ?!!
https://gist.github.com/aphyr/4d41e7655b10a68e753f729bdc1c5a...
/facepalm That's hilarious
This is presumably why Nephele is confused when the interviewer interprets her self-reference "helmswoman" as a metaphor.
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)
> 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.
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).
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)
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.
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.
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.
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.
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.
https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-de...
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.
Until this point I had been expecting that she was an Emacs user and would use an arcane series of shortcuts to scaffold the entire YAML file...
2. Didn’t her resume give enough information about her background?
Seeing the regex made me chuckle.
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.
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.
- You're hiring for a DevOps position - You use kubernetes to orchestrate your system
The test you do is FizzBuzz (? because that'll help you when your cluster is on fire). Along comes someone that seems to be way way better versed in kubernetes than anyone alive.
They use exactly the tools they'll be using day in and day out for their devops role. Hell, they implement FizzBuzz AS A SERVICE with kubernetes alone. And you pass it along.
Now ofc, in a real world situation you wouldn't want a person that when asked to implement a regex spins up a cluster and you do mention you have "Go" on your stack, so the easiest way would probably be to do a Go program, the thing still remains that for what it seems they were hiring, this person would be an amazing hire? You also say, "use any language", so the person could simply have thought - "well, this is for a devops position using kubernetes, I'm going to show you how much I understand this to the point your brain will melt"
That's why I think the story is good, it can be looked through quite different angles and it does pose some questions regarding the problems we use to proxy knowledge in a given domain/tool and also how we can access in a valid way someone's knowledge within a domain/tool when, and if, we ourselves lack considerable knowledge in that domain/tool. Maybe the person you end up hiring does the normal FizzBuzz in go and in all other areas is a better "hire", or culture fit, but when Kubernetes is burning they might not know how to put off the fire.
I don't really think this is right. Saying that understanding the presented solution requires knowledge of YAML, Kubernetes, and httpbin is like saying that understanding a solution in C with printf requires knowledge of file descriptors and terminal control codes. That's stuff the solution is built on, but you don't include it in your understanding of the solution.
Ask your interview candidate how printf works, and odds are they'll be stumped. But if we don't require that in order to understand the printf solution, why do we need to understand how the primitives of the Kubernetes solution work in order to understand that solution?
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.