Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I used to hate leetcode, and I've never done the grind, refusing to do so, so just a maybe 20-30 of them in total in my life to get an idea of it. I'm okay with not getting through hard leetcodes in competitive positions.

However, recently when I put myself on the market I found many companies are now doing take-home tests. I find I hate them even more, so I appreciate leetcode interviews now. I think take homes are too asynchronous and the last thing I want to do is waste my nights and weekends working on them. I've refused to do the last 4-5 I have been offered after agreeing to do a couple and then dropping out instead.

Ultimately I went with companies that didn't do tech screens beyond a simple code pairing session.



I like the take home tests myself. Whiteboarding and brain teasers are not outside my experience (I did mathletics stuff as a child) but doing them out loud in front of a hostile audience is not a strength of mine. The best work I have done has been largely composed of private problem solving, syncing up with peers only once I was sure I knew the topology of the problem and perhaps had run a few experiments.

It doesn't really take long to get to the point where talking about a problem with others can be helpful, less than a day most times, but starting off a new problem with verbal spitballing with peers has not been all that useful in my work. For me to really learn something I need to hold it in my hands/code editor and get to know the ins and outs, build up intuition so that I can speak about it accurately. Jumping into unknown problems in an interview by standing up at a whiteboard talking just seems like putting the cart before the horse to me. Maybe the interviewer wants to see my "thought process," whatever that means, but what does it really matter if I can get to a good solution without vocalizing every step along the way?

I often go down the wrong paths when problem solving, if only to traverse them for my own edification. If I can make 10 mistakes or false starts in a row and still arrive at a decent solution as quickly as anyone else, what does it matter in the end? I also tend to write code out of order. I might jump around between concepts and write disparate sections of a solution without linking them back right away, following my intuition without trying to enforce order on everything I do. No one has ever complained about my speed or code cleanliness/clarity, quite the opposite in fact. Yet when I am put under the microscope, these behaviors inevitably stand out to the interviewer as cause for concern.

Despite a strong track record of building numerous successful systems and apps, many solving "serious" problems that go beyond what can be assessed in an interview, on tiny teams where I shouldered large amounts responsibility, if I can't present my thoughts in a coherent, structured way, in the moment I am thinking them, I am bound to catch flak from the interviewer. So I often feel I must alter my behavior, go slower and try to only display ordered thinking, but this does not play to my strengths. Frustration and stage fright further degrade my performance. So the take home test is much appreciated for people like me. I am happy to be left to my own devices when starting a problem, and happy to talk with peers once I have gotten myself oriented, but the initial process I use does not lend itself well to interrogation.


I too favor the take-home tests for these reasons, however, there's a difference between a 3-hour take home and 300 hour one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: