Re:What's Wrong with Tech Hiring
by ChrisMarshallNY on Thursday September 16, 2021 @11:57AM
(#28553425)
Easy is not the point. Neither is “fair.”
I can usually do … OK … on these tests, but I’m probably mediocre, at best, as it’s often the first time I’ve encountered the test.
I tend to write naive code at first, and make sure the result is solid, then optimize. I will sometimes also experiment; trying out all kinds of harebrained stuff, before settling on even that “first try” code.
That workflow has worked extremely well for me, in my vocation, but does not present especially well, in quick whiteboard tests.
My workflow results in very high-quality, performant code, but iteratively. Also, not all code needs to be optimized. Sometimes, leaving the naive code, means it is more maintainable. I also habitually document my code as I go, which has proven unpopular, with testers.
People just out of school, or who spend hours each day, practicing LeetCode, will usually come up with an optimal solution, done the way the tester expects, first go.
Re:What's Wrong with Tech Hiring
by thebean11 on Thursday September 16, 2021 @12:32PM
(#28553873)
Sure, that's fair, but in both binary tree examples I listed the most efficient answer pretty much is the naive answer. I don't think you need to be fresh out of school to remember how binary search is implemented.
Re:What's Wrong with Tech Hiring
by chowells on Thursday September 16, 2021 @12:11PM
(#28553618)
That's what I do, and I have no trouble communicating that during a whiteboard interview. Have you considered that you're being tested for communication ability?
I can usually do … OK … on these tests, but I’m probably mediocre, at best, as it’s often the first time I’ve encountered the test.
I tend to write naive code at first, and make sure the result is solid, then optimize. I will sometimes also experiment; trying out all kinds of harebrained stuff, before settling on even that “first try” code.
That workflow has worked extremely well for me, in my vocation, but does not present especially well, in quick whiteboard tests.
My workflow results in very high-quality, performant code, but iteratively. Also, not all code needs to be optimized. Sometimes, leaving the naive code, means it is more maintainable. I also habitually document my code as I go, which has proven unpopular, with testers.
People just out of school, or who spend hours each day, practicing LeetCode, will usually come up with an optimal solution, done the way the tester expects, first go.