4 ms·

It's the start of the coding interview. It moves on from there. This candidate didn't even ask if he could use Apache commons, and I hadn't yet specified that h

by kronin 8y ago

It's the start of the coding interview. It moves on from there. This candidate didn't even ask if he could use Apache commons, and I hadn't yet specified that he couldn't use a 3rd party library. So yes. He failed on many counts. 1) not asking clarifying questions 2) not being familiar with some well-known libraries 3) not being able to implement a basic reverse string 4) not being able to explain whether or not a simple method was thread safe (with multi-threading experience all over his resume) I expect engineers, senior or otherwise, to be able to write code. If you can't do that, don't put it on your resume. If you honestly think implementing a reverse string method is "too complicated"... Edit: sorry, leaving the response as-is, but I recognize you didn't state "too complicated". You stated "focused on the wrong skills". I posit that an engineer that can't reverse a string, as a litmus test, will be likely unable to solve a more complicated problem.

0x445442 8y ago
If you're interviewing for some core, low level algorithm development then fair enough but I suspect if that's the case you could come up with something a little closer to the real life domain. It's not that I think the question is too complicated, just not the best marker. In my mind, more relevant questions are ones that demonstrate real life experience in the field. For example, populating a tree of objects in a high level language like Java from a DB where the tree of objects are stored as many to many relationships. You'd be surprised how many times I've run across production code which does this via SQL calls inside nested loops. This whole infatuation with algorithm questions like you'd find in SICP might be good for new grads but misses the mark for Senior level engineers.
- kronin 8y ago
  I asked a candidate to implement an algorithm that reverses a string. I don't see that as a complicated problem. It's literally a for loop, and based on how they choose to implement it you can ask about implications of append vs. prepend, etc. I didn't ask them to implement dijkstra's algorithm, or even something as "hard" as breadth-first or depth-first search (which I feel any senior that deals with trees should be able to do). It's a marker of this... Can the candidate solve a basic problem? Once they solve it, can they explain their solution? Do they understand the memory/time tradeoffs they chose? Do they know whether the code they wrote is thread-safe? If you don't feel a senior engineer should be able to answer those questions, to a very basic problem, how do you expect them to tackle something more complex?
  - deleted 8y ago
    [deleted]
  - 0x445442 8y ago
    What I'm interested in from a senior engineer is how many systems they've designed, implemented, deployed to production and supported in their careers and what their specific roles were in those projects. If I can't get an idea from their resume I wouldn't contact them for an interview. As for the interview itself, well I've never needed to ask someone to reverse a string to determine if they're going to be of value with the criteria mentioned above. But to be fair I've never worked on a project where implementing StringUtils.reverse() was required. If I were interviewing someone to work on Apache Commons or the JDK then I suppose that would be a relevant question.
    - deleted 8y ago
      [deleted]
    - jodrellblank 8y ago
      Oh come on, argue the strongest part of their argument, would you, instead of nitpicking over string reverse. They've repeatedly, laboriously, explained that reversing a string isn't the relevant part to be focusing on. What I'm interested in from a senior engineer is how many systems they've designed, implemented, deployed to production and supported in their careers and what their specific roles were in those projects. If I can't get an idea from their resume I wouldn't contact them for an interview. And when their resume looks good and claims they are an expert, and you call them in and talk to them and they say they are an expert, and you start by opening a warmup question on the most basic levels of their expertise and they totally flunk it on multiple levels - unable to even handle the situation with tact or diplomacy in any way, are you still going to trust what they say about the systems they've "deployed and supported"?
  - dave1999x 8y ago
    Did you know in .Net strings are immutable? Neither did the guy at Google when he asked me to do some "in place" string fiddling algorithm or that guy at Amazon who wanted to reverse the strings in a sentence (yes there's a trick to that one found in some 80s programming book)
baursak 8y ago
How many times in your job did you have to implement reversing a string without calling a library?
- akiselev 8y ago
  I mean, in languages like Python it can be as simple as `foo[::-1]` or some similar method. Anyone who can give a naive answer like that or usize len = strlen(foo); char* bar = malloc(len); for (int i = 0; i < len; i++) { bar[i] = foo[len - (i + 1)]; } and explain why that won't work for unicode strings, I imagine, would pass that particular fizzbuzz test. Bonus points for pointing out the null byte off by one error. The only competent programmers I can think of that wouldn't be able to come up with that off the top off my head work in embedded or FPGAs where strings are rarely relevant.
- throwawaymath 8y ago
  I understand the class of rebuttal you're invoking here, but reversing a string is extremely easy - with or without a library. This is not an academic problem designed to see if a person can study prior to an interview. This is a first pass question designed to see if a person is even acquainted with basic programming. Any such question you could devise would be similarly patronizing or orthogonal to the exact work done on the job. And yet, despite how easy the question is people still fail it. It's frankly absurd to me that a senior software engineer can fail this question. It's practically a freebie slam dunk for anyone with basic competency. Briefly drop that you can use your language's core function or method to do it. Then declare a new array and iterate through the string backwards, appending each character to the new array. When you're done, collapse the array to a string. In other words, it's testing if you can write a for loop. How many times in your job do you expect to implement a for loop? I use for loops quite often.
  - jen20 8y ago
    > iterate through the string backwards What about multi-byte characters?
    - 8y ago
kstenerud 8y ago
Just speaking to points 1 and 2: In an interview, there is an unspoken assumption that you won't be using third party libraries to implement algorithms, and certainly not a third party library that implements it in one function call. Using that as a red flag will yield a LOT of false positives. Also, I have over 10 years experience in Java, have used Apache commons extensively, and had no idea that a string reversal method even existed. You can't use that knowledge to judge anything useful.
- kronin 8y ago
  I agree about your unspoken assumption, but many interviewees ask. And the post I was responding to pointed to the Apache commons library, so I hazard to say it's not universally known. A fail is not a red flag. A senior candidate not asking clarifying questions does not disqualify them (what I would call a red flag) but it is brought up in the debrief as a potential gap. I don't expect them to state this could be implemented using a single call to Apache commons. I call those candidates out in the debrief as being aware of the library, as a bonus. But not saying it isn't a negative.

by kronin 8y ago

0x445442 8y ago

If you're interviewing for some core, low level algorithm development then fair enough but I suspect if that's the case you could come up with something a little closer to the real life domain. It's not that I think the question is too complicated, just not the best marker. In my mind, more relevant questions are ones that demonstrate real life experience in the field. For example, populating a tree of objects in a high level language like Java from a DB where the tree of objects are stored as many to many relationships. You'd be surprised how many times I've run across production code which does this via SQL calls inside nested loops. This whole infatuation with algorithm questions like you'd find in SICP might be good for new grads but misses the mark for Senior level engineers.

kronin 8y ago
I asked a candidate to implement an algorithm that reverses a string. I don't see that as a complicated problem. It's literally a for loop, and based on how they choose to implement it you can ask about implications of append vs. prepend, etc. I didn't ask them to implement dijkstra's algorithm, or even something as "hard" as breadth-first or depth-first search (which I feel any senior that deals with trees should be able to do). It's a marker of this... Can the candidate solve a basic problem? Once they solve it, can they explain their solution? Do they understand the memory/time tradeoffs they chose? Do they know whether the code they wrote is thread-safe? If you don't feel a senior engineer should be able to answer those questions, to a very basic problem, how do you expect them to tackle something more complex?
- deleted 8y ago
  [deleted]
- 0x445442 8y ago
  What I'm interested in from a senior engineer is how many systems they've designed, implemented, deployed to production and supported in their careers and what their specific roles were in those projects. If I can't get an idea from their resume I wouldn't contact them for an interview. As for the interview itself, well I've never needed to ask someone to reverse a string to determine if they're going to be of value with the criteria mentioned above. But to be fair I've never worked on a project where implementing StringUtils.reverse() was required. If I were interviewing someone to work on Apache Commons or the JDK then I suppose that would be a relevant question.
  - deleted 8y ago
    [deleted]
  - jodrellblank 8y ago
    Oh come on, argue the strongest part of their argument, would you, instead of nitpicking over string reverse. They've repeatedly, laboriously, explained that reversing a string isn't the relevant part to be focusing on. What I'm interested in from a senior engineer is how many systems they've designed, implemented, deployed to production and supported in their careers and what their specific roles were in those projects. If I can't get an idea from their resume I wouldn't contact them for an interview. And when their resume looks good and claims they are an expert, and you call them in and talk to them and they say they are an expert, and you start by opening a warmup question on the most basic levels of their expertise and they totally flunk it on multiple levels - unable to even handle the situation with tact or diplomacy in any way, are you still going to trust what they say about the systems they've "deployed and supported"?
- dave1999x 8y ago
  Did you know in .Net strings are immutable? Neither did the guy at Google when he asked me to do some "in place" string fiddling algorithm or that guy at Amazon who wanted to reverse the strings in a sentence (yes there's a trick to that one found in some 80s programming book)

baursak 8y ago

How many times in your job did you have to implement reversing a string without calling a library?

akiselev 8y ago
I mean, in languages like Python it can be as simple as `foo[::-1]` or some similar method. Anyone who can give a naive answer like that or usize len = strlen(foo); char* bar = malloc(len); for (int i = 0; i < len; i++) { bar[i] = foo[len - (i + 1)]; } and explain why that won't work for unicode strings, I imagine, would pass that particular fizzbuzz test. Bonus points for pointing out the null byte off by one error. The only competent programmers I can think of that wouldn't be able to come up with that off the top off my head work in embedded or FPGAs where strings are rarely relevant.
throwawaymath 8y ago
I understand the class of rebuttal you're invoking here, but reversing a string is extremely easy - with or without a library. This is not an academic problem designed to see if a person can study prior to an interview. This is a first pass question designed to see if a person is even acquainted with basic programming. Any such question you could devise would be similarly patronizing or orthogonal to the exact work done on the job. And yet, despite how easy the question is people still fail it. It's frankly absurd to me that a senior software engineer can fail this question. It's practically a freebie slam dunk for anyone with basic competency. Briefly drop that you can use your language's core function or method to do it. Then declare a new array and iterate through the string backwards, appending each character to the new array. When you're done, collapse the array to a string. In other words, it's testing if you can write a for loop. How many times in your job do you expect to implement a for loop? I use for loops quite often.
- jen20 8y ago
  > iterate through the string backwards What about multi-byte characters?
  - 8y ago

kstenerud 8y ago

Just speaking to points 1 and 2: In an interview, there is an unspoken assumption that you won't be using third party libraries to implement algorithms, and certainly not a third party library that implements it in one function call. Using that as a red flag will yield a LOT of false positives. Also, I have over 10 years experience in Java, have used Apache commons extensively, and had no idea that a string reversal method even existed. You can't use that knowledge to judge anything useful.

kronin 8y ago
I agree about your unspoken assumption, but many interviewees ask. And the post I was responding to pointed to the Apache commons library, so I hazard to say it's not universally known. A fail is not a red flag. A senior candidate not asking clarifying questions does not disqualify them (what I would call a red flag) but it is brought up in the debrief as a potential gap. I don't expect them to state this could be implemented using a single call to Apache commons. I call those candidates out in the debrief as being aware of the library, as a bonus. But not saying it isn't a negative.