3 ms·
But that is not a mental puzzle. It's a straightforward march of thinking. Programming as a craft, generally, does not have a "great filter" like medicine, civ
by vjerancrnjak 4y ago
But that is not a mental puzzle. It's a straightforward march of thinking.
Programming as a craft, generally, does not have a "great filter" like medicine, civil engineering or aerospace. The longer one survives in these fields, there's a really small chance of surviving out of luck and not out of experience.
If you look at carpentry instead, the mental part of the craft is also one thing you can test. For example, you might provide a limited set of tools (like arrays and loops) and require a solution to a carpentry problem. The mental part is not tested by puzzles (by puzzle I assume there's a set of tricks you need to know, or in the case of programming, a particular algorithm), but by problems. Problems might be more concrete for carpentry.
The problem above with buses can be reframed into whatever the area of programming expertise is for a candidate. There's a simple underlying structure in the problem that can appear in web dev, networking, databases, that maps directly to that bus problem. If you cannot figure out the buses, then how will figuring it out for something else be simpler? The solution is just loops and arrays, there's no fancy algorithms, there's no fancy math, it's pure art of programming.
Like I said, it's only one part that you're testing, which is thinking/problem solving. It can also be affected by personal anxieties or whatever. Failure at a particular problem does not mean much. But I would not say that these kinds of coding tests break hiring.
I mean, I hear people are being asked to pick if they're more hardworking or creative, or to describe where they see themselves in 10 years, or some other similar abstract silly stuff. I'd much rather someone asks me about buses.
- belter 4y agoOk. Let's put your theory to the test by making this more concrete:-) You are working as an Interviewer for a FAANG and the six candidates today for a SWE position are: - Linus Torvalds - John Carmack - Fabrice Bellard - Guido van Rossum - James Gosling - Donald Knuth What "puzzle" are you proposing?
- vjerancrnjak 4y agoThe proof of their experience is publicly visible. That is not the case for most individuals, including me. FizzBuzz is not a puzzle solvable only with an obscure trick, and easily maps to real world, the buses problem too, and I can list more problems that are solved with 1-10 lines of code but the initial attempt used 20-50 because the structure of the problem was not fully exploited, unnecessary passes over the data, too much intermediate state etc. (all of the listed bloat appears in real world all of the time) There are no tricks, no maths, no algorithms, no data structures involved. Your ability to pattern match these little bits should grow with your experience.
- deleted 4y ago[deleted]
- belter 4y agoIf that is the case, why do experienced Software Engineers, have to spend again, weeks on LeetCode as soon as they decide to get back to the Interview circuit? And why are so many competitive programmers,(not all) terrible Software Engineers? https://kislayverma.com/organizations/competitive-programming-is-useless/ https://kislayverma.com/organizations/competitive-programmin... https://www.freecodecamp.org/news/mythbusting-competitive-programming/ https://www.freecodecamp.org/news/mythbusting-competitive-pr...
- vjerancrnjak 4y agoMy first response focused on problems that do not require knowledge of any named algorithms, data structures, math or tricks. I even mentioned I do not care about heaps, linked lists etc. I'm not sure how we're back at LeetCode. Of course you're going to have to spend weeks on LeetCode if interview questions target knowledge of dynamic programming, heaps etc. You're preaching to the choir. My point was that FizzBuzz might test individuals to see if they can code, but there are "harder" problems that happen on a daily basis, and the amount of years you put in will affect your ability to pattern match. Competitive programming captures a part of the essence of programming, you're writing minimal, fast and efficient programs. You improve your pattern matching to minimize the amount of intermediate state, unnecessary loops etc. After some point, competitive nature pushes you to specialize, and then it probably stops making sense if you want to make programming your craft.