var a = 10;
function foo(){
console.log(a,b);
var a = 20;
var b = 30;
c = 40;
}
foo();
console.log(a, c)

--------------------------------------------------

console.log([1,2,3,4,5,6].map(e => e < 3))

--------------------------------------------------

const a = [1,2,3];
a.push(4);
const b = a[5]
console.log(a,b);

--------------------------------------------------

for(var i = 0 ; i < 5; i++){
setTimeout(function (){
console.log(i);
},0)
}
console.log(i).


Can anyone Put there views on this? what can be the probable answers for this.
Thanks in advance

If those are the test questions, I guess the position was for a entry-level JavaScript developer.

With a browser in front of you, determining the actual output should be trivial - if you're not yet capable of that, you need to start at the beginning - maybe check MDN for learning resources / tutorials.

If the issue is understanding why the behaviour is as it is, you need to understand scopes and search MDN for any keywords/functions you don't understand.

1 members found this post helpful.

As stated by boughtonp, these weren't interview questions, but a sample test. And not to sound nasty, but if you can't answer them or don't understand the questions, you're not qualified for the job.

If we tell you the answers here, what's going to happen if you get the position?? Are you just going to ask forums everywhere how to do the job you just got??? And your own profile says:
So you're a CS and Engineering graduate, who is 'passionate' about programming....and these stumped you??

2 members found this post helpful.

I dunno ... I just don't like "interview test-questions." I never did. I often thought that the people who wrote them were just trying to be clever. What I really want to know is how a candidate would view a problem – what his initial thoughts as to an approach might be. If he does not know the particular vagaries of a particular language, he can find it out quickly enough and/or ask for assistance. But, can he think?

2 members found this post helpful.

Well, I assume the point of the interview questions were to see if you knew Javascript well enough to predict the output just by looking at the code. Now that the interview is over, all you need to do to actually find out is to paste that code into your web browser's Javascript console.

1 members found this post helpful.

Honestly, @dugan, I just think that questions like these are – at best - "edge cases." No one should ever write code like that, so they might not know what such code would do.

I remember, many decades ago now, when a vendor of a debugging tool would publish code snippets in their [magazine ...] advertisements and challenge the reader to predict what the code would do. While teaching a programming class at the local community college, I actually handed out copies of one of those ads and said: "Don't write code like this!"

"Code like this" is "clever." And it almost instantly becomes indecipherable, even if you wrote it. When I go back to look at source-code that I myself wrote just a few months ago, I completely rely on my comments, written at the time, and on "simple" coding practices that I try to make "stupid obvious." Cleverness is not my friend; nor should it be yours.

Ummm ... #undef SOAPBOX

2 members found this post helpful.

Looks like pretty fundamental code to me there.

I don't prefer "trick" interview questions intended to trip candidates up.

If a candidate doesn't understand code, show an ability to learn, show any thought process, or debug abilities, then it's on to the next candidate.

I also find it very difficult to believe these were the only questions, or instead the hiring company provided a first screen page like those questions to save wasting time before they got into more difficult topics.

1 members found this post helpful.

Agreed...I think it's more likely they're homework questions, to be honest.

1 members found this post helpful.

I missed this from TB0ne's post earlier.

Whether or not you think any initial questions may be too difficult or unfair, you haven't said this, but think about this.

You are likely seeking software engineering roles or something close, salaried positions of high value compensation.

Do you (hopefully not) have a misperception that companies wish to bring in someone who can't program in a primary language which they most likely cited as a requirement for the role?

As a new graduate they realize you will be learning, employers very much will expect that you have absorbed your lessons from college, and further, gone beyond it potentially. The candidates who stick out and get jobs sooner and obtain higher offers, demonstrate that they can, and have, taken their lessons further. Like they didn't get stuck and stopped, instead they dug deeper and learned more than the average student.

2 members found this post helpful.

I was a member of the second class that could earn a "Computer Science" degree at my local University. Yes, I was one of the guinea pigs, although I didn't know it at the time. But, computers were (and still are ...) my hobby, and I basically taught myself.

But, these days, the technology is "arguably, bewildering." You cannot possibly "know all of it," and even if you could do so today, tomorrow would inevitably be different. So, "if you are any good at this," today you are able to quickly learn whatever it is that you need to know, and apply it.

This is what I meant when I said, "But can you think?"

Very interestingly, I have found for myself that I learn whatever I need to know, but then forget it. I can look back on archives of projects done even a year ago and now it seems like "the work of a complete stranger." I recognize that the comments were of course written by myself, but I must re-learn what they meant. (Which is precisely why I write comments on-the-spot and with such detail, capturing my immediate thoughts at that instant.) As the hokey song says: "It's all com - ing back to me now ..."

One thing that strikes me about these questions: two of them deal with the non-intuitive behavior of "var", and would be more straightforward if "var" were replaced with the newer "let" keyword.

Anyway, anyone who wants to try them out can just paste them here:

https://replit.com/languages/nodejs

This ^^^^^^^^^

It's the same reason I cringe when I see someone struggling to be clever with a one-liner -- in any language -- when a much clearer implementation is going to work out in the long run. As you said that "source-code that I myself wrote just a few months ago" can turn out to be pretty opaque when you come back to it to tweak it or borrow a bit of the code to use elsewhere. If the task requires doing something "clever", document the heck out of that code---you won't regret it.

This is an interesting question. If you want to do your best (because of performance or any kind of optimization) probably you will write code which cannot be easily understood by others. Because you are an expert and you can do it much better.
The question is: should you write your code for dummies (just to make it maintainable and understandable for everyone) or fine tune it to the limits (and probably dummies will not even understand your comments and will not be able to extend it - only if they also become experts).

False dichotomy.

Code written by good/senior developers ("experts") is more maintainable and understandable - by all developers - than code written by mediocre/mid-level developers and new/junior developers. (It is mid-level developers that are often the problem, having learned enough to be dangerous; new developers tend to lack the knowledge/experience to write overly convoluted code, and if they do it generally holds little value and can be scrapped/rewritten.)

Code should not be targetted at new/junior developers ("dummies") - otherwise those developers will never improve and the software will remain as if written by newbies - but that is not at all the same as producing a cryptic mess of obtuse one-liners with poorly named variables.

In the rare situations where code is necessarily dense/unclear, experienced developers already know how to make use of the available options to ensure clarity in what it does and how to handle any issues it might have, and will want to do so.

3 members found this post helpful.

That is unfortunately not true. Beginners use only part of the language elements and also they do not understand everything. Therefore what you wrote is just a wish (more maintainable is true, by all developers is false).

Furthermore code is not written to improve the skills of beginners. That is just nonsense, the real goal is to implement a feature (and probably make money).