4 ms·

That just makes me think that they are not doing interviews right either -- ranking based on how quickly you can whip up an algorithm for a tricky question.

by j0e1 10y ago

Retric 10y ago
I just conducted several technical interviews. Starting with a very basic question even for people with years of experience shows you quite a bit. It's not about getting it correct, it's can you get in the correct ballpark and you can evaluate what your doing. Create a function that returns true or false if _. Followed by far more hand holding that I was expecting, but most people got the idea fairly quickly. Only person who failed wanted to add a lot of print statements for no reason. And then did not respond to help. IMO, good interview questions are such that most people pass. I mean your bringing them in so asking something you had to google is a waste of time. The goal should be to minimize false negatives while still removing some people. The classic what is an Object, what is an Interface is just filler that tells you little. And very technical questions have ridiculous false negative rates. So, just softball an easy code problem, ask about background and fit, and call it a day. PS: Remember you're interviewing people for a reason. When a good fit backs out you lose not just time but potentially a great coworker.
- bbarn 10y ago
  The PS is something people forget all the time. It's a learned skill to make interviewees feel like this isn't an adversarial meeting, but a mutual interviewing. That said, you're right. Just this week I interviewed someone with almost 30 years experience, some of it dev, architect, some management, for a pure developer role, and gave him "Write a function(n) that takes an integer and gives you the nth number in the Fibonacci sequence." Got very angry and said he didn't know the algorithm, so I drew it on the board and explained it (red flag for someone who was a former "scrum master" not knowing what the Fibonacci sequence was), and he told me that it was arbitrary and academic and a waste of time. I asked him to do it anyway since it was to see his style and approach, and he got mad and left. Most junior devs solve this problem in ten-fifteen minutes, and I consider it actually more of an interactive ice breaker to get us both standing and talking rather than a stumper.
  - inimino 10y ago
    Are you sure that's really the hiring process you want? Junior devs were more recently in school, which is the last time such knowledge is needed. If you have actual technical challenges relevant to your work, why not take that hint and shift the interview to something that might possibly come up on the job and that isn't trivial for a junior dev? Instead of finding out what that candidate was good at, you just found out which academic trivia he doesn't remember, and that he has a low tolerance for irrelevant bullshit.
    - bbarn 10y ago
      There were no trivia involved. I wrote the sequence and explained it - it's not hard to grasp. It's a simple for loop in the easiest solution and a simple recursive method if they want to show off.
      - inimino 10y ago
        I like recreational mathematics too. Is the Fibonacci sequence related to the job in any way? If not, I say it's trivia. Look, someone looking for their first coding job is surely willing to walk you through CS101 assignments. It's a fine icebreaker if someone has no industry experience. Someone more senior should be trying to have an entirely different conversation with you. Do you understand and value what they bring to the table that a junior dev doesn't? Will you adapt to take advantage of their strengths, or will you insist on following your process just because it's your process? Is there space for them to make a contribution or are you just looking for someone who will code up what you ask for? Interviewing is a mutual search for fit. There wasn't one. Maybe that's because you weeded out someone who couldn't complete a freshman homework assignment with help. Maybe not.
- kafkaesq 10y ago
  It's not about getting it correct, it's can you get in the correct ballpark and you can evaluate what your doing. Is it, now? In many of these sessions you are unequivocally dinged for having a less-than-perfect answer by the time the bell rints. Or if there is some fuzzy acceptance standard in the back of their minds somewhere -- they certainly won't condescend to tell you what it is. Instead, what you usually get is: "Uhh, hi. Here's a Google Doc. Can you type a fully working implementation X for me while I boredly watch? BTW I don't normally program in the language you're programming in and so probably shouldn't be doing this session with you anyway, as that will only work against you. But then again, it's not like I care -- I'm just doing this because they told me to."

That just makes me think that they are not doing interviews right either -- ranking based on how quickly you can whip up an algorithm for a tricky question.

by j0e1 10y ago

That just makes me think that they are not doing interviews right either -- ranking based on how quickly you can whip up an algorithm for a tricky question.

Retric 10y ago

I just conducted several technical interviews. Starting with a very basic question even for people with years of experience shows you quite a bit. It's not about getting it correct, it's can you get in the correct ballpark and you can evaluate what your doing. Create a function that returns true or false if _. Followed by far more hand holding that I was expecting, but most people got the idea fairly quickly. Only person who failed wanted to add a lot of print statements for no reason. And then did not respond to help. IMO, good interview questions are such that most people pass. I mean your bringing them in so asking something you had to google is a waste of time. The goal should be to minimize false negatives while still removing some people. The classic what is an Object, what is an Interface is just filler that tells you little. And very technical questions have ridiculous false negative rates. So, just softball an easy code problem, ask about background and fit, and call it a day. PS: Remember you're interviewing people for a reason. When a good fit backs out you lose not just time but potentially a great coworker.

bbarn 10y ago
The PS is something people forget all the time. It's a learned skill to make interviewees feel like this isn't an adversarial meeting, but a mutual interviewing. That said, you're right. Just this week I interviewed someone with almost 30 years experience, some of it dev, architect, some management, for a pure developer role, and gave him "Write a function(n) that takes an integer and gives you the nth number in the Fibonacci sequence." Got very angry and said he didn't know the algorithm, so I drew it on the board and explained it (red flag for someone who was a former "scrum master" not knowing what the Fibonacci sequence was), and he told me that it was arbitrary and academic and a waste of time. I asked him to do it anyway since it was to see his style and approach, and he got mad and left. Most junior devs solve this problem in ten-fifteen minutes, and I consider it actually more of an interactive ice breaker to get us both standing and talking rather than a stumper.
- inimino 10y ago
  Are you sure that's really the hiring process you want? Junior devs were more recently in school, which is the last time such knowledge is needed. If you have actual technical challenges relevant to your work, why not take that hint and shift the interview to something that might possibly come up on the job and that isn't trivial for a junior dev? Instead of finding out what that candidate was good at, you just found out which academic trivia he doesn't remember, and that he has a low tolerance for irrelevant bullshit.
  - bbarn 10y ago
    There were no trivia involved. I wrote the sequence and explained it - it's not hard to grasp. It's a simple for loop in the easiest solution and a simple recursive method if they want to show off.
    - inimino 10y ago
      I like recreational mathematics too. Is the Fibonacci sequence related to the job in any way? If not, I say it's trivia. Look, someone looking for their first coding job is surely willing to walk you through CS101 assignments. It's a fine icebreaker if someone has no industry experience. Someone more senior should be trying to have an entirely different conversation with you. Do you understand and value what they bring to the table that a junior dev doesn't? Will you adapt to take advantage of their strengths, or will you insist on following your process just because it's your process? Is there space for them to make a contribution or are you just looking for someone who will code up what you ask for? Interviewing is a mutual search for fit. There wasn't one. Maybe that's because you weeded out someone who couldn't complete a freshman homework assignment with help. Maybe not.
kafkaesq 10y ago
It's not about getting it correct, it's can you get in the correct ballpark and you can evaluate what your doing. Is it, now? In many of these sessions you are unequivocally dinged for having a less-than-perfect answer by the time the bell rints. Or if there is some fuzzy acceptance standard in the back of their minds somewhere -- they certainly won't condescend to tell you what it is. Instead, what you usually get is: "Uhh, hi. Here's a Google Doc. Can you type a fully working implementation X for me while I boredly watch? BTW I don't normally program in the language you're programming in and so probably shouldn't be doing this session with you anyway, as that will only work against you. But then again, it's not like I care -- I'm just doing this because they told me to."