Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScripting the technical interview

richard-towers.com

Post reply on HN
Print view View original

141–150 of 180 posts

Re: TypeScripting the technical interview

#141

Post by jtinder »

An amazing read, and almost perfect!

There's a bug in the Solve "function" due to which you'll get the right answer only for 1x1, 5x5 and 7x7 (I checked till 8x8).

The base case makes a wrong assumption that there will always be a candidate available for the last row. If there are no candidates available, it should return Nil, and backtrack.

Basically, replace

  Concat
with

  candidates extends Cons
    ? Cons
    : Nil

Re: TypeScripting the technical interview

#142

Post by hnbad »

wiseowise wrote: post #78
siriusfeynman wrote: post #72

Earlier quoted context omitted.

Which is exactly the point, it's a leetcode question that tests whether you've memorised a bunch of leetcode interview questions

> classic backtracking problem Literally in the parent post.

> Backtracking is extremely important in today’s software interviews and almost always comes up in some form.

From TFA. Even the article struggles to explain how this is useful outside similar leetcode questions. Yes, backtracking is sometimes a useful approach for some real-life programming problems but leetcode questions neither test for the ability to recognize backtracking problems nor the general ability to solve them.

Re: TypeScripting the technical interview

#143

Post by hoseja »

efficax wrote: post #109
nine_k wrote: post #101

Earlier quoted context omitted.

Were this true it would be terrible, because Turing-completeness necessarily includes non-termination. This would mean that a compiler would crash, or get stuck in an infinite loop.

yes, all turing complete type systems make it possible to define type structures that would cause infinite loops, but typically they are able to detect this and refuse to compile

-_-

“Oh, right.” He blusters a non-termination argument at nobody in particular. “That’s why we usually think in subsets of Haskell where types don’t have bottom values.”

Re: TypeScripting the technical interview

#144

Post by aw9f70gae »

girvo wrote: post #73
hnfong wrote: post #26

Earlier quoted context omitted.

I'd say it's "inspired" rather than "translated". The part about using the typescript language server to compute the solution, and the protagonist claiming the code is "concise" because only 4 lines of javascript were generated, was absolutely brilliant. Cracked me up at least. Glancing at the actual code, I admit I'm with Criss in my ability to follow the logic, but it doesn't look like a direct translation from Has…

I know my mind is decidedly poisoned when I could follow the type definitions perfectly, and they reminded me of certain types I have written myself… ah, TypeScript, what have you done to me…

How does one even come close to such wizardry

Re: TypeScripting the technical interview

#145

Post by irrational »

wiseowise wrote: post #79
irrational wrote: post #66

Earlier quoted context omitted.

I’ve been hiring developers for decades at a Fortune 100 company and have never engaged in such nonsense. Unless you are hiring people to program chess sets, the question in the article is foolish. If you want to test their problem solving or coding skills, give them a problem from the actual work they will be doing at your company.

> Unless you are hiring people to program chess sets, the question in the article is foolish. Ever heard about word “abstraction”?

Sure. But do you know how often I’ve had to do backtracking in 25 years of professional programming? Zero times. Maybe the person is interviewing for a position where this kind of leetcode question is applicable, but in my experience this question is not abstracting real normal day to day problems.

Re: TypeScripting the technical interview

#146

Post by thih9 »

I’m unfamiliar with TS. Could someone explain this part?

> Invoke the compiler

    $ tsc *.ts --lib esnext --outFile /dev/stdout 
    var ᚾ = Symbol();
    var ᛊ = Symbol();
    var ᛚ = Symbol();
    var ᛞ = Symbol();
Why is there so little output? Is that because the compiler removed the unneeded types? And the author is implying that the task was boilerplate and pointless?

Re: TypeScripting the technical interview

#147

Post by agmyintmyatoo »

thih9 wrote: post #146

I’m unfamiliar with TS. Could someone explain this part? > Invoke the compiler $ tsc *.ts --lib esnext --outFile /dev/stdout var ᚾ = Symbol(); var ᛊ = Symbol(); var ᛚ = Symbol(); var ᛞ = Symbol(); Why is there so little output? Is that because the compiler removed the unneeded types? And the author is implying that the task was boilerplate and pointless?

Everything is only in type system providing developer type-hints. When compiled, it all boiled down to plain js.
Post reply on HN