Hi all,
In a couple of days I have a technical test for a great Front End job (I already passed 2 interviews, this is the 3rd stage). They told me that the test would be 4 hours. I would have to build something and then give them a walk through.
I’ve done tech interviews before, but it was either 1) 30-45 minutes live coding tests or 2) a longer project that I had several days to complete, in my own time.
I’ve never done a long AND timed project like this one, so I’m wondering what it could be? I want to be well prepared for this, but I have no idea where to start.
During the interviews they asked about my experience with
- Javascript, jQuery, Ajax, Json, REST APIs, etc (I am familiar with this or able to find the info I need very fast with Google)
- CSS pre-processors and methodologies (I know a bit about SASS and LESS and can use them if I need to but I’m just faster writing CSS myself)
For the moment I am doing Javascript and CSS tests just to refresh my knowledge.
One year ago I applied for a similar position. I was asked to build a web app that gets data from an API (info on Spanish football players and teams) and displays it, with various filters. They gave me a couple of days for this. I am wondering if the 4-hour project would be something similar?
(By the way this is my first time posting here 
)
It really could be anything from a static website from scratch to working within a large and established code base, to designing and implementing tricky algorithms. I’ve seen all these things and more.
1 Like
Interviews for both of my last jobs had a task which was recommended at few hours (four for last one, can’t remember one before that), and then I walked through the code. First interview was standard stuff, then they gave me the task to take away, then went through the code in the second interview. For four hours, I’d expect something that is very simple but has a series of conditions that are similar to things the company does (which will complicate it). I took a fair bit longer than four hours on each one (the first one I learned Redux which took a few days).
For reference: first job, task was a betting application, was given an API endpoint that served up a blob of JSON with odds, had to do a front-end that let a user male bets and do a few other things (https://github.com/DanCouper/Bettest - code is probably awful). second job, write an implementation of FizzBuzz, with a cache and exposed on a server, allow the server to be locatable on a network so any other machines can connect to the node and make request on it (https://github.com/DanCouper/fibz - code is pretty good on that one)
Can’t really give much advice as it could be anything, but I would say document everything, and by that I mean actually write documentation in the code, with a high-level overview that you constantly update as you work in the README. This is primarily to explain to yourself what you’re doing all the time, which then translates to you being able to talk about every single thing in detail in interview. Secondarily it’s because (YMMV, but generally holds true) people tend to be unfeasibly impressed with good documentation, which I found weird at first until I actually started having to deal with other people’s code.
3 Likes
Thank you for the detailed answer
The point you made about good documentation is great, I’ll definitely do that. I’ll take a look at your projects now, they look interesting (although a bit advanced for me, I’m very new to React and currently learning it).
Was the first task for a front end, and second task for a back end position? Sounds like mostly server stuff was involved in the second one.
Yes, second one is entirely backend, in a language called Elixir. Just really as an example [of requirements], both kinda try to explain what they are.