Matthias Felleisen wrote on 6/16/19 12:30 PM:
Of course, good companies know by now that these “puzzle” questions are bad at identifying good (as in above-average) sw devs. Only the average companies still use this method because they are way behind. You want people who think systematically and leav code behind that others comprehend down the line.
Just to define my terms, I distinguish Leetcode-style "coding tests" from the old MS-style "puzzles" that Google later adopted for a while -- Leetcode-style is more more undergrad Algorithms and Data Structures homework problems that most people never use again.
AFAICT, the vast majority of dotcoms still do Leetcode-style new-college-grad "coding tests" for software jobs at all levels -- the FAANGs, the non-FAANGs, and all the fresh-out-of-school startups who mimic what they heard everyone else does.
(There's a longer discussion about the various reasons this is done; and it seems sometimes not only for evaluation, but also for hazing/pledging/posturing. And an imbalanced dynamic, possibly arrogant -- note that it's always only one-way, with no opportunity to evaluate the person who's making you do the whiteboard dance for their amusement. Cartman of South Park demonstrated this dynamic with a variation on the game Roshambo.)
If you mean that your undergrad students aren't pretty much always getting Leetcode-style undergrad coding tests for pretty much any software job, maybe your program has an exceptionally good reputation with some employers, perhaps in combination with an coop/internship program trial period. I'd be pleasantly surprised if Google, for example, doesn't insist on the hazing ritual battery for every single one of them, however.
And fwiw, we have anecdotes where places such as Amazon accepted students who coded their solutions in BSL or ISL+.
This is great. And it makes sense. A particular language is only a small part of what a new grad or coop/intern needs to ramp up to being a good software developer, and can be picked up like everything else, so focusing on that one thing doesn't make sense. A lingua franca for interviewing is convenient, but not necessary.
Now I'm wondering even more, whether should try to get leetcode.com to add Racket or Scheme to its menu.
I looked at the solutions for the first problem (’sum’). I think idiomatic full-fledged Racket will look fine. I use d-s-r because I hate repeated patterns.
That's an interesting way of doing it, and I'll have to ruminate on it, but you're hurting my advocacy argument on HN yesterday, about when macros are best used in Racket. :) https://news.ycombinator.com/item?id=20191406
It includes a “test”. But yes, I can see how plan R5 would look very bulky here, except if you can figure out ‘do’. (This has been a iong running argument with a local colleague here who loves R5.)
I think an R5RS style fits, for example, an early phase of a particular pedagogic approach I have in mind. Big quick paragraph, in case anyone cares... I'd poach experienced programmers into Racket, possibly learning on-the-job, by starting with the more familiar algorithmic bits of R7RS, while telling them that unfamiliar stuff is coming next, but they can start working with this (hopefully not like a movie villain telling the hero, "we are not so different, you and I"). With unit tests from the very start, starting with exposing/understanding the language, rather than designing and validating their code. Then, after a little practice with that, have them try an exercise of writing without mutations (maybe heavy on recursive with named-`let`). And only after experience with that, show them things like the Racket `for` family (once they know how to get their recursive algorithms exactly right without those, before they get into a habit of shoehorning). (Well, maybe I can show `for` early, for immediate productivity and appeal, and then tell them to stop using it for a while, as an exercise.) Then some experience with that, before we get into syntax extension (so had a sense of how to do things without syntax extension). And never introducing `eval` (for perhaps at least a year, until people already know how to solve most every problem without it). In parallel with this, convey a particular school of thought about various higher-level software development stuff, which will be at least slightly different than what they already know. I think this might make for very solid Racket/Scheme developers, and a doable progression that has them able to start being productive within a day (of course they'll probably want to rewrite that code later, once they're not writing Pascal in Scheme syntax, but the code will probably still work until they get around to that), and mixing together progression of abilities with modest exercises that shouldn't slow productivity much (e.g., the no-mutations exercise).
Thanks for your comments. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/0ef85e89-d8ee-2925-afd8-485588496f83%40neilvandyke.org. For more options, visit https://groups.google.com/d/optout.
