Lessons learned from a failed interview

A little background

A few years ago, I worked in the fulfillment center for a startup. Our day-to-day primary consisted of:

• Count the morning vehicle inventory
• Add/Shift around inventory between cars
• Verify the drivers had their checkout tools
• Receive new inventory
• Check for any new order changes throughout the day
• Count the evening vehicle inventory

There were also special projects, but that was the gist of the job. It was something that I had always wanted to try out, but as you can see, it was quite repetitive. However, because humans are gonna human, we consistently made simple mistakes but often weren’t aware that we were making mistakes until it was too late. One of which were non-sellable items.

The Problem

Say a driver went to make a delivery and somewhere after the transaction was completed, the customer changed their mind and either wanted to return or swap the product. If the product was opened the driver would hand it over to us and we’d return it. However, if it were still in the packaging, they would leave it in the vehicle and move on, because visually it was untouched. The only trouble with that is we used multiple systems that didn’t communicate with one another. So although one system recognized the change between sellable, non-sellable and back to sellable, the other required a ticket request to change the status. That meant if we didn’t know a phone was non-sellable in that system, we might send it out on a visit which would (1) ruin the customer experience if there wasn’t a second phone (2) waste the time of our drivers if they didn’t catch the error early enough and (3) left us pointing fingers at each other for not knowing the movement of our inventory.

I hated that. Whenever I felt like we were doing well as a team, something like that would happen and there would be a cascade of other issues. I made it my mission to figure out a way to stop it from happening. The first thing I looked at was how can we know which products are non-sellable? Well, every morning unbeknownst to us, we’re sent a report of non-sellable devices by email. The problem is that no one knew to look at the emails. Also, you had to manually check the report to know whether or not your fulfillment center had outstanding serial numbers to look for. I tried for about a week to check it and by day three I was too busy with morning duties that I couldn't realistically find myself opening the spreadsheet. They didn't appear all of the time, so checking a list daily for your name not to appear didn't feel like the best use of my time.

So I sat on it

The Solution

One day, I'm listening to the CodeNewbie Podcast and Joanna starts talking about how you can use code within GSuite for automation. Her specific story talks about a guy who would automate saving photos to his Google Drive from emailed links he'd receive from his daycare. And I thought to myself, well if he can do that, then surely there's got to be a way to import some text into a sheet from an attachment, and hopefully spit that information into some form of a Gmail notification.

The only problem was that I didn't know JavaScript. I had taken Java back in college, previously completed an Android Nanodegree, and dabbled in Python, but I had hoped that I could start my coding career without ever touching JavaScript. I wasn't afraid of it, I just thought there were too many versions and I didn't want to get caught up using the wrong one. So, on my next van shift, I pulled out my computer started looking at the documentation and figured out how to make a script that would check if an email with a specific subject existed. It was real janky but I could also locate the email I was looking for. I didn't know how to take it beyond that point so I setup email alerts every time it failed which didn't take long to flood my inbox. I thought I would eventually fix the error, but I just never got around to it.

I sat on it again

Once again, when we weren't paying attention, we got hit with another non-sellable related failed visit. Now I was determined to solve this problem. Instead of me thinking that I needed to learn JavaScript in order to code this script, I wrote out what I wanted the script to do and then I told myself to remain in the box and only learn what was needed to complete each step.

1. Check email with the most recent subject of [BLANK]
2. Open the attachment into a Google Sheet
3. Loop through the sheet to find our site's products
4. Save the value(s) and send them to Slack

Doing that saved a bunch of time. I'm definitely one of those people that like to know everything before I start something, but I also realized if I spent my time trying to learn JavaScript from scratch, I'd never get anything accomplished.

After several tests in my test channel I released it to the team.

The Response

The initial response was mixed. My immediate team was both excited and confused (most people didn't know there was even a report). I don't know if they shared my dislike of non-sellable devices, but they did see the value in it. More importantly, it got the attention of our engineering team who were skeptical about the code (Who wrote it? Was it open source? Who would maintain it?). Fortunately, one of the managers helped me reach out to the technical recruiter and that's how I got somewhat of an interview.

What about the interview?

So, the interview was more like a meeting between me and the technical recruiter. Their team mostly used:

• Ruby on Rails
• React
• JavaScript

Nothing that I really familiar with, but they explained that they accept people from various levels of experience. I'm also comfortable with teaching myself new things, so I wasn't too worried. I've listened to enough podcasts and programmers to know that you're ready when you're ready. Honestly, I would say that the interview went well, but I failed in two places. The first was my hesitancy to say I'd relocate. Apparently the engineering team was located in California. I just moved to New York two years prior and had no plans to go back any time soon. The second was really selling myself. I think what I did was useful and could help save time, headaches, and really made it easy for the average-non-spreadsheet-looker-ater to know what to do when the notification hit. The problem was explaining it to someone outside of fulfillment. Translating the value of how it saved me and my team time was great, but if they don't have a clue of what my job is then what was the point? Needless to say, there were no follow ups on my script. I'd get a few emoji eyes on the Slack messages Non-Sellabot would produce, and that was it. I was a bit disheartened, but I wasn't upset. I had solved an issue that plagued the team since I got there. And, built something using JavaScript without any previous experience. Using ES5 at that! So, after I setup the bot to work on my team's channels. I reached out to the rest of the East Coast fulfillment centers and set it up for them as well. I think that's when it reached a turning point because now I had something to maintain for other people. Now, I have clients who rely on my messages being timely and accurate.

The Aftermath

With Non-Sellabot having more eyes on it I customized the locations and what the links did. If you didn't have any devices to worry about, you got to celebrate with a random Youtube video from a handpicked playlist. If the spreadsheet was incomplete, it sent you to Sisqo. Having no real restrictions gave me the opportunity to make something boring and frustrating actually fun.

I wish I had saved more screenshots but in the end it evolved into the photos below. Just because I couldn't transition from fulfillment to development didn't make me a failure, nor did it change the value of what it accomplished.