Earlier quoted context omitted.
I'm not sure why it makes you sad. On a germane-to-the-parent-comment sense, that's pretty much exactly what tptacek said. But on a wider scale, if you are trying to help someone, wouldn't you want to give them advice that truly helps them in a big and cross-task way? Much better than "get good at Rails", which is useful only for a subset of engineering roles (albeit a subset I may enjoy). In terms of time investment…
Yes, for the current state of the industry it is good advice. That is the part that saddens me, that "get good at sales" in order to get a job that has nothing to do with sales is sound, even the best, advice.
People suck at technical interviews
161–170 of 177 posts
Re: People suck at technical interviews
#162Fizzbuzz isn't supposed to be a test of your knowledge of the modulo operator. It's supposed to be a very low bar that can filter out a large percentage of candidates who have no business being there. If you spend 20 minutes on Fizzbuzz, you're doing it wrong. It should take 10 tops, and be limited by how quickly the candidate can write.
Now don't get me wrong, I wouldn't think poorly of someone or of their programming skills because of that. But not knowing about FizzBuzz is like not knowing the name of the current president. Have you been living under a rock for the past 5 years? It seems to be mentioned at least once a week on any sort of newsfeed, forum or blog related to programming.
Re: People suck at technical interviews
#163Earlier quoted context omitted.
I'm with @lostcolony: if I were interviewing and a candidate said "don't do that, it's unpredictable, do this instead" it's a great answer.
At the same time though, as someone looking for their first dev job, I'm not going to tell the interviewer "don't do that." Given the people I've met in industry, I can't see that ending well- I would expect some variation of "who does this kid think he is!?"
Re: People suck at technical interviews
#164This is a really excellent post. It talks about a bunch of things that are hobby-horses of mine (I help run recruiting for a large software security firm), and I find myself agreeing with more of it than I disagree with. I would go a little further than Laurie does. I think several of the goals he sets up for his process are not in reality achievable in an interview process. Starting axiom: job interviews are among t…
1. I tried to emphasize how important it is to keep the candidate relaxed and comfortable. Your suggestions are good, though we are too small and resource constrained to spend several weeks on interviews; each candidate gets about 6 hours in total, at least an hour of which is with me.
2. I had this process at my last job -- I asked everybody the same opened-ended architectural design question, and found it very useful for hiring back-end engineers, but at npm it's obviously inappropriate for our front-end and CLI engineers, so I've yet to come up with a "standard" question. It's a great suggestion.
As an aside, I am pleasantly surprised to see how many constructive comments there were on this article. Sort of feels like HN from a couple of years ago.
Re: People suck at technical interviews
#165Earlier quoted context omitted.
Yes, for the current state of the industry it is good advice. That is the part that saddens me, that "get good at sales" in order to get a job that has nothing to do with sales is sound, even the best, advice.
Software development is still sales. To successfully roll out a new internal product you need to sell your colleagues on it. To overhaul an existing architecture you need to sell your manager on its necessity. To prevent your coworker from making what you feel to be a poor choice, you need to sell her on your point of view.
Re: People suck at technical interviews
#166Earlier quoted context omitted.
> A recursive solution springs to mind, but I can recall implementing recursive solutions in production code only a few tens of times over a ten year career. If you are not comfortable with recursion, just remember: Recursion is really just a free stack. To use your example: Whenever you see an opening brace, push onto the stack. (Or, make a recursive call, which goes onto the call stack...) Whenever you see a closin…
Thank you for the helpful comment. I can't help but feel you miss the point of my post though. I can solve the problem. Verbally, (but admittedly less eloquently and less complete) I approximately gave your answer in the interview. Give me a quiet Monday morning, a pair of headphones and a compiler/interpreter and I can solve it well. It's the fact that it is being used as a filter when the person filtering doesn't k…
Re: People suck at technical interviews
#167Earlier quoted context omitted.
He didn't say coding was bad. He said coding on a whiteboard is bad. And, if you evaluated 100 strong developers by comparing their performance at a terminal and a whiteboard, my guess is that you'd quickly see that he's absolutely right about that --- not only would everyone outperform the whiteboard with a terminal, but that the whiteboard deficit would be highly irregular, defying any attempt to "handicap" for it.
Coding on a whiteboard is also impossible or infeasible for candidates with some kinds of disabilities (e.g. blind). Sure, you can make an exception for those few candidates, but I suppose the fact that you even have to make an exception to your normal process for a particular candidate might bias you against that candidate.
Re: People suck at technical interviews
#168Earlier quoted context omitted.
As a junior developer, I find myself confused by your comment. It seems as if a large proportion of the posts on HN claim that, when looking to hire someone, they focus on problem solving abilities and and culture fit. However, in May when I was interviewing with companies (including YC backed startups), almost every company focused on quizzing me about trivia [1]. I was actually given a paper quiz by one of the comp…
I was treated with respect throughout the whole process, and the interview was very well done, with challenging questions that forced me to think, and didn't rely on language trivia. I would recommend the company to any of my friends, whereas I can't say that about almost any other company I interviewed with. This is a really important point to remember for interviewers. The interview process isn't just to help you f…
Which hurt, in the short term, because I am a human being. But it was better than many other companies that would say "we'll tell you later today" and then wait a week, or wait for two weeks since my last interview and then reject me in the middle of the CTF they are running and I'm participating in (what, did my answers in the CTF suck?) and then invite me to apply for a job at the end of the CTF after rejecting me. That's really yanking my chain.
Re: People suck at technical interviews
#169For my first job out of uni, I was asked to write pseudocode on a whiteboard to solve a simple scripting problem (call an executable repeatedly, changing the command line args). My background is nuclear engineering, and I was interviewing at a cloud/networking business, so I was already slightly outside my experience comfort zone[0]. I was explaining my thought process while writing on the whiteboard, trying my best…
I, literally, just slapped my hand against my forehead loud enough to get people to look at me.
It's an understatement to say that, as a profession, we have poisoned the well when it comes to interviews.
Re: People suck at technical interviews
#170Fizzbuzz isn't supposed to be a test of your knowledge of the modulo operator. It's supposed to be a very low bar that can filter out a large percentage of candidates who have no business being there. If you spend 20 minutes on Fizzbuzz, you're doing it wrong. It should take 10 tops, and be limited by how quickly the candidate can write.
I think FizzBuzz is so popular that if you even needed me to describe the question, I'd be a little confused. I don't think I know any programmers with more than a year or two of experience/schooling that have never seen FizzBuzz before. Now don't get me wrong, I wouldn't think poorly of someone or of their programming skills because of that. But not knowing about FizzBuzz is like not knowing the name of the current…