leetcode

[Neil Van Dyke]

Anyone have thoughts on whether there's anything Racket can/should do
involving Leetcode?

If you're not familiar, Leetcode is a site with bunch of coding
interview problems that huge numbers of CS students and professionals
work through.  For doing the problems on the site, there's several
popular programming languages to choose from (Racket and Scheme not
among them).  https://leetcode.com/problemset/all/

I just did three of the most popular problems tonight, in Racket/Scheme,
offline.  (Incidentally, in the official solutions writeups of all
three, I ended up finding what appears to be one outright incorrect
algorithm, and had nits to pick in each, over the discussion and
sometimes needlessly inefficient coding.  And they strangely provide
little-to-no test cases in the official solution writeups I've seen so
far, when I'd say that figuring out good test cases should be a
fundamental part of every solution process.)

One thing I found with my code[1] is that it's probably not good for
*selling* people on Racket.  If you don't know a Lisp, and you look at
this Racket/Scheme code as well as the Java or C++ official solution, I
suspect this code looks bulkier and less familiar. Though, for example,
one of their solutions, if you tried to really understand an
optimization they were doing, their coding style actually obscured that,
and the Scheme code could've done that same approach in a way that was
easier to step through exactly what's going on.[2]

Also, I suspect that going to a lot of trouble to publish better
solutions, and crits of the official ones, won't impress many. Although
I saw one of the official solutions go into excessively detailed big-O
analysis, and I suspect most everyone doing Leecode has Intro Algorithms
as an accomplishment they can rightly be proud of, I suspect that the
majority of people just want to survive the all-important whiteboard
hazings, and the self-image/aspiration after that is more "I get it
done".  I suspect that Racket will already be assumed to be for
academics, so academic-ing Leetcode problems harder won't change that,
and these contrived whiteboard problems I've seen so far don't really
lend themselves to Racket's relative practical strengths.

I suppose one possibility might be to get Racket or Scheme considered an
official language for Leetcode.  Simply having it appear on the menu on
leetcode.com is a boost of credibility.  I doubt many employers will
want to see Racket/Scheme in any case right now (and schools I've seen
seem to be targeting a popular language, for internships and whiteboard
interviews), but students and professionals will see it.  Maybe: not
being on that list says we're definitely not relevant; being on the list
says we might be. Plus a few "what's this new Racket/Scheme thing?" leads.

Other ideas for involving Racket and Leetcode?


[1] Style-wise, for this exercise, I did pure-functional (which was easy
and efficient for all of the 3 problems thus far), and in only R5RS plus
Racket hashes and my unit testing library, and favoring named-`let`. 
FWIW, for the constant factor details, I also assumed a modestly good
compiler, I micro-optimized a bit more than I had to (e.g., avoiding
redundant branching in imagined target code), and I didn't assume
allocations/GC were free.

[Matthias Felleisen]

> On Jun 16, 2019, at 3:38 AM, Neil Van Dyke <ne...@neilvandyke.org> wrote:
>
> Anyone have thoughts on whether there's anything Racket can/should do involving Leetcode?
>
> If you're not familiar, Leetcode is a site with bunch of coding interview problems that huge numbers of CS students and professionals work through. For doing the problems on the site, there's several popular programming languages to choose from (Racket and Scheme not among them). https://leetcode.com/problemset/all/
>
> I just did three of the most popular problems tonight, in Racket/Scheme, offline. (Incidentally, in the official solutions writeups of all three, I ended up finding what appears to be one outright incorrect algorithm, and had nits to pick in each, over the discussion and sometimes needlessly inefficient coding. And they strangely provide little-to-no test cases in the official solution writeups I've seen so far, when I'd say that figuring out good test cases should be a fundamental part of every solution process.)

Undergraduates from NEU routinely report that when they follow the design-recipe teaching (purpose, examples, tests, templating), the interviewers soon move them to the next stage of the process. Or shorter, I can’t count the students anymore who see me and say something like “the design recipe saved my a.. during the interview.” (And then there are those students who know better :)

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.

And fwiw, we have anecdotes where places such as Amazon accepted students who coded their solutions in BSL or ISL+.


> One thing I found with my code[1] is that it's probably not good for *selling* people on Racket. f you don't know a Lisp, and you look at this Racket/Scheme code as well as the Java or C++ official solution, I suspect this code looks bulkier and less familiar.


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.

;; determine indicies i, j for Vec such that (Vec i) + (Vec j) = T
(define (find Vec T)
(define-syntax-rule (N) (in-range (length Vec)))
(define-syntax-rule (in k) (in-value (list-ref Vec k)))
(for*/first ((i (N)) (j (N)) (n (in i)) (m (in j)) #:when (= (+ n m) T)) (list i j)))

(equal? (find '[2 7 11 15] 9) (list 0 1))

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.)


;; - - -

You forgot [2].

— Matthias




> IThough, for example, one of their solutions, if you tried to really understand an optimization they were doing, their coding style actually obscured that, and the Scheme code could've done that same approach in a way that was easier to step through exactly what's going on.[2]

>
> Also, I suspect that going to a lot of trouble to publish better solutions, and crits of the official ones, won't impress many. Although I saw one of the official solutions go into excessively detailed big-O analysis, and I suspect most everyone doing Leecode has Intro Algorithms as an accomplishment they can rightly be proud of, I suspect that the majority of people just want to survive the all-important whiteboard hazings, and the self-image/aspiration after that is more "I get it done". I suspect that Racket will already be assumed to be for academics, so academic-ing Leetcode problems harder won't change that, and these contrived whiteboard problems I've seen so far don't really lend themselves to Racket's relative practical strengths.
>
> I suppose one possibility might be to get Racket or Scheme considered an official language for Leetcode. Simply having it appear on the menu on leetcode.com is a boost of credibility. I doubt many employers will want to see Racket/Scheme in any case right now (and schools I've seen seem to be targeting a popular language, for internships and whiteboard interviews), but students and professionals will see it. Maybe: not being on that list says we're definitely not relevant; being on the list says we might be. Plus a few "what's this new Racket/Scheme thing?" leads.
>
> Other ideas for involving Racket and Leetcode?
>
>
> [1] Style-wise, for this exercise, I did pure-functional (which was easy and efficient for all of the 3 problems thus far), and in only R5RS plus Racket hashes and my unit testing library, and favoring named-`let`. FWIW, for the constant factor details, I also assumed a modestly good compiler, I micro-optimized a bit more than I had to (e.g., avoiding redundant branching in imagined target code), and I didn't assume allocations/GC were free.
>

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7c80122b-6157-f75e-3994-d5e5d0503f90%40neilvandyke.org.
> For more options, visit https://groups.google.com/d/optout.

[Neil Van Dyke]

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.

[Matthias Felleisen]

We’re way way way off topic here, so I’ll

> On Jun 16, 2019, at 3:01 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:
>
> Just to define my terms, I distinguish Leetcode-style "coding tests" from the old MS-style "puzzles" that Google later adopted for a while

I equated puzzles w/ undergraduate algorithm regurgitation knowledge.

> I'd be pleasantly surprised if Google, for example, doesn't insist on the hazing ritual battery for every single one of them, however.

Yes Google knows. I spent quite some time talking to a person who analyzed the problem. What Google doesn’t know is what to replace it with.

As for our undergraduates, they may not be up there with the best algorithms-memorizing interviews for their co-ops, but they are told to fall back on the HtDP design recipe. And that impresses a certain class of interviewers. (As it did Google.)

> 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

As I wrote. patterns in code make me so unhappy that I abstract them, using the minimal tool necessary.

But when I scanned this dumb discussion you pointed me to, I couldn’t resist stooping down to their level :))

"Does it matter that for loops don't leave a stack trace? How can poor programmers debug them w/o a stack trace?”

— Matthias :)