As someone who is preparing to embark on my own technical interviews for the first time, this is an incredibly helpful resource. Watching this mock interview is easing my anxieties and helping me overcome my strong feeling of imposter syndrome. Thank you for sharing this!
This is probably my favorite mock. Very professional acting, knowledgeable of what he knows and doesn't but is able to express it without seeming like a bro.
I don't see how a self-taught beginner programmer has knowledge of things such as restAPI, strict comparisons, backend processes, recursion, depth first search implementations as well as a pretty decent high level overview of the language, after only a year. Very impressive!
The amount of hours required to go from zero to junior level job-ready is around 1,200h. That can be done in a few months to a year depending on the amount of time you put in. I'm at 300 hours mark right now (1.5 month in) as self-taught and solving most of the problems they give here instantly as I do a lot of codewars/leetcode. Covering all the topics you mentioned is easy, you can do it in a few weeks. Being good at them is a different story. Recursion alone took me a week of daily struggles to grasp the basics of it. I'm doing The Odin Project and most of the things you mentioned is covered later on into the course as well.
For the first question: Primitive values like strings are automatically converted to objects (wrappers) when you access their properties or methods. In this case, when you call a method on a string literal, JavaScript temporarily converts the string to a String object, which is why you see [String: 'racecar']. At the end, you're comparing a string literal to a string object using ===. To make it work, you can just compare values (==), or do something like, 'this.toLowerCase()', which will act on the string literal of the string object and return true. Confusing...I know.
Code question 1: The '===' operator checks for both equality and datatype. In this case, we are comparing and object string against a string, hence the equality will always return false. The fix: use '==' operator which will just check for equality.
I stopped the video in each question for find the response by myself, and the tecnifiqué part i resolved the problems by myself too and then I continued with the video. Was very interesting!
I never actually had a proper JavaScript interview, but your video demonstrates an accurate level of interview would be liked. It definitely nudged me into thinking more of a typical questions to why am I doing things in JavaScript, especially in the earlier stage of the interview questions about React, API, etc. The follow up coding interviews were very interesting. For example, if someone where to ask me about the MAP function, I should be doing ok, but coding it.... is another question.
These are extremely useful. Thanks a lot, Nader! I'd like to suggest a video that would advice on how to get recruiters' attention, to land the interview. Seems like a real struggle.
Great video, really helpful. Just curious why you want to create methods on the prototype instead of just using plain functions. This seems dangerous as it could collide with other libs that add methods to the prototype. Seems the trend is away from OOP to functional programming. Also in JS, 'this' always refers to an object, though strict-mode may modify that behavior but not sure.
56:09 Gavin actually had the right idea which is to pass in the result array as an argument to flatten. On the other hand, the implementation you suggested needlessly creates temporary arrays.
Good point! Yes, this can be done without the new array allocations but the code looks a bit messier since you need to use it in a closure or declare a separate/global function to use. If you have the code for it, it would be really helpful for others to see this alternative way since it can definitely be more space/alloc efficient 😊
The problem with this was that it's mentioned that it's a object in the docs right? That's why it was an object and we all know that everything in js is a object so when we use the String constructor and pass an object it returns the string. Let me know if you find any fault here
`this` is the string object, not the primitive since when you're doing "something".isPalindrome() it's not using the primitive (it would not have the method) -- it will use the String object, go to the prototype and consume the function if it exists. `this` in that context is the String object with all of it's methods from the prototype. So you can call `this.toString()` to get the primitive
thanks to share this helpfull video. I think in the first code question we can just use String function (not String constructor) to convert to string and make strict check on value.
Thanks to @zia on the Discord for looking in to the mystery of the String and this Object: Regarding this being an object but not a string literal, basically, when a function is executed, this is converted into an object if its not already. So string literal is converted into an an object which for string hello looks like {0: h, 1: e, 2: l, 3: l, 4: o, length: 5 } ECMAScript calls is string exotic object (just learned btw). TLDR: value of this keyword is always converted to an object. Conversion of this to an object: es5.github.io/#x10.4.3 String exotic objects: 262.ecma-international.org/14.0/#sec-string-exotic-objects
More simpler than that, I can just say that one is an object `String`, other is a primitive `string`. An instance of a String ""class"" is not identical to a primitive, but can be loosely equal. If you just used '==', it would work, or 'this.toString() === reversed'. A primitive is not an instance of a class, but JS automatically turns it into it with auto-boxing. That's why also "typeof String('hello')" returned primitive stringing console, it's internally "(new String('hello')).toString()". To check it in the prototype context: "typeof new String('hello')" => "object". And in the long run, that is makes confuses devs...
Palindrome question, is the solution used in the video better than iterating the string with a single for loop matching symbols from both ends of the string and breaking on the first mismatch?
the solution utilizes functional programming which is more or less specific to prototyping in js. so from the aspect of using a prototype, yes it's better
Single loop like that should be much more efficient and doesn't allocate unnecessary memory so it is better (more performant). Some could argue that 'functional' solution is more readable, but I'm not so sure about that as imperative one literally spells out how we think about palindromes and I think would read just as fast.
I think it is not a good idea to use String.prototype.isPalindrome and Array.prototype.myMap it will cause a lot of problems which is why you will never see someone using them in an interview or in a project. instead just use a normal function like: function isPalindrome, function myMap, etc
Can the palindrome task be solved in this way? Would appreciate your feedback :) String.prototype.isPalindrome = function (str) { if (str.split("").reverse().join("").toLowerCase() === str.toLowerCase()) { return true; } else return false; }; console.log(String.prototype.isPalindrome("racecar"));
Yes just not as readable in some opinions but you could also get rid of the else since you return out of the if statement and even remove the brackets. However you will have to use this unless you want to call it as String.prototype.isPalindrome(myString) vs using this and calling myString.isPalindrome(). One addition note is your version also requires a check to ensure it is a string being passed in. With the "this" version it will implicitly be type string since method only accessible through String prototype chain unless you did something like String.prototype.isPalindrome.call(myArray) which would also break the "this" option but would almost have to be intentional miss use // Replace "this" with str and add back to function signature for your version. String.prototype.isPalindrome = function () { str = this.toLowerCase() if (str.split("").reverse().join("") === str) return true; return false; }; console.log(myString.isPalindrome()) // Your version. String.prototype.isPalindrome = function (str) { if (typeOf(str) !== "string") throw new Error(''Argument must be a string"); str = str.toLowerCase() if (str.split("").reverse().join("") === str) return true; return false; }; console.log(String.prototype.isPalindrome(myString)) Also thank you for pointing this out I forgot to .toLowerCase in the video.
They only need to do: String.prototype.isPalindrome = function () { return this.split("").reverse().join("").toLowerCase() === this.toLowerCase() }; console.log("racecar".prototype.isPalindrome());
Are you sure this is for a junior position? I think it might be more suitable for a junior position at a FANG corporation. Given the salary range of 60k to 100k, these types of exercises would likely be appropriate for a mid-level software engineer.
I think it's unnecessarily confusing for a Junior Level interview to use the String.prototype.isPalidrome. Just let the guy focus on the main goal of the question which is to check for a palindrome with a simple function. :)
DSA is a BS way of determining employee value. But here. Anyone over 40 usually does poorly with these because we didn't have classes to learn, we taught ourselves. Now we are senior systems designers and we find solving these stupid puzzles ridiculous. Proves next to nothing. We hired someone who smoked all the DSA, on the job they were absolute trash. Couldn't even commit things to Git, had no idea about TypeScript, had no idea about the value of cohesive patterns. Just hot garbage hire, 9 months later, they left. DSA is a red herring at best. Libraries solve most of these, like Lodash, and if not, use AI to generate a starting point and optimize it. These are solved here for reference. I wrote these, but only because of interviewing. Interviewing is broken. They should be asking us to build something related to the job. Not this nonsense. O{n} version const isPalindrome = str => { const forward = str const reverse = str.split('').reverse().join('') return forward === reverse } The interviewer will then ask you to optimize it, which means remove the memory so O(1) version using pointers. const isPalindromeWithPointers = str => { let left = 0 let right = str.length - 1 for (let i = 0; i < str.length; i++) { if (str[left] != str[right]) { return false } else { left = left + 1 right = right - 1 } } return true }
this seem overly convoluted for a junior mock interview. Playing around with prototypes in this manner and creating things that already exist in JS ie map, flatten etc seems really odd.
As someone who is preparing to embark on my own technical interviews for the first time, this is an incredibly helpful resource.
Watching this mock interview is easing my anxieties and helping me overcome my strong feeling of imposter syndrome. Thank you for sharing this!
This is probably my favorite mock. Very professional acting, knowledgeable of what he knows and doesn't but is able to express it without seeming like a bro.
I don't see how a self-taught beginner programmer has knowledge of things such as restAPI, strict comparisons, backend processes, recursion, depth first search implementations as well as a pretty decent high level overview of the language, after only a year.
Very impressive!
The amount of hours required to go from zero to junior level job-ready is around 1,200h. That can be done in a few months to a year depending on the amount of time you put in. I'm at 300 hours mark right now (1.5 month in) as self-taught and solving most of the problems they give here instantly as I do a lot of codewars/leetcode. Covering all the topics you mentioned is easy, you can do it in a few weeks. Being good at them is a different story. Recursion alone took me a week of daily struggles to grasp the basics of it. I'm doing The Odin Project and most of the things you mentioned is covered later on into the course as well.
For the first question: Primitive values like strings are automatically converted to objects (wrappers) when you access their properties or methods. In this case, when you call a method on a string literal, JavaScript temporarily converts the string to a String object, which is why you see [String: 'racecar']. At the end, you're comparing a string literal to a string object using ===. To make it work, you can just compare values (==), or do something like, 'this.toLowerCase()', which will act on the string literal of the string object and return true. Confusing...I know.
or this.valueOf() to access the value
Autoboxing 🤨
It looks like a real interview. The guy are nervous but answers are good. The interviewer keeps calm and a very kind. I had the same experience)
Code question 1: The '===' operator checks for both equality and datatype. In this case, we are comparing and object string against a string, hence the equality will always return false. The fix: use '==' operator which will just check for equality.
your approach is right but it is generally not recommended to rely on type coercion (using '==') due to potential unexpected behaviors.
I stopped the video in each question for find the response by myself, and the tecnifiqué part i resolved the problems by myself too and then I continued with the video.
Was very interesting!
I never actually had a proper JavaScript interview, but your video demonstrates an accurate level of interview would be liked. It definitely nudged me into thinking more of a typical questions to why am I doing things in JavaScript, especially in the earlier stage of the interview questions about React, API, etc. The follow up coding interviews were very interesting. For example, if someone where to ask me about the MAP function, I should be doing ok, but coding it.... is another question.
These are extremely useful. Thanks a lot, Nader!
I'd like to suggest a video that would advice on how to get recruiters' attention, to land the interview. Seems like a real struggle.
Great video, really helpful. Just curious why you want to create methods on the prototype instead of just using plain functions. This seems dangerous as it could collide with other libs that add methods to the prototype. Seems the trend is away from OOP to functional programming. Also in JS, 'this' always refers to an object, though strict-mode may modify that behavior but not sure.
Interview and have fun together should never be mixed in the same statement 😂
I like these. Really having a good time watching and good imagining my future interview in this area
56:09 Gavin actually had the right idea which is to pass in the result array as an argument to flatten. On the other hand, the implementation you suggested needlessly creates temporary arrays.
Good point! Yes, this can be done without the new array allocations but the code looks a bit messier since you need to use it in a closure or declare a separate/global function to use. If you have the code for it, it would be really helpful for others to see this alternative way since it can definitely be more space/alloc efficient 😊
Good video and great job. Super impressive for only having coded for a couple years
The problem with this was that it's mentioned that it's a object in the docs right? That's why it was an object and we all know that everything in js is a object so when we use the String constructor and pass an object it returns the string. Let me know if you find any fault here
`this` is the string object, not the primitive since when you're doing "something".isPalindrome() it's not using the primitive (it would not have the method) -- it will use the String object, go to the prototype and consume the function if it exists. `this` in that context is the String object with all of it's methods from the prototype.
So you can call `this.toString()` to get the primitive
thanks to share this helpfull video. I think in the first code question we can just use String function (not String constructor) to convert to string and make strict check on value.
will they actually ask me the basics like what is javascript react node mongo express?
Thanks to @zia on the Discord for looking in to the mystery of the String and this Object:
Regarding this being an object but not a string literal, basically, when a function is executed, this is converted into an object if its not already.
So string literal is converted into an an object which for string hello looks like
{0: h, 1: e, 2: l, 3: l, 4: o, length: 5 }
ECMAScript calls is string exotic object (just learned btw).
TLDR: value of this keyword is always converted to an object.
Conversion of this to an object: es5.github.io/#x10.4.3
String exotic objects: 262.ecma-international.org/14.0/#sec-string-exotic-objects
😇
More simpler than that, I can just say that one is an object `String`, other is a primitive `string`. An instance of a String ""class"" is not identical to a primitive, but can be loosely equal. If you just used '==', it would work, or 'this.toString() === reversed'. A primitive is not an instance of a class, but JS automatically turns it into it with auto-boxing. That's why also "typeof String('hello')" returned primitive stringing console, it's internally "(new String('hello')).toString()". To check it in the prototype context: "typeof new String('hello')" => "object". And in the long run, that is makes confuses devs...
In the first problem we should either loosely compare "this" with reversedString (using ==) or compare this.valueOf() with reversedString
We could also use this.toString() === reversedString
Gavin should have a top job by now
Palindrome question, is the solution used in the video better than iterating the string with a single for loop matching symbols from both ends of the string and breaking on the first mismatch?
the solution utilizes functional programming which is more or less specific to prototyping in js. so from the aspect of using a prototype, yes it's
better
Single loop like that should be much more efficient and doesn't allocate unnecessary memory so it is better (more performant). Some could argue that 'functional' solution is more readable, but I'm not so sure about that as imperative one literally spells out how we think about palindromes and I think would read just as fast.
thanks a lot Nader
I would love to have an interview with you Nader
great review friends, if possible take me to work)
This was too good ! (no pun intended)
thank you for these videos
Thanks for the video😁
I think it is not a good idea to use String.prototype.isPalindrome and Array.prototype.myMap it will cause a lot of problems which is why you will never see someone using them in an interview or in a project. instead just use a normal function like: function isPalindrome, function myMap, etc
Can the palindrome task be solved in this way? Would appreciate your feedback :)
String.prototype.isPalindrome = function (str) {
if (str.split("").reverse().join("").toLowerCase() === str.toLowerCase()) {
return true;
} else return false;
};
console.log(String.prototype.isPalindrome("racecar"));
Yes just not as readable in some opinions but you could also get rid of the else since you return out of the if statement and even remove the brackets. However you will have to use this unless you want to call it as String.prototype.isPalindrome(myString) vs using this and calling myString.isPalindrome(). One addition note is your version also requires a check to ensure it is a string being passed in. With the "this" version it will implicitly be type string since method only accessible through String prototype chain unless you did something like String.prototype.isPalindrome.call(myArray) which would also break the "this" option but would almost have to be intentional miss use
// Replace "this" with str and add back to function signature for your version.
String.prototype.isPalindrome = function () {
str = this.toLowerCase()
if (str.split("").reverse().join("") === str) return true;
return false;
};
console.log(myString.isPalindrome())
// Your version.
String.prototype.isPalindrome = function (str) {
if (typeOf(str) !== "string") throw new Error(''Argument must be a string");
str = str.toLowerCase()
if (str.split("").reverse().join("") === str) return true;
return false;
};
console.log(String.prototype.isPalindrome(myString))
Also thank you for pointing this out I forgot to .toLowerCase in the video.
They only need to do:
String.prototype.isPalindrome = function () {
return this.split("").reverse().join("").toLowerCase() === this.toLowerCase()
};
console.log("racecar".prototype.isPalindrome());
Make more please
cool video)
Nice
Are you sure this is for a junior position? I think it might be more suitable for a junior position at a FANG corporation. Given the salary range of 60k to 100k, these types of exercises would likely be appropriate for a mid-level software engineer.
agree, I don't think this is junior lvl
he did mention junior/intermediate so id say a, this is more for a junior(with a year + under the belt) minimum/intermediate.
I'm 1.5 month into learning programming from zero and solved most of the problems in video. I doubt this is mid level.
I think it's unnecessarily confusing for a Junior Level interview to use the String.prototype.isPalidrome. Just let the guy focus on the main goal of the question which is to check for a palindrome with a simple function. :)
I came here to hear the English language from the point of view of a non English speaker
DSA is a BS way of determining employee value. But here. Anyone over 40 usually does poorly with these because we didn't have classes to learn, we taught ourselves. Now we are senior systems designers and we find solving these stupid puzzles ridiculous. Proves next to nothing. We hired someone who smoked all the DSA, on the job they were absolute trash. Couldn't even commit things to Git, had no idea about TypeScript, had no idea about the value of cohesive patterns. Just hot garbage hire, 9 months later, they left. DSA is a red herring at best. Libraries solve most of these, like Lodash, and if not, use AI to generate a starting point and optimize it.
These are solved here for reference. I wrote these, but only because of interviewing. Interviewing is broken. They should be asking us to build something related to the job. Not this nonsense.
O{n} version
const isPalindrome = str => {
const forward = str
const reverse = str.split('').reverse().join('')
return forward === reverse
}
The interviewer will then ask you to optimize it, which means remove the memory so O(1) version using pointers.
const isPalindromeWithPointers = str => {
let left = 0
let right = str.length - 1
for (let i = 0; i < str.length; i++) {
if (str[left] != str[right]) {
return false
} else {
left = left + 1
right = right - 1
}
}
return true
}
this seem overly convoluted for a junior mock interview. Playing around with prototypes in this manner and creating things that already exist in JS ie map, flatten etc seems really odd.
they are both very very weak
const array2 = [1,2,[2,4,[7,8]],[8,9]]
Array.prototype.flatten = function(depth=1){
let result = []
for(let i=0;i0){
result.push(...this[i].flattern(depth-1))
}else{
result.push(this[i])
}
}
return result;
}
console.log(array2.flatten(2))
Array.prototype.myMap = function(cb){
let ownArray = [];
for(let i=0;ivalue*2)
console.log(newArray)
Array.prototype.myFilter = function(cb){
let ownArray = [];
for(let i=0;ival%2==0);
console.log(filtered)
String.prototype.isPalindrome = function() {
return Object.values(this).join("") === this.split("").reverse().join("") ? true : false;
}
String.prototype.isPalindrome = function () {
if (this.split('').reverse().join('') === this.slice(0)) { return true; }
return false;
};
String.prototype.isPalindrome=function(){
return this.split("").reverse().join("")===this.toString()
}