Live data from Hacker News

JSFuck (2012)

jsfuck.com

111–120 of 168 posts

Re: JSFuck (2012)

#111
post #53

Earlier quoted context omitted.

The right type of answer for that is to laugh and say, "you should ask the fool who wrote that code instead of asking me."

This kind of thing does happen in the wild, through no fault of anyone in arms' reach, in particular when service APIs change in subtle and unexpected ways. You might have a service that yesterday returned a JSON payload: { tasks: 5, ... } but today returns: { tasks: [{...}, ...], ...} If you had an array of these objects and were trying to sum the count of tasks, now your code returns weird results. Knowing how the…

Sure, but in the wild, you would actually run the thing in the repl to see what it does. So either you know the answer or you don't and it doesn't affect whether or not you can do the job well. In my opinion binary knowledge-based questions are seldom useful unless you specifically are checking for that exact knowledge. You can have someone who is totally terrible in general but just knows that one thing or the answer to that specific trick question and you can have people who would be fantastic for the role but either don't know the answer or can't think of it because of a mental block in the moment. ie the false negative and false positive rate are too high and your question is just a random classifier.

Questions that allow a person to show their skill and their thought process are much more revealing. They're much harder to fake and bluff your way through for poor candidates and they allow good candidates to show their skill. They require a bit more effort from the interviewer though because there isn't just one right answer and you have to sacrifice the idea that you get an ego boost by dunking on some poor candidate with your trick question.

An example of a question I used to ask when interviewing candidates who said they were good at unix: "Say I have a directory full of files called a, b, c, etc and I want to rename them all to a.bar, b.bar, c.bar etc how do I do that"? Then I would follow up with "Ok now I have a directory full of files called a.bar, b.bar, c.bar etc and I want to rename them back to a, b, c, how do I do that?".

Now if you know unix you know there are a bunch of ways to do this, there are a bunch of traps you can fall into, what if there are too many files for shell expansion, what if the file names contain spaces etc. It's not hard for someone skillful to come up with a few ways that deal with these issues and if they can talk through how they did it and why then any of them are fine.

Edit to add: There is a kernel of value here though, which is say you were debugging a thing where the result was an empty string and you thought "wow, that makes no sense", maybe you get to understanding what went wrong when you see that two arrays are getting type coerced or something.

Re: JSFuck (2012)

#112
post #49

Earlier quoted context omitted.

In case anyone is wondering, the answer is '' (empty string).

How can adding two empty arrays give you an empty string?

The + operator doesn’t work on arrays, but tries to cast the sides of it to a string. Arrays implement the toString function, which shows the toString of the individual values comma separated. An empty array returns an empty string. Which means that this is equivalent to empty string + empty string.

[ ‘foo’, ‘bar ] + [ ‘baz’ ] would return ‘foo,barbaz’

Re: JSFuck (2012)

#113
post #69

Earlier quoted context omitted.

Because it's broken for my usecase, and I need to do something slightly different on the webpage

You shouldn't have access to it -- it's on my private servers doing stuff for me. How did you get it? I think the problem with this thread is people think I am writing browser code, or code that is going to be shared on GitHub. I am not. Also I'm only half joking as I've indicated with the "/s" below.

> You shouldn't have access to it -- it's on my private servers doing stuff for me. How did you get it?

Seems like the logical solution would be to restrict access to it then, rather than obfuscate it making it harder for yourself to maintain. But hey, you do you.

Re: JSFuck (2012)

#114

Earlier quoted context omitted.

I think I might've actually analysed the code you're describing. We even made a few tweaks to the code so that you couldn't just reverse it back into JS This is why a lot of us keep our tools private... an old tradition of the cracking scene going back decades to the 80s. Think of things like IDA/Hexrays and Ghidra, then realise the most prolific crackers had similar private tools they had written many years before t…

>This is why a lot of us keep our tools private How ironic, that you want to open up other peoples code but keep your own hidden.

Not really ironic or related. The privacy here is, well, keeping the tools entirely private -- no distribution or highly limited distribution, not obscuring their function.

Irony would be applying obfuscation or other DRM protection techniques to tools intended to de-obfuscate/reverse engineer which are then distributed/sold. This is fairly common in commercial reverse engineering solutions, although I don't think the irony of the cat and mouse game is lost on the authors in that case...

Re: JSFuck (2012)

#115

Earlier quoted context omitted.

You shouldn't have access to it -- it's on my private servers doing stuff for me. How did you get it? I think the problem with this thread is people think I am writing browser code, or code that is going to be shared on GitHub. I am not. Also I'm only half joking as I've indicated with the "/s" below.

> You shouldn't have access to it -- it's on my private servers doing stuff for me. How did you get it? Seems like the logical solution would be to restrict access to it then, rather than obfuscate it making it harder for yourself to maintain. But hey, you do you.

At the bottom of the thread I explain the intention is to protect against unauthorized access.

I also wouldn't obviously edit the obfuscated production code, so it wouldn't really be a problem.

Re: JSFuck (2012)

#116

Earlier quoted context omitted.

I think I might've actually analysed the code you're describing. We even made a few tweaks to the code so that you couldn't just reverse it back into JS This is why a lot of us keep our tools private... an old tradition of the cracking scene going back decades to the 80s. Think of things like IDA/Hexrays and Ghidra, then realise the most prolific crackers had similar private tools they had written many years before t…

>This is why a lot of us keep our tools private How ironic, that you want to open up other peoples code but keep your own hidden.

why not - after all, none of the open source licenses say that you must actually distribute the program, they only say that you should also include the source code if doing so.

Re: JSFuck (2012)

#117
post #48

Earlier quoted context omitted.

That's an idiotic interview question. I've experienced this at young companies where both the company and its engineers are too immature to understand basic etiquette in the industry. Btw I doubt Google would ask a stupid "gotcha" question like that. They tend to ask hard algorithmic questions.

FWIW I’ve had Google recruiters ask me stuff where they don’t understand the answer and the questions are things like “what is the protocol number for ICMP” and “what port does NTP use”. If one doesn’t work with these things very often, they’re very forgettable as they’re so easy to google and find the correct answer to in seconds, and therefore not worth memorizing. No idea if they’re still doing this, but it was li…

Is a pretty silly question too, since NTP uses whatever port you set it to.

Re: JSFuck (2012)

#118
post #43

Earlier quoted context omitted.

I think someone once asked me the simplified variant of that question. What is the result of: []+[] And I didn’t know the answer to that (I mean, who does that kind of fuckery in Javascript, you can’t sum arrays). I would have no chance with these Google level questions.

This is in my opinion actually a decent interview question. If you know JS in detail, if you know how the "+" operator works, it's a super easy question. If you don't know JS in detail, if you don't know how the "+" operator works, it's pretty tough. If you want an engineer who knows JS in detail, asking this question can be valuable.

That may be relevant if you are working on a javascript engine, not if you build webapplications.

Re: JSFuck (2012)

#119
post #70
post #43

Earlier quoted context omitted.

I think someone once asked me the simplified variant of that question. What is the result of: []+[] And I didn’t know the answer to that (I mean, who does that kind of fuckery in Javascript, you can’t sum arrays). I would have no chance with these Google level questions.

"let's try running it and find out"

Haha, yeah, that was about my answer. “No idea, but now that you ask me I’m interested.”

Re: JSFuck (2012)

#120

Earlier quoted context omitted.

Did you have a legitimate reason to make things harder for reverse engineers?

Why are you reverse engineering my code in the first place?

Because you gave it to me to run it. I want to know what is it exactly that I'm running.

Also, why do you mind me doing that?

Post reply on HN