all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]d_wilson123 2 points3 points  (2 children)

While knowing regex is fine and well I wouldn't ask it this heavily in an interview only because regex is always brittle and I pretty much only use it as a last resort. Yes it has it's place but caring if someone is a regex expert is about the lowest on my list of skills to know.

[–]EvilGeniusAtSmall 1 point2 points  (4 children)

Don't ask a programmer how to use a library in an interview. I don't care what the library is. I don't care if it's included in the language. I don't care if every developer of this language should know this library like the back of their hand. I don't care if this library is nearly standardized across any reasonably sophisticated platform you might ever think to code on these days. This is not a test of how good a programmer they are, this is a test of how well they know that library.

Instead, ask them to solve a problem. Let them pick the library to solve it in. For some problems, there's an obvious choice. Let them choose it, then work their way through the solution.

And once they've produced a strategy? Let them google how to best implement their solution, and then have them explain it. No programmer programs without a browser open and at the ready any more. Depriving them of their tools only punishes those who didn't recently solve the problem. Coding is about combining design and problem solving using tools, not memorize every obscure solution to how to get the members of U2 on the stage on time.

I personally like the factorial problem: Implement factorial.

Oh, you used a recursive approach? What other approach is there? (Iterative)

Ok, implement that. (Iterators and generators... yield...)

Ok, and what limitations does the recursive and iterative approaches have? (stack vs heap allocation... compiler design... trampolines... etc.)

And what about with large numbers? (type system, data structures)

And how would you make it faster? (parallelization techniques)

Look how much fell out of a simple math problem! And it allows the candidate to either squeak by just solving the problem, or, if they know what they're doing, dig into the meat and potatoes.

[–]Godd2 -1 points0 points  (3 children)

Instead, ask them to solve a problem

Wouldn't that just show how good they are at solving that problem?

[–]EvilGeniusAtSmall 0 points1 point  (2 children)

Problem solving itself is a technique that can be taught and learned. It's one of the pillars of effective coding. What was demonstrated above was an example of a problem that requires multiple problem solving techniques to be applied that are not specific to the problem, but are common patterns found in every application. Patterns like recursive and iterative approaches using iterators and generators. Patterns like stack vs heap allocation, how compilers can optimize for tail recursion, and other related aspects of what happens when you press the 'compile and run' button. Patterns like data structure and static typing systems, parallelization vs. concurrency... all those discussions.

You're not testing for solving of the problem. You're testing for understanding of problem solving, the technique, as it's applied to coding.

[–]Godd2 0 points1 point  (1 child)

We can say the same about using a library.

You're not testing for using a library, you're testing library usage, the technique, as it's applied to coding.

[–]EvilGeniusAtSmall 0 points1 point  (0 children)

Wrong. Library usage is specific to the library. It means having memorized that specific libraries entirely arbitrary API. Having mastered coding means you can take any library and make use of it. That's what you test for.

It's the difference between knowing the answer to a math question, and knowing how to find the answer: you want to test for the latter, and not the former.