Even with a quality JD, it can be tricky to find the best fit and evaluate the skills of your applicants when you hire front end developers. To assist you, we have created a pool of questions that good front end developers need to be comfortable with. We have compiled questions across frameworks such as Angular, React and Vue. You can check out some more questions on this page, too.
Note that the ability to answer these questions doesn't imply that you have a top quality candidate. But it definitely is a big step in that direction.
We have categorized the questions into three parts to help you navigate easily:
A. Basic concepts: Includes all basic concepts used across languages. This will give you an understanding of how strong their programming foundation is.
B. Advanced concepts: Includes all concepts that someone with higher expertise should know.
C. DS/Algorithm questions: To test the logical capability of the candidate.
A. Basic concepts
What were the major changes brought about in ES6?
Let us first discuss ECMAScript. ECMAScript is a Javascript standard, designed by ECMA international. It is designed to ensure interoperability across different web browsers. It is commonly used for client side scripting, but has also become popular in server side due to its use in Node.js.
The sixth edition of ECMA Script was introduced in June 2015 called ES6. It was later renamed to ES2015. ECMA has made multiple releases and still continues to make new ones, with the latest one being ES2020 (11th edition). But the reason ES6 is popular is because it brought quite a few major changes. We shall highlight some of the key ones which are required to be known:
1) Introduction of Let and Const:
Var is a highly infamous variable used in javascript extensively. It suffers from the lack of restriction on scope of the variable. That is, if a var is defined inside a block, its scope might extend beyond it also. For example:
var variable = 0
if (true) {
var variable = 100
}
{
{
var variable = 1000
}
}
console.log(variable)
The output is 1000, whereas it should be 0 as the console.log lies in the same block as var variable = 0.
To put such restrictions on var, let and const were introduced. Let functions similar to var but with much better restrictions on scoping. Here is the same example with let being used in place of var:
let variable = 0
if (true) {
let variable = 100
}
{
{
let variable = 1000
}
}
console.log(variable)
Here the output is 0, as expected.
Const variables are immutable variables. This means that the value of that variable cannot be changed, similar to the “final” keyword in Java. Const also functions similar to let, in terms of the variable scope. However, objects defined as const can alter their object values and keys, but cannot be reassigned.
This is allowed
const obj = {
name: "Flexiple",
city: "Bengaluru"
}
obj.name = "Flexiple"
console.log(obj)
giving an output as : { name: 'Flexiple', city: ‘Bengaluru’ }
Whereas, this is not allowed:
const obj = {
name: "Flexiple",
city: "Bengaluru"
}
obj = {
company: "Flexiple"
}
console.log(obj)
This throws the following error: “TypeError: Assignment to constant variable"
2) Arrow Functions
Arrow made the syntax for function definitions and return statements shorter. It can be considered similar to lambda functions in Java.
Before ES6 function definition looked like this:
func = function() {
return "end"
}
With arrow functions they can be shortened to:
func = () => {
return "end"
}
And if there is a only a return statement, it can be shortened to:
func = () => "end"
The way “this” works also differs in arrow functions and regular functions.
In arrow functions, “this” always represents the object that defined it. Whereas, in a regular function, “this” represents the function that called it.
3. Template Strings
Prior to ES6 you would have had to add variables to strings in this manner:
var url = "http://localhost:3000/id:"+id
Now, using backticks templating can be done like this:
var url = `http://localhost:3000/id:${id}`
Basically, use backticks to declare a string and inside it use a dollar sign along with curly brackets to insert a variable.
4) Default Parameters
There wasn’t a way to declare parameters in a function as default - it would take the default value as 0. Workarounds popularly used, looked like this:
func = function(param1, param2) {
param1 = param1 || 20
param2 = param2 || true
}
With ES6, we can set default parameters in the following way:
func = function(param1 = 20, param2 = true) {
}
5) Destructuring
This makes assigning variable values a lot faster. Before ES6, it would have looked like this:
var req = {
body: {
username: "flexiple",
email: "[email protected]"
}
}
var username = req.body.username
var email = req.body.email
After ES6, it can be shortened to:
var req = {
body: {
username: "flexiple",
email: "[email protected]"
}
}
var { username, email } = req.body
What is the popular open standard file format (like XML) used with javascript and node.js? And what are the popular commands to convert string to that and vice versa?
It is JSON which stands for Javascript Object Notation. It is a lightweight data interchange format. It is easy for humans to read. Even though it has Javascript in its full form, it is language independent.
It’s built on 2 structures:
- Collection of key-value pairs. This is called an object, dictionary, hashmap, associative array, in different languages
- Ordered list of values, This is called an array, list, vector, in different languages
These are universal data structures which is important for a file format which is language independent.
Example of JSON:
{
"flexiple": {
"top": "1%",
"location": "remote"
},
"blog": {
"topic": "engineering",
"title": "What are stable coins and how do they work?"
}
}
This in XML would look like this:
<root>
<blog>
<title>What are stable coins and how do they work?</title>
<topic>engineering</topic>
</blog>
<flexiple>
<location>"remote"</location>
<top>1%</top>
</flexiple>
</root>
Valid JSON
Few of the rules to remember while handling JSON are that:
- Empty objects and arrays are okay
- Strings can contain any unicode character, this includes object properties
- null is a valid JSON value on its own
- All object properties should always be double quoted
- Object property values must be one of the following: String, Number, Boolean, Object, Array, null
- Number values must be in decimal format, no octal or hex representations
- Trailing commas on arrays are not allowed
These are all examples of valid JSON: -
{"name":"John Doe","age":32,"title":"Vice President of JavaScript"}
["one", "two", "three"]
// nesting valid values is okay
{"names": ["John Doe", "Jane Doe"] }
[ { "name": "John Doe"}, {"name": "Jane Doe"} ]
{} // empty hash
[] // empty list
null
{ "key": "\uFDD0" } // unicode escape codes
These are all examples of bad JSON formatting:-
{ name: "John Doe", 'age': 32 } // name and age should be in double quotes
[32, 64, 128, 0xFFF] // hex numbers are not allowed
{ "name": "John Doe", "age": undefined } // undefined is an invalid value
// functions and dates are not allowed
{ "name": "John Doe",
"birthday": new Date('Fri, 26 Jan 2019 07:13:10 GMT'),
"getName": function() {
return this.name;
}
}
Javascript provides 2 methods to encode data structures to JSON and to convert JSON to objects or arrays. These methods are JSON.stringify() and JSON.parse().
JSON.stringify()
It takes a Javascript object or array as input and returns a serialised string form of it.
const obj = {
name: "Flexiple",
city: "Bengaluru"
}
const jsonStr = JSON.stringify(obj)
console.log(jsonStr)
// output is {"name":"Flexiple","city":"Bengaluru"}
JSON.stringify() can take 3 arguments in total, the first one being the data structure.
The second argument, called the replacer parameter, can either be a function or an array. It is used to manipulate the properties (keys and values) in JSON.
let cost = {
candy: 5,
bread: 20,
cheese: 100,
milk: 15
}
let func = (key, value) => {
if (value < 15) {
return undefined
}
return value
}
let arr = ['candy', 'bread']
let jsonStrWithFunc = JSON.stringify(cost, func)
console.log(jsonStrWithFunc)
// Output is {"bread":20,"cheese":100,"milk":15}
let jsonStrWithArr = JSON.stringify(cost, arr)
console.log(jsonStrWithArr)
// Output is {"candy":5,"bread":20}
The third argument, called the space parameter, takes in either a number or a string. It is used to control the spacing of the final string by deciding the size of indentation.
let cost = {
candy: 5,
bread: 20,
cheese: 100,
milk: 15
}
let jsonStrWithNum = JSON.stringify(cost, null, 2)
console.log(jsonStrWithNum)
// Output is
// {
// "candy": 5,
// "bread": 20,
// "cheese": 100,
// "milk": 15
// }
let jsonStrWithStr = JSON.stringify(cost, null, 'xx')
console.log(jsonStrWithStr)
// Output is
// {
// xx"candy": 5,
// xx"bread": 20,
// xx"cheese": 100,
// xx"milk": 15
// }
JSON.stringify() is also popularly used for debugging, as trying to see a JSON object using console.log() isn’t always successful
const obj = {
"nest1": {
"ex": "ex",
"nest2": {
"nest3": {
"ex": "ex",
}
}
}
}
console.log(obj)
// Output is { nest1: { ex: 'ex', nest2: { nest3: [Object] } } }
As we can see that after a certain level of nesting the log just displays ‘[Object]’. Therefore, JSON.stringify() can be used to make debugging easier.
const obj = {
"nest1": {
"ex": "ex",
"nest2": {
"nest3": {
"ex": "ex",
}
}
}
}
console.log(JSON.stringify(obj,null,2))
// Output is
// {
// "nest1": {
// "ex": "ex",
// "nest2": {
// "nest3": {
// "ex": "ex"
// }
// }
// }
// }
JSON.parse()
It takes a JSON string and converts it into its respective data structure
const jsonStr = '{"name":"Flexiple","city":"Bengaluru"}'
const obj = JSON.parse(jsonStr)
console.log(obj)
// output is { name: 'Flexiple', city: 'Bengaluru' }
Calling JSON.parse() on invalid JSON string will throw a SyntaxError.
Cloning Objects in Javascript
These 2 functions of JSON can be used together to clone javascript objects.
const obj = {
"prop1": {
"ex": "ex",
"prop2": {
"ex": "ex"
}
}
}
const objCopy = JSON.parse(JSON.stringify(obj))
console.log(objCopy)
// Output is { prop1: { ex: 'ex', prop2: { ex: 'ex' } } }
But this is not recommended, because of multiple reasons:
- It is slower than alternatives
- This works properly only for valid JSON, but not all javascript objects fall in that category
A better alternative for deep cloning objects would be to either use an npm library called ‘lodash’ or write a custom recursive function to do the same. The spread operator can be used for shallow cloning of objects.
B. Advanced concepts
How do you work with security vulnerabilities in npm packages?
While working with Javascript frameworks like React.js and Node.js, you will be using a lot of packages, and many packages you use come with their own dependencies. This creates a lot of scope for security vulnerabilities in your project. As many of these packages are open source, vulnerabilities are often discovered and reported to npm. Therefore, a security audit needs to be done for your project.
A security audit is an assessment of package dependencies for known security vulnerabilities. The easiest way to do this would be to run ‘npm audit’. This is automatically run every time ‘npm install package_name’ is run and it shows how many vulnerabilities that package has.
for example on installing axios, this is the output:-
+ [email protected]
added 1 package from 1 contributor, removed 1 package and audited 2154 packages in 16.811s
found 0 vulnerabilities
The ‘npm audit’ submits a description of the dependencies in your project and asks for a list of known vulnerabilities. It checks direct dependencies, devDependencies, bundledDependencies, and optionalDependencies, but does not check peerDependencies. The severity of vulnerabilities are classified into the following types: low, moderate, high and critical.
Let us take a sample project, on running ‘npm audit’, I get a long report of vulnerabilities in it. The final message of the report was this:
found 105 vulnerabilities (104 low, 1 high) in 371 scanned packages
run `npm audit fix` to fix 102 of them.
3 vulnerabilities require semver-major dependency updates.
The long report has description for each vulnerability, which looks something like this:
Low Prototype Pollution
Package lodash
Dependency of mongoose
Path mongoose > async > lodash
More info https://npmjs.com/advisories/1523
- ‘Low’ is the severity of the vulnerability.
- ‘Prototype Pollution’ is the description of the vulnerability
- ‘lodash’ is the name of the package with the vulnerability
- ‘mongoose’ is the package which you have installed, and ‘lodash’ is a dependency of it which has a vulnerability
- ‘Path’ shows the dependency chain: ‘mongoose’ uses ‘async’ which uses ‘lodash’
Many known vulnerabilities are fixed by the package maintainers in the subsequent versions of the package and therefore can be solved by updating the packages. Often times, this is what ‘npm audit fix’ does. I decided to run ‘npm audit fix’:
+ [email protected]
updated 4 packages in 24.002s
fixed 102 of 105 vulnerabilities in 371 scanned packages
1 package update for 3 vulnerabilities involved breaking changes
(use `npm audit fix --force` to install breaking changes; or refer to `npm audit` for steps to fix these manually)
Now, there are 3 vulnerabilities remaining which weren’t addressed by ‘npm audit fix’. This is because the package update involves ‘breaking changes’. In such cases, it is better to not run ‘npm audit fix --force’. What is recommended, is to run ‘npm audit’ again and do a review of the remaining vulnerabilities. Npm often gives suggested steps to fix it, which is what happened in my case:
# Run npm install [email protected] to resolve 3 vulnerabilities
SEMVER WARNING: Recommended action is a potentially breaking change
Low Prototype Pollution
Package minimist
Dependency of nodemon
Path nodemon > chokidar > fsevents > node-pre-gyp > mkdirp >
minimist
More info https://npmjs.com/advisories/1179
This single package ‘minimist’ was leading to 3 vulnerabilities, which had a ‘SEMVER WARNING’ saying that action is potentially breaking change. Above it the recommended update is given: ‘npm install [email protected]’. After running this update, you will have to check whether your project functions properly or not, and then move on to the next vulnerability. I ran ‘npm install [email protected]’ and this package did not show any more vulnerabilities. I ran ‘npm audit’ and got this:
=== npm audit security report ===
found 0 vulnerabilities
in 206 scanned packages
This was an example of how I cleaned up the known security vulnerabilities in a sample project. Similar steps can be used to fix security vulnerabilities in other npm dependent projects.
What are the vulnerabilities of using cookies? What about the usage of local storage?
Cookies and local storage are primarily used for session management in web application development. What this means is that once the user is authenticated, there needs to be a way for the application to remember the user for a period of time without asking the user to login again.
In an architecture design it is standard to keep the server stateless, but this would mean that the user information cannot be stored on the server. Therefore, the decision was taken to store it on the client. This was originally done using cookies. Cookies are basically a storage facility with the browser, which the client side javascript or the server (using headers) can interact with.
Each item stored in cookies is called a cookie, and each cookie has an expiration time which can be manually set too. The cookie persists in the browser for that duration and is not removed by page refreshes or window being shut. When a client interacts with a server using HTTP requests, then the cookies are also sent along in headers.
The data which is stored in a cookie is generally a token such as a JSON Web Token (JWT). JWT consists of a payload which is used to fetch information about the user. JWT tokens are signed on the server using a secret key. The routes allow only authorized users to check whether the token is present in the cookies. This is the outline of the architecture followed for session management.
Difference between Cookie and Local Storage
Primarily both function in similar ways - i.e. both involve persistent storage in the browser. The differences come in slight nuances of their functioning:
- Local storage does not have the concept of expiration time. So, the developer dealing with it needs to handle the expiration of tokens stored in it. Whereas, the expiration time for cookies can be set while storing the cookie and the browser handles the rest.
- Local storage is not sent with every HTTP request, like a cookie is sent. This reduces load on especially those HTTP requests which are public and do not require to use the token stored.
- The server can directly interact with cookies, whereas only the client side script can interact with local storage.
- Local storage has a much larger storage capacity of 5mb compared to 4kb of cookie. This is primarily because cookies are meant to be read by the server, whereas local storage is meant for the client side to be able to persistently store data.
Vulnerabilities
Local storage
Local storage is accessible only by client-side javascript code. This makes it particularly vulnerable to XSS attacks. XSS (Cross-Site Scripting) attacks are a type of injections in which malicious scripts are injected into otherwise trusted websites due to a vulnerability.
This script then executes on the client’s browser and can access the local storage quite easily. XSS attacks are mainly used to steal cookies, session tokens and other information. After obtaining session tokens they can access protected routes using it. Therefore, storing authentication tokens on local storage is very risky.
Cookies
Cookies function similarly as they can also be accessed by client-side javascript code. They are also vulnerable to XSS attacks, but there can be a further layer of protection added to prevent this.
If the ‘httpOnly’ flag is marked as true while setting cookies then client side javascript cannot access that cookie. This allows only the server side code to interact with it. So this protects it from XSS attacks. However, due to its property of sending a cookie on every request, it gets vulnerable to CSRF/XSRF attacks.
CSRF/XSRF (Cross-Site Request Forgery) attacks are when malicious web apps can influence the interaction between a client browser and a web server that trusts the browser. Therefore, further measures need to be taken like using CSRF tokens and proper use of the Same-Site cookie attribute.
C. Data Structure/ Algorithm
1. Write a program to find whether a string or number is palindrome or not.
function palindrome(myString){
var removeChar = myString.replace(/[^A-Z0-9]/ig, "").toLowerCase();
var checkPalindrome = removeChar.split('').reverse().join('');
if(removeChar === checkPalindrome){
document.write("<div>"+ myString + " is a Palindrome<div>");
}else{
document.write("<div>" + myString + " is not a Palindrome <div>");
}
}
palindrome('"Madam"')
palindrome('"Star Wars"')
palindrome('"7,10,7,8,9"')
The output of the above code will be:
"Madam" is a Palindrome
"Star Wars" is not a Palindrome.
"7,10,7,8,9" is not a Palindrome.
2. What will the output of the following code be?
var p = 2;
var q = 4;
var r = 6;
if (p > q > r)
document.write("true");
else
document.write("false");
The answer is False. It may look like the output can be true because 6 > 4 > 2 is true, but PHP evaluates $z > $y
first, which returns a boolean value of 1 or true. This value (true or 1) is compared to the
next integer in the chain, bool(1) > $z, which will result in NULL and echo “false.”
.png)
