4 ms·

I think different companies view this differently. I recently did an interview with a social media company (not Facebook, one of the other ones) where I wrote u

I think different companies view this differently. I recently did an interview with a social media company (not Facebook, one of the other ones) where I wrote up a solution to the problem that "just worked" in one go, as did my extensions. After the interview, when I asked for feedback, the interviewer told me that I should have been running and testing my code as we went along. However, I've also heard in mentoring sessions from engineers at other companies that the goal in interviews is to write code that works the first time without having to test along the way. In general, I prefer the approach of writing out the entire solution at one go, and trusting that bugs will be easy to fix at the end if the code is clean enough to understand what is happening at every step. This is in part because there usually isn't enough time in interviews for running tests at every crux moment. However, I think our current virtual environment may make it easier to test for (and to utilize) these types of programming best practices, since instead of writing code on the whiteboard, candidates and companies can use one of the interview interfaces that allows running code as you write it.

lmilcin 5y ago
> After the interview, when I asked for feedback, the interviewer told me that I should have been running and testing my code as we went along. Have they specified that you should be testing your code? If they haven't specified then it is wrong to expect some kind of arbitrary outcome. People write code in many different ways, some do it very chaotically, some have very organized process. I try to figure out which of these behaviors are fundamental to writing good code and which are not. For example, I believe a habit of writing readable code IS fundamental to writing good code. If you don't have a habit of writing readable code, on average your code is going to be worse than if you had. On the other hand, I believe writing unit tests IS NOT fundamental. Unit tests is one possible way of working with the code, but people were writing reliable code before unit testing became popular. Unit testing takes time and effort that can be allocated differently. And so I try to look (I can't call it measuring because it is subjective) only at the behaviors that I believe are fundamental and dismiss others. In the end, if you are smart person that can program well, you will be able to learn those other behaviors. But if you are not smart or you lack certain fundamental abilities, it is going to be much more difficult to fix it.
ajmurmann 5y ago
I do an interview in which we do TDD on a problem together. So we are frequently running tests during the interview. However, one of the things that's expected from the candidate is that they will be able to predict what happens when we run tests. Will the tests pass? Will an exception be thrown? How will it fail? Maybe as do often the difference in this discussion is a quantitative one not one in principle.
- lmilcin 5y ago
  Running tests frequently is not a problem. Not knowing what the code will do is.

lmilcin 5y ago

> After the interview, when I asked for feedback, the interviewer told me that I should have been running and testing my code as we went along. Have they specified that you should be testing your code? If they haven't specified then it is wrong to expect some kind of arbitrary outcome. People write code in many different ways, some do it very chaotically, some have very organized process. I try to figure out which of these behaviors are fundamental to writing good code and which are not. For example, I believe a habit of writing readable code IS fundamental to writing good code. If you don't have a habit of writing readable code, on average your code is going to be worse than if you had. On the other hand, I believe writing unit tests IS NOT fundamental. Unit tests is one possible way of working with the code, but people were writing reliable code before unit testing became popular. Unit testing takes time and effort that can be allocated differently. And so I try to look (I can't call it measuring because it is subjective) only at the behaviors that I believe are fundamental and dismiss others. In the end, if you are smart person that can program well, you will be able to learn those other behaviors. But if you are not smart or you lack certain fundamental abilities, it is going to be much more difficult to fix it.

ajmurmann 5y ago

I do an interview in which we do TDD on a problem together. So we are frequently running tests during the interview. However, one of the things that's expected from the candidate is that they will be able to predict what happens when we run tests. Will the tests pass? Will an exception be thrown? How will it fail? Maybe as do often the difference in this discussion is a quantitative one not one in principle.

lmilcin 5y ago
Running tests frequently is not a problem. Not knowing what the code will do is.