Interview question for senior front-end engineer

[liegroup]

Thoughts on the difficulty level of the following question for a senior front-end engineer candidate? Interviewer was given 15 minutes to provide the function body for

  // Contract:
  //
  // Create a function with a signature:
  //
  //    retry(fn, retryDelay, maxAttempts) -> promise
  //
  // Implementation:
  //
  //  • retry should call fn; if fn() throws an error error, wait for the retry delay to retry calling fn.
  //  • if fn() succeeds, the returned promise should resolve with the result of fn()
  //  • in fn() has been attempted maxAttempts with an error each time, returned promise should reject with the last error
  //
  function retry(fn, retryDelay, maxAttempts) {
    /* ... */
  }

I provided some basic assertions to valid the code was working. Solution is about 12-13 lines of code.

I remember being able to solve this sight unseen within 15 minutes; I was asked this question on an on-site by a large, well-known tech company. When I tried it again pre-interview it took longer (~30 minutes). Thoughts?

[nherment]

I would consider this as easy level (ie. solving this should be an acquired skill for a senior dev) with a couple of caveats:

- while an interviewee could be expected to come up with a solution quickly (15 minutes seem more than reasonable), interviews are sometime stressful, people are sometime tired, etc. Some leniency should be applied to the amount of time needed to solving this or any algorihtmic problem.

- not everybody is used to working with promises. What is considered good practice in one company is not necessarily best practice in another one. Any senior front-end dev should at least know about them and be able to pick up a quick definition of the API given by the interviewer and use it in the solution.

If it took you 30 minutes maybe it's not so good to expect interviewees to solve it in 15 ?

On "why did it take you 30 minutes?", only you knows where you spent these minutes and struggled, that is, if you even struggled..

[liegroup]

It took me 30 minutes because I'm out of interviewing practice mode, and I was pair-programming with a backend/infrastructure dev :). When I tried it alone, I did it in about 7 minutes.

Would you agree that 15 minutes is enough to get a sense of the candidate's approach, and be able to tell whether or not they'd be able to solve it given 45 minutes?

[nherment]

I agree that 15 minutes is enough to get a sense of the candidate approach. While I don't think only one question and its solution give enough information about a candidate, not solving this quickly is a bad sign (for a senior front-end dev).

My approach to interviewees is no panacea but I try to start low and build up in complexity from there by playing on their strength and finding where that brings the both of you (hopefully to their upper limit). It means a bit of preparation before hands based on their resume or a prior phone interview.

Some interviewees just slice through whatever you give them and others are in an uphill battle. To somehow answer you question about being able to infer if a candidate can solve a problem in a given amount of time, I believe the only way to know is to give them that time. A bit of help here and there can help move on to a different question and I've yet to see someone properly 'fake' understanding code (ie. they say they understand but not really).

I also believe that it's only by knowing what candidates are able to do and what their current limits are that I can make a good hiring decision. This is very hard to do and I often get it wrong. Comparatively, it's easy to find what a candidate can't do but it does not help you much deciding who to hire.

If a candidate fails all questions, either the questions are inadequate/wrong or they are a fraud.

[liegroup]

Now that I think back, at least half the time was spent in setting up test cases and clarifying the problem statement.