I recently graduated from Flatiron’s Full Stack Software Engineering Bootcamp and one aspect of Flatiron I’ve really appreciated is the support they provide post-graduation. I have a career coach who has helped me revamp my resume, linkedIn, done multiple practice cultural and behavioural interviews and has been a guide when talking with recruiters. As part of preparation for the job search Flatiron provides a token to SKILLED which is a company that pairs you with an experienced engineer and they give you a mock technical interview in the language that you choose. I chose React since that was what my most recent module at Flatiron covered and I’m most fresh in my technical knowledge.
I did a little bit of googling and talked with some of my classmates to get an idea of what the mock interview is like and read two articles SKILLED Technical Interview and Mock Technical Interview with SKILLED: what to expect.
My classmates encountered a large variety of situations. One classmate's biggest challenge was solving the Interview Cake Inflight-Entertainment algo. One had to turn a string into an object that counted the number of times a letter appeared in the string, then build a React component with a button that increased the counter, then they had to have that count display the fizz-buzz algo, and then determine how to make the function multiply(5)(6) return 30 using nested functions. Another started with a 15 minute cultural and technical understanding of React, then they built a component with an input that displayed it twice, followed by making a Higher Order Component, and then they asked their interviewer for a mini-lesson on hooks.
I did a little studying of my technical knowledge by reviewing my notes from school and practicing setting up a counter, but it turned out my everyday coding and practicing was the best prep! My interview was a little different from the blogs I’d read about and my classmates’ experiences. I want to share what my interview was like with the biggest emphasis being; be prepared, but really, you don’t know what your interviewer will be testing you on!
The interview started with about 15 minutes of verbal questions followed by 40 minutes of live coding and a few minutes for me to ask questions.
Part 1. Verbal Questions:
- What is the virtual DOM?
- What is the component Lifecycle?
- What are the main differences between a class and functional component?
- What is the difference between props and state?
- What are keys in React?
- What is jsx?
- What is a fragment?
- What is the CSS box model?
After I answered the questions we moved on to the live code.
Part 2. Live code in the SKILLED text editor.
A few notes about the code editor, it has minimal syntax highlighting and almost no auto-fill. So if you’re used to your VSC editor going ‘rcc tab’ and it builds out the boilerplate for a class component, you will need to recall how to build all of that manually. Also there was no output or visible browser associated with my code, so I had to rely on my knowledge to know if the code I wrote would produce the outcome I was expecting. I was also not allowed to use google and according to my interviewer this was to more accurately reflect what a real interview might be like. Because of this I learned that I’m very reliant on MDN using fetch to recall the fetch syntax, and when it came to using the useEffect hook I couldn’t remember the exact syntax either. My interviewer was very gracious and they helped when I needed it. I was honest and upfront when I blanked and they would type in the curly brackets and parentheses I was missing and I would keep on moving, in this way we maintained a good pace during the live code.
They would give me verbal instructions on what to do and also leave commented out notes in the code to help prompt me visually. We started with ‘Build a react class component called hello that returns an h1 of “Hello”.
//Build a react class component called Hello
//that returns an h1 with "Hello"
import React, { Component } from 'react'
export default class Hello extends Component {
render() {
return(
<div>
<h1>Hello</h1>
</div>
)
}
}
Then I was asked to build a constructor that could accept props and set an initial state of helloTranslations set to an empty array. I’m used to setting state directly using state ={ helloTranslations: [] } and I told them as much and so they helped remind me of the need to use super.
// make a constructor, assume it accepts props
//with state helloTranslations set to an empty array
import React, { Component } from 'react'
export default class Hello extends Component {
constructor(props) {
super(props);
this.state = {
helloTranslations: []
};
}
render() {
return(
<div>
<h1>Hello</h1>
</div>
)
}
}
Next they had me imagine that this component has access to a fake endpoint of an api that is being sent down as props. I can access it by this.props.helloTranslations = ‘https://hello/translations’ without ever writing out the url. They asked me what kind of function I would set this up in, and my response was componentDidMount(). They followed up with let's write a fetch to that endpoint that returns the data.
// assume you have an endpoint of this.props.helloTranslations = 'https://hello/translations'
// What kind of function would you set this up in?
// componentDidMount()
// make a fetch to that endpoint
import React, { Component } from 'react'
export default class Hello extends Component {
constructor(props) {
super(props);
this.state = {
helloTranslations: []
}
}
componentDidMount() {
fetch(this.props.helloTranslations)
//I did not remember the exact syntax for fetch, asked to use MDN, he said let's not since I most likely won't be able to in an interview setting
//he mentioned the first arg is the endpoint you want to hit, optional second arg of {} with all your headers such as 'POST' etc
.then(response => response.json())
.then(data => console.log(data));
}
render() {
return(
<div>
<h1>Hello</h1>
</div>
)
}
}
Once my fetch was set up they inform me that the data returns an array of words that include ‘Hello’. Use that array to set your state but don’t include the word ‘Hello’. I mused aloud that this would be a good case for filtering, and when they nodded and went ahead and built that.
//that data returns an array data.translations = ['Hola', 'Bonjour', 'Hello', etc.]
// access that array and set your state of helloTranslations equal to that array
//but exclude 'Hello'
import React, { Component } from 'react'
export default class Hello extends Component {
constructor(props) {
super(props);
this.state = {
helloTranslations: []
}
}
componentDidMount() {
fetch(this.props.helloTranslations)
.then(response => response.json())
.then(data => {
let newArray = data.translations.filter(trans => trans !== 'Hello')
this.setState({helloTranslations: newArray})
})
}
render() {
return(
<div>
<h1>Hello</h1>
</div>
)
}
}
Now let’s iterate through the data in your state and make each translation a button inside an li. I verbalised my thought process of building a ul to hold the li and then calling a function that would render the translations. Inside that function I mapped through all the data to display them. When I got to setting the key I told them I would assume that each translation is unique and use that as the key. They asked me why I didn’t use the index and I pointed out that arrays are mutable and if it was rearranged or an item inserted or deleted the index might change and keys should be stable for react to be able to make changes efficiently. They agreed with this answer and we moved on to the next item of business.
//display that data: <li><button>Hola</button></li>
import React, { Component } from 'react'
export default class Hello extends Component {
constructor(props) {
super(props);
this.state = {
helloTranslations: []
}
}
componentDidMount() {
fetch(this.props.helloTranslations)
.then(response => response.json())
.then(data => {
let newArray = data.translations.filter(trans => trans !== 'Hello')
this.setState({helloTranslations: newArray})
})
}
renderTranslations = () => {
return this.state.helloTranslations.map( trans =>
<li key={ trans }><button>{ trans }</button></li>
)
}
render() {
return(
<div>
<h1>Hello</h1>
<ul>
{ this.renderTranslations() }
</ul>
</div>
)
}
}
Next they had me write a function that when the button is clicked, it console.logs the translation. I had to repeat the instructions back since I was confused that the translation was already on the page and they confirmed that they wanted the same data logged.
//write a function that when a button is clicked it console.logs that translation
import React, { Component } from 'react'
export default class Hello extends Component {
constructor(props) {
super(props);
this.state = {
helloTranslations: []
}
}
componentDidMount() {
fetch(this.props.helloTranslations)
.then(response => response.json())
.then(data => {
let newArray = data.translations.filter(trans => trans !== 'Hello')
this.setState({helloTranslations: newArray})
})
}
logTranslation = (translation) => {
console.log(translation)
}
renderTranslations = () => {
return this.state.helloTranslations.map( trans =>
<li key={ trans }><button onClick={ () => this.logTranslation(trans) }>{ trans }</button></li>
)
}
render() {
return(
<div>
<h1>Hello</h1>
<ul>
{ this.renderTranslations() }
</ul>
</div>
)
}
}
At this point they confirmed that everything looked correct to them and next they wanted me to rewrite the entire component as a functional component. Lucky for me I had practiced using hooks last week. I broke it down and built each piece in the same order that we built the class component. They taught me some tricks along the way such as destructuring the props of helloTranslations when it comes into the component, and remembering that useEffect takes in two arguments, the first being a function and the work you want done, and the second is the empty array so that useEffect only runs once.
//take this component and rewrite it as a functional component
//you can either write over it directly or write a new component
import React, { useState, useEffect } from 'react'
const Hello = ({ helloTranslations }) => {
const [translations, setTranslations] = useState([])
useEffect(() => {
fetch(helloTranslations)
.then(response => response.json())
.then(data => {
let newArray = data.translations.filter( trans => trans !== 'Hello')
setTranslations(newArray)
})
}, [])
const logTranslation = (translation) => {
console.log(translation)
}
const renderTranslations = () => {
return translations.map( trans => <li key={ trans }><button onClick={ () => logTranslation(trans)}>{ trans} </button></li>)
}
return(
<>
<h1>Hello</h1>
<ul>
{ renderTranslations() }
</ul>
</>
)
}
export default Hello
At this point we talked a bit about arrow functions and they asked me how they are different from regular functions, the key difference being that it does not have its own ‘this’ and therefore it inherits this from the parent which in this case would be the class itself. In the context of renderTranslations that allows me to call translations directly because they are in the same scope.
What is a state management tool you can use and why might you use it? I told them I was familiar with redux and you might use it in a very large app or apps where you are finding you need to pass state down as props to grandchildren or great-grandchildren. Redux allows for components to directly access state so you can avoid prop-drilling. When then discussed briefly the merits of React context and using that instead of Redux.
They then asked: What is a ref? Followed by: What is the difference between a client-side and a server-side react app?
I had heard of a ref but couldn’t recall what it referred to and I had only ever heard of React as a client side app. I was straight up honest and then we had an interesting discussion where they taught me about client-side vs server-side apps. They weren’t surprised I didn’t know this information since they have noticed many bootcamp grads don’t have knowledge of what they call Advanced React Topics.
And that was it! For me my biggest takeaways were needing to brush up on some syntax, practice more with hooks, and start delving into more advanced topics for React. Overall it was a very positive experience for me. It also gave me a confident boost that I really do know my React concepts and can code successfully in an interview setting. To recap I had verbal questions about the theoretical knowledge of React and built a class and a functional component that both used state and made an asynchronous fetch request. With SKILLED there are lots of different possibilities of what you might be asked to do, just like with a real interview! So go prepared, but know that what you prepped might not be what your particular interviewer expects of you.
Happy coding!
Oldest comments (0)