3 ms·
If it was trivial you would have completed the exercises, no? Truth is you're using age and "years coded" as a cover for competency. Hit the books, refresh yo
by brador 7y ago
If it was trivial you would have completed the exercises, no?
Truth is you're using age and "years coded" as a cover for competency. Hit the books, refresh your knowledge stack. There's no shame in improving.
- jerf 7y agoI'm 40. As it happens I like Haskell and I've spent some time with it, and I expect I could get through most recursion interview tests, so this is not sour grapes on my part, but: I really can see just how easily my career and hobbies could have turned so I would be a good developer that should pass interviews, but stumble and fall when trying to write a recursive version of some algorithm. (I'd add that in practice, almost nobody ever directly writes a recursive version of anything anymore. You should generally be using combinators like map and filter and the crazier stuff Haskell provides rather than directly writing recursion schemes by hand. It does happen in Haskell for a couple of specific cases, but even the ones I can think of are exceptional cases for dealing with certain optimizer corner cases, not places where it was absolutely necessary to write direct recursive code. Even for a pure-FP job I wouldn't hammer on it in an interview; I'd want to very rapidly move up the stack to more interesting and relevant questions in our precious interview time. I suppose it's an integration testing approach to interviews rather than unit testing; I'd rather find something where recursion is used in passing to ensure that you've got it than sit there and pound on that specifically. It's not a good interview question unless that's all your interviewee can handle.)