12 ms·

Without leet coding, named algorithms (binary search, dynamic programming, and other esoterica) or data structures (only requiring knowledge of arrays, assoc ar

Without leet coding, named algorithms (binary search, dynamic programming, and other esoterica) or data structures (only requiring knowledge of arrays, assoc arrays, loops is enough), coding interviews still allow you to demonstrate your thinking ability. You can construct various simple problems (that require only loops and arrays) that can easily be mapped to real world problems and see how well the programmers perform (problems: that exploit the fact that input is sorted, linear search for min/max, collect data -> loopy state transition -> output state). A fictional scenario that you can map to a real software problem, there's 7 cities, N people (program input) in city 0. 6 buses, one goes from city 0 to city 1, other from 1 to 2, ... last from 5 to 6. Bus has a limited capacity (6 additional program inputs). Everyone needs to be at city 6. Time starts at 0. One time tick: all buses go from city X to city (X+1), unload people at city (X+1), and then go back to city X. What's the minimum time it takes for everyone to be at city 6? There's 7 inputs (N people and bus capacities) and there's multiple programs one can write to solve the problem. There's no math tricks, no data structures. You can write a program whose time complexity depends on the size of the inputs O(N), or just on the number of inputs O(7), or maybe something worse or in-between. I have no idea if there is a way for one to teach/learn how to write the simplest program as soon as possible, but some will find it in 1 minute, some in 60 minutes. The amount of time it takes might be irrelevant and the only thing you're looking for is the ability to eventually think simple enough. And the thinking bit is not the only filter. The person might struggle to use the computer (but uses it well enough for these simple problems), might have no idea about the machine that runs the program, etc.

menaerus 4y ago
You throw some good arguments and although I am not in agreement with such methodology let me ask would you apply the same process when hiring a senior engineer with a demonstrated experience of N+ years in tech you're looking for? Isn't that off putting and isn't that ingraining distrust from the very beginning?
- vjerancrnjak 4y ago
  It is just an attempt to shortly evaluate the experience listed on paper. Thinking is only one aspect of programming. Are open form questions for which the candidate can give an honest answer or that start a discussion better, or do you find them similar to a simple coding problem? What if during discussion I probe for more details about one particular thing? Just to be clear, I agree that coding questions can be ridiculous. These do appear in some interviews. Questions related to quicksort, radix sort, counting sort, heaps, Dijkstra, 0-1 bfs, dfs, iterative deepening, prime testing or integer factoring, or convoluted problems of counting the many ways of tiling a n x m grid with 2x1 and 1x1 tiles, can all be found in the wild. My buses problem is completely different and simpler.
belter 4y ago
You see but here is the thing... Let's say I am interviewing, for their corresponding roles, one of the Aerospace Engineers responsible for the design of the latest Airbus, or a specialized heart surgeon with 10 years of experience, or a Civil Engineer that lead 5 year projects building bridges crossed daily by thousands of persons. What kind of look would they give me....If I start throwing them the type of mental puzzles like that, that you typically find on the back pages of newspapers on dentists waiting rooms:-)
- 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 ago
    Ok. 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?

menaerus 4y ago

You throw some good arguments and although I am not in agreement with such methodology let me ask would you apply the same process when hiring a senior engineer with a demonstrated experience of N+ years in tech you're looking for? Isn't that off putting and isn't that ingraining distrust from the very beginning?

vjerancrnjak 4y ago
It is just an attempt to shortly evaluate the experience listed on paper. Thinking is only one aspect of programming. Are open form questions for which the candidate can give an honest answer or that start a discussion better, or do you find them similar to a simple coding problem? What if during discussion I probe for more details about one particular thing? Just to be clear, I agree that coding questions can be ridiculous. These do appear in some interviews. Questions related to quicksort, radix sort, counting sort, heaps, Dijkstra, 0-1 bfs, dfs, iterative deepening, prime testing or integer factoring, or convoluted problems of counting the many ways of tiling a n x m grid with 2x1 and 1x1 tiles, can all be found in the wild. My buses problem is completely different and simpler.

belter 4y ago

You see but here is the thing... Let's say I am interviewing, for their corresponding roles, one of the Aerospace Engineers responsible for the design of the latest Airbus, or a specialized heart surgeon with 10 years of experience, or a Civil Engineer that lead 5 year projects building bridges crossed daily by thousands of persons. What kind of look would they give me....If I start throwing them the type of mental puzzles like that, that you typically find on the back pages of newspapers on dentists waiting rooms:-)

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 ago
  Ok. 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?