6 ms·

I think it is focusing on the wrong parts. My framework for the coding part of the interview is following: * Does the candidate tackle the problem analyticall

I think it is focusing on the wrong parts. My framework for the coding part of the interview is following: * Does the candidate tackle the problem analytically? Being able to think analytically is critical to scaling from solving small problems to solving large problems. * Can the candidate predict what his code is going to do before he executes it? Repetitively executing code to see if it works may seem innocuous, but really is a huge defect in candidate's process which makes it really difficult or impossible for them to write anything non trivial to be reliable. * Can the candidate recognize and make use of an advice? Surprisingly, a lot of people can't recognize when they are given advice even when I directly give them solution to their problem. It is really disheartening to have a candidate dismiss your advice even when repeated multiple times. I frequently give advice to unstuck the candidate because seeing him/her work on the problem is more important to me than seeing if they can solve any particular part of the problem. * Can the candidate recognize choices/tradeoffs that impact performance and/or simplicity of the solution? * Can I have productive discussion with the candidate about designing his solution? Can the candidate converse in a clear and precise language? * Is he/she caring that the resulting code is readable? * Can they diagnose faults in their code effectively? Assuming they executed their solution and it is not doing what it was expected to do, I like to see the candidate follow some kind of analytical process to find out what is causing the problem. I even design the task specifically so that it is very likely they are going to make one particular mistake to give me that opportunity. ** What I specifically ignore in the coding task: * Whether the candidate knows the standard library. I don't care. During normal work they can look it up on google. On the interview I tell them that if they can describe the function I can tell them the name and how to use it. * Whether the candidate can have flashes of insight. I don't get so many candidates to waste them on that kind high false negative signal. I have identified parts of the task that require a flash of insight. I give the candidate a minute or two when they reach it and if I don't see progress I give them a progressively less subtle nudges. * Whether the candidate can do TDD/DDD/etc. It all depends on their experience. If they worked for non-TDD or non-DDD shop for a long time it is going to take some time to adjust. * Whether the candidate can solve a very complex problem. The interview is already stressful enough experience for the candidate. I can learn what I need on a simple problem and I care much more to see the candidate's process rather than results. The problem is just hard enough to be out of grasp of most people at the very beginning and require some actual thinking. Some people get it instantly and then I am disappointed a little bit because I can't see them working on it.

Jaygles 5y ago
>* Can the candidate predict what his code is going to do before he executes it? Repetitively executing code to see if it works may seem innocuous, but really is a huge defect in candidate's process which makes it really difficult for them to write anything non trivial to be reliable. I'm going to disagree here. Testing your code in small chunks can not only catch small errors before they propagate into something larger, but also give you insight into whether you are going down the wrong path.
- lmilcin 5y ago
  If you write a small piece of code and can't tell if it is going to work or not you don't really understand what it does. We are not talking using external dependencies or frameworks. I am talking simple code that you just wrote in entirety, maybe couple of loops and conditionals. If you can't predict what that small piece of code does, exactly, you are thoroughly unable to write reliable code, by definition. Reliable code == code that does exactly what you intend it to do, nothing less, nothing more. If you can't predict what your code does you are writing buggy code. Experimentation can uncover some of the bugs, but if you start with buggy code the experimentation will never remove all bugs -- only the ones that are easy to detect.
  - cghendrix 5y ago
    You have a good point overall. However, can you truly reduce the definition of reliable code to something that simple? I think there are a lot more factors that determine if code is reliable or not.
    - lmilcin 5y ago
      I actually think that this is good definition of reliable code -- product of an individual developer's process. It does not say whether it was specified well, but I think an application can reliably execute wrong process. There is no contradiction. I don't want to say that making sure that your code does exactly what you intend it to do is at all simple. As your application grows, as you start incorporating dependencies, external systems, code that came from others, things that you do not know very well -- writing code that does exactly what you intend it to becomes very difficult or even impossible. But on the lowest level, when we are talking couple of variables, conditionals, loops, maybe small data structure -- I would expect a developer to be able to write it to do what is exactly intended. Because if you have that ability and use it for every piece of code that you write, the overall result (even if it does not guarantee reliability) will be better than a person that cannot do it. In my experience (and it depends a lot on our HR and candidates that are being sent my way) only one in about 10 candidates (for senior Java dev position) can do that.

Jaygles 5y ago

>* Can the candidate predict what his code is going to do before he executes it? Repetitively executing code to see if it works may seem innocuous, but really is a huge defect in candidate's process which makes it really difficult for them to write anything non trivial to be reliable. I'm going to disagree here. Testing your code in small chunks can not only catch small errors before they propagate into something larger, but also give you insight into whether you are going down the wrong path.

lmilcin 5y ago
If you write a small piece of code and can't tell if it is going to work or not you don't really understand what it does. We are not talking using external dependencies or frameworks. I am talking simple code that you just wrote in entirety, maybe couple of loops and conditionals. If you can't predict what that small piece of code does, exactly, you are thoroughly unable to write reliable code, by definition. Reliable code == code that does exactly what you intend it to do, nothing less, nothing more. If you can't predict what your code does you are writing buggy code. Experimentation can uncover some of the bugs, but if you start with buggy code the experimentation will never remove all bugs -- only the ones that are easy to detect.
- cghendrix 5y ago
  You have a good point overall. However, can you truly reduce the definition of reliable code to something that simple? I think there are a lot more factors that determine if code is reliable or not.
  - lmilcin 5y ago
    I actually think that this is good definition of reliable code -- product of an individual developer's process. It does not say whether it was specified well, but I think an application can reliably execute wrong process. There is no contradiction. I don't want to say that making sure that your code does exactly what you intend it to do is at all simple. As your application grows, as you start incorporating dependencies, external systems, code that came from others, things that you do not know very well -- writing code that does exactly what you intend it to becomes very difficult or even impossible. But on the lowest level, when we are talking couple of variables, conditionals, loops, maybe small data structure -- I would expect a developer to be able to write it to do what is exactly intended. Because if you have that ability and use it for every piece of code that you write, the overall result (even if it does not guarantee reliability) will be better than a person that cannot do it. In my experience (and it depends a lot on our HR and candidates that are being sent my way) only one in about 10 candidates (for senior Java dev position) can do that.