3 ms·

Off topic — I am surprised to find this statement [1] in the blog post considering how negative were my teachers in university with the "trial and error" approa

Off topic — I am surprised to find this statement [1] in the blog post considering how negative were my teachers in university with the "trial and error" approach of solving a problem. They always said that you should design a solution before the implementation, and I agree that it makes sense but there are cases where you need to put a print and exit to debug something; and if you think about it, that is what a debugger does. Nowadays — and if you are doing interviews will understand — people expect you to write flawless code from scratch using a basic code editor (looking at you HackerRank) with no time for tests. Sixty minutes to write a solution for four challenges, without autocomplete, without tests. Even the genius co-worker that comes with an optimized solution for every problem would need more than fifteen minutes to solve those crazy/random challenges that at the end will measure your ability to resolve those specific questions but not problem solving skills in general. So is trial-and-error bad or not? [1] Much of a programmer’s time is spent in an edit-compile-debug workflow.

xyzzy_plugh 10y ago
I think "design a solution" can be as simple as having a rough idea of what the implementation looks like. This is solid advice. But the journey is part of the magic. Anyone expecting candidates to produce perfect code is doing it wrong. HackerRank is garbage. I want to understand how you think. I want you to communicate and ask questions. Yes, it can challenging to ve without your tools, with only a whiteboard, but that's okay. If I'm interviewing you and you make a typo, great! I don't care. Maybe I'll point it out to you, but I probably won't, and I certainly won't dock you for it. And yeah, you can debug. I often encourage candidates to walk through their code with sample input, which I usually want them to come up with too. This demonstrates an understanding of how your software works. I don't actually care if it compiles. I don't care if you're a wizard in emacs or can type a million words a minute. I also don't care if your solution is optimal. In the real world they rarely are. But, I want to talk to you about ways we could optimize it, and maybe I'll ask you to show me what you mean. Ultimately I want you to explain stuff to me, talk technical, and display your train of thought. Trial-and-error is fine. It's a tool, and there are no silver bullets.
Manishearth 10y ago
Designing a solution is still far from having code that works. You have designed a solution, and now you need to test it. In significantly complicated codebases, there are often all kinds of obscure issues that can crop up and make your (manual or automated) testing fail. These are not things you can think of beforehand in your design because it is not possible for you to have known about all of these issues. In fact, later in your comment you allude to this yourself -- "with no time for tests". You're worried about interviews not having time for tests. But tests are a edit-compile-debug feedback loop. If a test fails, you need to debug it, fix the issue, and recompile. Often you have to do this many times. This is precisely what the blog post is talking about. You're generalizing the term "trial and error" to mean something more than what your teachers probably meant. (I do agree that those interview practices are silly. But the blog post is not talking about stuff like that.)
Ace17 10y ago
> So is trial-and-error bad or not? It depends. Efficient trial-and-error should help you acquire a good understanding of the solution. When your program finally works, are you really sure why? If not, you might be doing it wrong. You might want to google "test driven development". Basically, it's a programming discipline which heavily relies on shortening your feedback loops (i.e reduce the time between the moment you make an error and the moment you detect it). While it certainly is controversial, it can be seen as a serious formalization of "trial and error".

xyzzy_plugh 10y ago

I think "design a solution" can be as simple as having a rough idea of what the implementation looks like. This is solid advice. But the journey is part of the magic. Anyone expecting candidates to produce perfect code is doing it wrong. HackerRank is garbage. I want to understand how you think. I want you to communicate and ask questions. Yes, it can challenging to ve without your tools, with only a whiteboard, but that's okay. If I'm interviewing you and you make a typo, great! I don't care. Maybe I'll point it out to you, but I probably won't, and I certainly won't dock you for it. And yeah, you can debug. I often encourage candidates to walk through their code with sample input, which I usually want them to come up with too. This demonstrates an understanding of how your software works. I don't actually care if it compiles. I don't care if you're a wizard in emacs or can type a million words a minute. I also don't care if your solution is optimal. In the real world they rarely are. But, I want to talk to you about ways we could optimize it, and maybe I'll ask you to show me what you mean. Ultimately I want you to explain stuff to me, talk technical, and display your train of thought. Trial-and-error is fine. It's a tool, and there are no silver bullets.

Manishearth 10y ago

Designing a solution is still far from having code that works. You have designed a solution, and now you need to test it. In significantly complicated codebases, there are often all kinds of obscure issues that can crop up and make your (manual or automated) testing fail. These are not things you can think of beforehand in your design because it is not possible for you to have known about all of these issues. In fact, later in your comment you allude to this yourself -- "with no time for tests". You're worried about interviews not having time for tests. But tests are a edit-compile-debug feedback loop. If a test fails, you need to debug it, fix the issue, and recompile. Often you have to do this many times. This is precisely what the blog post is talking about. You're generalizing the term "trial and error" to mean something more than what your teachers probably meant. (I do agree that those interview practices are silly. But the blog post is not talking about stuff like that.)

Ace17 10y ago

> So is trial-and-error bad or not? It depends. Efficient trial-and-error should help you acquire a good understanding of the solution. When your program finally works, are you really sure why? If not, you might be doing it wrong. You might want to google "test driven development". Basically, it's a programming discipline which heavily relies on shortening your feedback loops (i.e reduce the time between the moment you make an error and the moment you detect it). While it certainly is controversial, it can be seen as a serious formalization of "trial and error".