Forem: keith hayden

Adventures in Fronted Interviewing - The Take Home

keith hayden — Thu, 11 Nov 2021 03:44:27 +0000

During my recent job search, I was exposed to how different companies run their interviews. Two of the companies I interviewed with asked me to complete a takehome challenge as opposed to doing a live codescreen. The idea is to give you more time and flexibility to do it on your own schedule. This also means that instead of a 30-45 minute window to complete one or several code tasks live, you have a few days, maybe a week, to complete a broader set of tasks that would involve more complexity.

A little more about me

For both takehomes, I had to learn tech that I was not familiar with instead of having the choice to use what I know. I consider myself to be very good at taking mockups from designers and specs from product managers and creating a responsive interface. Making me do it "their way" adds complexity and doesn't really showcase my skills and experience.

It should only take a couple hours

For the first of the take homes, I was assured that "It should only take a couple hours". It ended up taking me a few hours a night for a few weeknights after work, and then about 6 hours on a Sunday to wrap it up.

They sent a zip file that contained a README, a mockup of a data card, and two json files. The README contained a list of requirements like:

bootstrap a new NextJS app using create-next-app
Add TailwindCSS as a dependency
Create two api endpoints that return the data in the json files
update index to fetch the data from endpoints
create a "loading" component to display while data is fetching
create a card component to display the data for each item
Use Flexbox to render cards in a grid with media queries for breakpoints listed

They didn't go into detail about how much of tailwind I was expected to use. I'd never used it before and when I started researching it, I was kind of horrified to see how it worked. Creating utility classes isn't itself a bad thing, but basing your entire layout on littering your markup with classnames seems like madness to me. At the very least I included the tailwind base, components and utilities in my global css file. But ultimately I ended up just rolling my own CSS because I was more concerned with getting it done than with getting it done "with tailwind". I'm very much a CSS geek and I love experimenting. I can learn any framework on the job so I wasn't enthused that it was a requirement.

For creating the project with NextJS, I'm lucky because I've done that before. My personal site is a NextJS site and I had already been through the learning process for that. NextJS was actually relevant here because it was in the job description and we did discuss it on the initial interview.

The requirement to use flexbox for the grid didn't feel right. During our call I spoke about how I loved CSS grid and was immediately told, "we can't use that because we still have a lot of users on Internet Explorer". I understand the sentiment behind that, but it's a bit uninformed and forces me into a box instead of allowing me to show how I would solve it. Who knows, maybe they'd learn something from me. But I digress. I'd never used flexbox to do grids in this way so that was another thing I'd have to experiment with. My use of flexbox usually involved a container element aligning children in a row or a column but not as a grid. I also haven't had much cause to use properties like grow/shrink.

For the API endpoints, Next makes it real easy and all I had to do was read in and return the contents of the json files. The data consisted of 34 items in one array, let's call them "teams" and 400 in another, let's call them, "players". Each player had several properties, including an id that cross-referenced the teams data set. However, the documented schema said this id would be an integer, but it turned out to be a three-letter string. The fact that I figured that out after their mistake should be a point in my favor.

I setup two variables using the useState hook to hold the data from each and async/await to fetch them from the API. I used useEffect to make those API calls only after the component had mounted (like componentDidMount would do in a class component). Then I did something like this in the component's return:

<main className={styles["page-content"]}>
    {playerData.length > 0 && teamData.length > 0 ? (
        <PlayerList players={playerData} teams={teamData} />
    ) : (
        <Loading />
    )}
</main>

Then I spent quite a bit of time obsessing over layout of each card and the overall page. I started out just using 20 items to get the layout details ironed out, then started having it load 50, 100, then all the data.

There were two more problems with the data that I discovered at runtime. The first was a handful of players had null values for some stats, so I had to account for that in the code. Each player also had a full static url to a thumbnail image but one of them was throwing a 404 and blowing up the layout. I made some adjustments to the css to cover that scenario as well. In my mind, finding and fixing bugs in the data or the layout is exactly what happens on the job. I called these things out in the README.

As a way to help me stand out a bit, I decided to use CSS custom properties for the colors and added support for dark mode using the prefers-color-scheme media query. I also used the prefers-reduced-motion media query to control the loading animation. The loading animation would spin slowly if prefers-reduced-motion: reduce but bounce otherwise. I felt like this showed that I thought about things outside the scope of what is asked.

So after all that, I pushed to my own repo and sent them the link. Then I waited...

It took them almost a week before I even heard from them to say they were going to look at it. Then it took another week to hear back from the recruiter with the rejection. I had to ask this 3rd party recruiter about feedback, and he had none, so I asked if he could ask them on my behalf. I had the hiring manager's email, but wasn't sure if I should email him directly.

Did I misunderstand something in the instructions

Did I not do something they were expecting?

Did I do something they didn't agree with?

After yet another week, I finally got something that barely qualifies as feedback. I was still just as perplexed as before.

In terms of the code challenge itself, they mentioned that there's a specific layout that they look for in terms of how far you can break the code down. Since I'm not an Engineer, my interpretation of that is there could've been areas where the code wasn't as complex or in depth that they'd like. For example, didn't take it to its limits as much as it could've.

It was hard for them to break it down into more simple feedback; the best way he phrased it was just that the layout and format didn't match what they hoped for.

As the interviewing company, they should be upfront and clear about their expectations, not cryptic and just see if someone does it how they like. Every candidate is different and has different experiences, but we're all pretty adaptable to change if we know what is expected. The lack of clear expectations and lack of feedback afterwards tells me that I don't want to work there.

Takehome Challenge: The Sequel?

For the second takehome, I was invited to fork a private repo on github and create a branch. To submit it, I was supposed to create a PR against master branch in my fork. It was an already existing React app that I just had to run locally, and make updates.

There were required tasks and extra tasks.

The tasks were as follows:

Required

implement the layouts for mobile/desktop according to mockups using Styled Components
create a scrollable component that shows 3 videos at once
Sort the videos alphabetically
This is not a design challenge, but use your best judgement to make the site look nice using Styled Components
make selected video autoplay when thumbnail is selected
(senior required) use redux for global state
(senior required) write tests

Extra

implement lazy loading
use typescript
deep linking using React Router
write your own express server

Just like I had never used Tailwind, I had also never used Styled components or Redux. The project I worked on up to this point used MobX for state management. I did some quick recon on Redux so that I could set that up and know how to use it, but Styled Components drove me a little nuts. As a longtime CSS and SASS geek, I got a little frustrated with learning a new way to do CSS.

But here's what I did:

implemented layouts for mobile and desktop using Styled Components
loaded video thumbs in scrollable component
sorted alphabetically
made it "look nice"
had issues with autoplay because of browser restrictions
used redux adding data to the store
added deep-linking with React Router
added some tests using React Testing Library
attempted to add typescript but the existing app had dependency issues and I opted to leave that in a branch and made note of it in the PR
I added lazyloading to thumbnails using loading=lazy
added prettier and eslint (wasn't required, I just like it)

I submitted the PR, sent an email and waited a week to be told "the team is passing on your candidacy". No more details, no followup to review my code or ask questions, no feedback about what I did wrong or what I did right (which is just as important). Just ghosted...

Conclusion: I didn't enjoy the takehome experience

The idea of a takehome should be to give the candidate more time to do the task at their own speed. Having requirements to do things a certain way just adds complexity and doesn't consider that not all candidates have used everything in your tech stack. Let them complete the challenge the way they want and then have a followup discussion. Not everyone who is good at Typescript and CSS-in-JS can figure out an npm module dependency issue or webpack config.

Making someone use unfamiliar tools or mess with dependencies feels like you're expecting too much time and effort from a candidate who has no guarantees of moving forward.

Neither of these companies had followup calls with me to discuss it. To me, that's a failure in their process. If I gave someone a takehome I'd want to review it with them afterwards because it would reveal a lot about their thought process, how they handle challenges.

While not all codescreen interviews were great either, I'd have to say these two experiences have soured me on takehome challenges.

Allow Myself to Introduce... Myself

keith hayden — Tue, 22 Jun 2021 14:20:15 +0000

whoami?

My name is Keith, and I've been working on the web for over 20 years. I'm currently a Senior Frontend Engineer but I've held a few different titles and worked in a lot of different tech stacks over that time.

why?

Just a bit of context about me. If you see me on social media, and want to know more, I'll likely point you here.

what?

I learned about the web while at college in the 90s. I even was a student employee working on the school's website for one summer. I got my first post-college tech job working for a small tech company in NJ, providing customers with various web services. We helped them buy their domains, designed their sites, setup their email. After getting laid off during the dotcom bubble, I landed at another tech company in NJ working on in-house web apps in a LAMP stack environment. I was architecting MySQL databases, writing perl and bash scripts for cron jobs, modifying apache configs, and oh yeah, getting the PHP backend to play nice with the frontend.

In 2005 I landed in Westchester County, NY working for Ask.com/IAC. Majority of my time was spent working on javascript apps that integrated with IE toolbars (yes, those things, I am sorry). Also had the chance to work on Flash/Actionscript/Flex apps like a virtual world, e-cards, smiley creator. Had some exposure to Java using JSP and JSTL but just enough to get the backend to do what I needed on the frontend.

In 2011 I headed south to New York City, first working for a lifestyle/marketing company on partnership microsites that we churned out on a somewhat weekly basis. My first responsive work, as well as Sass and a lot of CSS experimentation on a LAMP stack backend. That only lasted a year because there was some not so great chaotic and shady things going on there.

I then landed at iHeartRadio on the digital team. I wasn't working on the streaming web site, but on a platform that hosted about 800+ radio station web sites. This platform got re-architected about 4 or 5 times during my 9 years there. From really old PHP to a custom MVC PHP framework, then we merged the separate mobile and desktop sites into one responsive site which is where my frontend experience really came in handy. Eventually that frontend was migrated to a python app powering the backend. Our frontend was a hodgepodge of jQuery, Bootstrap, and vanilla JS with bootstrap grid and whole mess of plugins. After I pushed for us to upgrade and modernize our tech stack, we re-architected that into a React frontend with typescript and then eventually ditched the python backend for full-stack nodejs.

Since 2017, I've been working in the React/Typescript tech stack. I established myself as the go-to resource for much of the UI work. I worked closely with Product Managers and UX designers to implement their visions.

In June of 2021 I said farewell to iHeart and "Hello" to Squarespace. I'm now primarily working on React, with and without typescript, in a large codebase with an in-house component library. It's a different world, and I'm learning new ways to solve problems and excited to see where this takes me.

anything else?

I'm a big hockey fan (NJ Devils) and I am quite the geek. I grew up on Saturday morning cartoons, Schoolhouse Rock, Atari, Star Wars, and sci-fi/fantasy of the 80s.

I'm known to spout puns and pop culture references and you might find me bopping to some 80s one-hit wonder or 90s grunge, among others.

I like craft beers and experimenting with my Weber Kettle grill/smoker.

I guess that's good enough for now. Say hello in the comments or on twitter.

What's up with flex-direction?

keith hayden — Sun, 14 Mar 2021 18:37:06 +0000

Does flex-direction sometimes trip you up?
Does it make you ask, "Which way did he go George?"

I came across a conversation on twitter a few weeks back. (sorry I can't find the link) where someone expressed some confusion over flex-direction. Some of the replies were chastising them over it which I think was unfair. Later I saw another post by Jen Simmons that asked people what confused them about flexbox and some of the replies mentioned flex-direction.

This made me think about knowledge and about things we take for granted as "known". The spec defines flex-direction as

The flex-direction property specifies how flex items are placed in the flex container, by setting the direction of the flex container’s main axis. This determines the direction in which flex items are laid out.

I'm not advocating for changing the spec or anything. I'm just acknowledging that sometimes things aren't as simple as we think they are. And when we realize that, we can stop judging others for getting confused.

How it's defined in the spec doesn't always stick when people go to write their css. I know I often have to set both align-items and justify-content, only to adjust them after I see which one I need to alter. Those two properties effect the child elements differently depending on the flex-direction.

I think the main hangup people have is that "row" makes the parent a row, so all the child elements are actually in columns in that row. Conversely, "column" sets the parent to be a column and the children fall into their own rows. I think the issue here is what we see vs what we know. We see columns when we set flex-direction: row and our brains process that as contradictory.

CSS-Tricks has A Complete Guide to Flexbox and there are lots of flexbox cheat sheets and examples that you could find with a simple search.

There really is no simple way to remember it other than rows go left-to-right and columns go top-to-bottom.

Speaking of examples, here's my contribution:

Creating a CSS color palette from Sass variables

keith hayden — Sat, 13 Mar 2021 16:59:22 +0000

Does your project use a defined color palette? Maybe it comes from a design system or maybe it's just a list of random colors that you use a lot. As someone who's worked on a lot of projects, some small, some big, and some very large, I find that having a defined set of colors can help keep things organized.

Most recently I work on a platform that hosts hundreds of sites that all use the same basic palette. This palette was created by our awesome UX team as part of our design system and it includes different shades of many colors. The most often used ones being in the gray (grey) palette. Together we analyzed all the colors used in our codebase and saw how many different shades were used. UX came up with this palette and it's worked beautifully.

In engineering, we took the defined palette and created it as a sass map object like this:



$palettes: (
        red: (
                600: #c6002b,
                500: #cd212e,
                400: #e22c3a,
                300: #f4747c,
                200: #f79096,
                100: #f4adb1,
        ),
        blue: (
                600: #0055b7,
                500: #509da7,
                400: #30bac6,
                300: #68c8d5,
                200: #84dae5,
                100: #a3e2eb,
        ),
        grey: (
                600: #27292d,
                500: #3f4447,
                400: #717277,
                300: #a9afb2,
                200: #e6eaed,
                100: #f6f8f9,
        ),
);

Originally, we would use a sass function that did a deep-get into the map to find the right color by passing it the color name and number. After a review of this tactic we realized this was hard to maintain and didn't work well with our theming initiative. So we went and replaced all the function calls to use CSS custom properties. After some experimenting we found the best way to create this palette as CSS props was to loop over the map and dump the results into :root{}



:root {
    @each $colorname, $palette in $palettes {
        @each $key, $value in $palette {
            $keyname: "--palette-" + $colorname + "-" + $key;
            #{$keyname}: #{$value};
        }
    }
}

which ends up giving us this:



:root {
  --palette-red-600: #c6002b;
  --palette-red-500: #cd212e;
  --palette-red-400: #e22c3a;
  --palette-red-300: #f4747c;
  --palette-red-200: #f79096;
  --palette-red-100: #f4adb1;
  --palette-blue-600: #0055b7;
  --palette-blue-500: #509da7;
  --palette-blue-400: #30bac6;
  --palette-blue-300: #68c8d5;
  --palette-blue-200: #84dae5;
  --palette-blue-100: #a3e2eb;
  --palette-grey-600: #27292d;
  --palette-grey-500: #3f4447;
  --palette-grey-400: #717277;
  --palette-grey-300: #a9afb2;
  --palette-grey-200: #e6eaed;
  --palette-grey-100: #f6f8f9;
}

We then use them anywhere we need to using the CSS var function like this: background-color: var(--palette-grey-100);.

Here's a handy codepen to see it in action.
Thanks for stopping by.