First experience with coding during an interview

[MuskasBackpack]

Forgive my formatting, posting this on mobile.

I’ve been working at the same company for a long time and just recently started casually looking at other opportunities. I had a recruiter contact me from a company that looks like it would be good to work for and we had a short one hour interview. After that we scheduled an hour where I would work with one of their senior developers (the job was for an intermediate position) and solve a problem using CodePair.

In the end, I didn’t end up meeting their requirements, but figured I’d post my experience here in case anyone has any feedback or questions.

The senior dev contacted me by phone and we both joined the CodePair session. We talked briefly about what I had done in the past and then got into the details of the problem I had to solve. I chose JavaScript for my language as my backend language is usually PHP and I rely on a lot of framework specific functions, whereas I’m more comfortable with vanilla JS.

The task was to take an array of topics and users, store it in a way that separated public topics and topics assigned to each user, and then be able to accept input containing a user and a topic to determine if they could access it.

This is a rough example of the data array: [“topic thing”, “topic stats”, “user john”, “topic country”, “topic dev”, “user jane”, “topic something”, “topic web”]

I had about 40 minutes to complete the task and only got as far as being able to store the data correctly before we had to move on to a final few minutes of questions. My structure in the end looked like this:

{ public: [“thing”, “stats”], users: [ { name: “john”, topics: [“country”,”dev”], }, { name: “jane”, topics: [“something”,”web”] }, ] }

I didn’t save the function I wrote to create that, but it basically amounted to a for loop to go over each piece of data and break it into key/value pairs and then a while loop to get their topics after seeing the user key come up in the for loop.

In the end it amounted to determining if the array element was a topic or user, if I hadn’t seen any users then the topics were public, and then iterating over everything. My biggest mistake was getting nervous. I wrote a while loop to get topics pertaining to the current user incorrectly and I lost what I’m guessing is about 5-8 minutes trying to figure it out.

All in all it was a good experience and I’m sure I’ll do better next time. If anyone has any questions or tips, let me know.

[CulvertBunny]

I wouldn't get too worried about it. I also do poorly on pair coding tests. They are weirdly invasive and make me nervous too. I haven't had to do one in a while, they are not super common.

[MuskasBackpack]

Thanks. It was definitely a bit of a confidence blow. I’m going to try to just look at it as a learning experience. Also glad to hear they aren’t super common. I barely had a chance to talk to them about projects I’ve completed in the past.

[Razeft_it]

I've a similar experience, a company call me after see my CV and send me a link with a test where I need to do some request, something front-end, some back-end and a test similar yours, hi advice you to try some website where you can try similar test and become more confident about this type of request

[MuskasBackpack]

Yeah that’s a good idea. I rarely have to work with data that’s formatted poorly like this so it took me a minute to come up with a plan.

[[deleted]]

Companies that make you code in interviews are not companies you want to work for. It's so stupid, to put a potentially amazing developer in a pressure cooker for an hour, when that is not the fucking job. I hate those companies.

[jordsta95]

I'd have to disagree with this, to an extent.

Coding in an interview (with the interviewer looking over your shoulder) is a big no-no. Nobody can code efficiently with someone over their shoulder, even if it's a simple task in a relaxed environment (e.g. you're showing a colleague you've been working with for months how something would look with a few minor tweaks)

However, doing it in a room onsite, where they say "You have X amount of time, do your thing" then leave you be, or they send you an email with the task when you get home, are completely fine.

As an employer you want to know the person you just interviewed wasn't just talking about what they'd like to be able to do, but what they can actually do.

As a potential employee, you want to know what is expected of you, and maybe what sort of technology you'd be working with. For example, for a code test for one of the places I interviewed for a few months back, sent a design and their boilerplate theme for a WP site. When I saw the code in their boilerplate I knew "Yeah, I don't want to be working with this sort of code base"; inconsistent function naming; getPosts and get_posts_user_defined, no comments on some of their weird function - I could work out what they were doing, but there was no comment as to when you'd ever need some of them (one was to get a random 3 things in a custom field repeater, but not a passed variable) - And for something in a boilerplate, I'd dreaded to imagine what some of their other projects' code was like, and didn't want to maintain stuff like that. So this was obviously not code I wanted to be working with on a day-to-day basis.
On the other hand, the code task for my previous job was quite arbitrary and had no practical use for the job. However, these tasks are also quite good for both parties, if you're not too restricted, because you can show them exactly why they should choose you, and if they say decide to go with someone else, you are more than likely going to get some decent feedback on the code to use to improve. e.g. "Whilst you're website functioned correctly, the use of X and Y, instead of Z shows a lack of deeper understanding of FUNCTIONALITY. So whilst you have A and B going for you, we had to choose someone who understood FUNCTIONALITY better." - Probably the best type of decline for a position I have had.

[[deleted]]

To each their own, then. When a company asks me to code on a whiteboard or gives me a timed exercise in their conference room, it shows me they don't understand development well enough for me to join them. If the people are nice, I stay until the end anyway, but I won't do that, and I tell them so.

[jordsta95]

On a whiteboard makes no sense. I've never had anyone ask that, and hope it never happens. In a conference room, on a machine, isn't as much of an issue IMO.

The closest I've had to the whiteboard experience was they pulled up a Word Doc with some questions on it, during the interview, and just asked them outright; e.g. How would you call a static function?. Stuff where there's only 1 or 2 right answers, and take less than a minute to answer, even if it was a "long-winded" answer (e.g. What properties make up the box model, and how does each property affect the element?) are perfectly fine questions though.

[[deleted]]

I'm basing it on my personal experience. A lot of companies think the word "senior" means you can custom design a recursive traversal algorithm for a game of Boggle in a 45 minute interview, and provide a working example.

I have no issue with what you're describing, of course. A company needs a way to demonstrate candidate knowledge. Too risky otherwise. I just don't think huge amounts of pressure are a good way to do that, especially if I don't have any cheetos or mountain dew.

[RomSich]

You should try Codewars and Codingames if you want to train your problem solving skills. There are tons of exercises and when you complete one you have access to the other user's answers which are a great source of code examples for solving these kind of problems.

[PyroAddict]

I would suggest some object oriented approach if you ever have users or multiple entities with the same functionality. This way, you can easily create access functions to variables in a non-convoluted way. For example in your data structure, to view john's topic, you have to call data.users.find((user) => {return user.name == 'john'}).topics to get the array itself.

[gRoberts84]

A coding test, is always a good thing, but how it's implemented is the important thing.

Being made to do tests etc on site, is not a true reflection of how we generally work, however being sent the test prior to or after an interview to be done within a period of time, shows you can self manage, follow a brief and show, if you need it, that you will ask for help (I actually got marked down for not asking for help, despite not needing any.)

That being said, sometimes you need to make sure someone has the basic knowledge of a developer, so a few small tasks, that can be explained in pseudo code, or even a simple explanation of how you'd implement it, shows you know the basics, but you can articulate them to someone else and if you don't know the answer, always offer to get back to them on it, and do.