Michele Degges

Exploring Code and Design in SF

Technical Challenge

Challenge

After applying to a few startups on Angellist, I was super excited to have gotten through my very first phone interview. At the end of the call, the HR rep scheduled me for a technical challenge. He said I would have up to 24 hours to complete the challenge, but that I’d have to check in at the 2 hour mark and report my progress. I would be assessed on both the first draft of my code at the 2 hour mark, and the final version.

The task was pretty straightforward: to create a game in the language I felt most comfortable in. Since I applied for a backend position, I wasn’t supposed to create any front-end or accept any user input. The program was supposed to simulate the turns taken by players and have a function to print out the board in ASCII.

Now.. this was a pretty challenging task for me. I got the basic version down, but it took me about 4 hours to complete and another hour of debugging before I felt comfortable enough to submit the final version. Here’s what I learned from the whole process:

Don’t freak out!

Once I got the challenge emailed to me, I set an alarm for 2 hours. While this helped me keep track of my time, it also made me really anxious as I saw the minutes slipping by. I would have gotten further along much faster if I didn’t obsessively check the time every five minutes.

Find a quiet place to work

When living in a house with 20 other people, it’s hard to find a quiet place to think, let alone code. My advice is: either lock yourself in your room and ask your roommates not to bother you, or get out of the house for a few hours. I ended up on a park bench for my last- and most productive- hour.

Hit MVP before trying to get fancy

Everyone always says to hit MVP first before trying anything fancy, even if your MVP is the most obnoxious piece of code you’ve ever written. Now I know why I keep hearing this- it’s the best piece of advice out there. Get something working and then revise if you have any time left. If not.. you won’t have anything working to show for all of your hard work. To reiterate: GET SOMETHING WORKING!

I didn’t take my own advice on this one, and I ended up wasting a lot of time trying to debug a function that just wasn’t working. At my two hour check-in, I barely had any working code to show.

If you don’t have time..

Sometimes there just isn’t enough time to refactor. I submitted the final version of this challenge about 5:30 hours in. It isn’t fancy- actually, it barely hits MVP- but it works.

I had a lot going on- I had another in-person interview to prepare for, I had to continue working on another piece of code that my team needed to present the next day, and I was just plain exhausted from coding so much.

Are you sure you want to submit?

The thing is- I probably could have created a more elegant solution if I had spent more time on it. That’s the thing about coding: it’s impossible not to improve. The more time you spend coding, the better you get, the smarter you become.

I did have the full 24 hours to finish the challenge, but I submitted at around the 6 hour mark. In hindsight, I should have slept on it for a few hours and woken up to work on it the next day with a fresh pair of eyes. I was afraid that taking all of the allotted time would reflect negatively on my abilities, but you know what- I think it’s better to take more time to submit something you can be proud of than to submit the bare minimum and regret it all week.

My solution

I’m not very proud of my code, nor am I happy with how far I got on this challenge, because I really did just barely get MVP. I don’t expect this to land me the job I was going for. In fact, I will be suuuper surprised if I get any reply back from that HR guy, but that’s part of the reason I’m posting this now.

This is honestly the skill level I’m at right now

This is how I code. This is truly a reflection of where I’m at. Sometimes it takes me forever to get anywhere (like it did with this challenge). Sometimes it takes me minutes. That’s how it is for us stone-cold beginners. But you know what… that’s okay! I’m getting there, and you’ll get there too. With each new challenge we take on and refuse to give up on, we get better and better. We shave minutes off of our time. We’re able to think more logically and efficiently. And most of all, we can feel proud of ourselves because we really did try our hardest.. and we didn’t give up!

If you have any questions, feel free to hit me up at mdeggies@gmail.com, or message me on twitter.

Integrating Jekyll With Gh-pages

Octopress

Integrating Jekyll with gh-pages shouldn’t take more than 15 minutes. The idea is simple: you already have a personal website hosted on yourusername.github.io. The goal is to create a blog and host it on yourusername.github.io/blog. Sounds easy, right?!

Well, not so fast.. Jekyll and gh-pages are not the stellar, easy-going couple that they claim to be. Integrating the two- especially when you already have a static site at yourusername.github.io- is not such an easy task.

In comes Octopress! Octopress is a static blogging framework built on top of Jekyll. It’s supposed to allow for easy integration and deployment. I was so excited when I found out it existed.. but then I started reading through it’s documentation and my excitement fizzled out pretty quick.

The goal

We know the goal- to get a blog up and running on gh-pages- specifically, gh project pages- since we already have a site at yourusername.github.io

The steps

First, create a new repo on github.com called blog. This is where our octopress site will live. Copy the location (https://github.com/yourusername/blog.git).

In your terminal, navigate to the directory you want to create and edit your blog project in. In that directory, perform these commands:

  • git clone git://github.com/imathis/octopress.git blog
  • cd blog
  • git init
  • git add .
  • git remote add origin https://github.com/yourusername/blog.git
  • git commit -m “initializing octopress”
  • git push origin master

You’ve just initialized your blog project with Octopress! Now let’s set everything up:

  • gem install bundler
  • bundle install
  • rake setup_github_pages

At this point, you’ll be asked to give a repository url. Use the same url you copied from github (https://github.com/yourusername/blog.git)

  • git config branch.master.remote origin
  • rake install
  • rake generate
  • rake deploy
  • rake preview

Rake install will install the default Octopress theme on your site. Generate and deploy will get it running, and preview will allow you to preview your site locally at localhost:4000

HOLD UP!!

There’s one last step you need to follow to get your blog up and running! Navigate to the _config.yml file in the root of your blog project. In addition to changing the default info in ‘Main Configs’ to your info (url will be https://yourusername.github.io/blog - title will be whatever you want - author will be your name - etc) you must do one more thing!

Navigate to the ‘Jekyll & Plugins’ section. Change the option

root: /

to

root: /blog

This will point the root url of your site to the correct page. Don’t forget to do this step, or none of your styling will be visible (as you will be doing GET requests to the wrong urls!)

After adding, committing, and pushing your changes to github, you’ll be able to view your blog at yourusername.github.io/blog

Optionally install a new theme

To install a new theme, such as ioveracker’s MNML, follow these steps:

  • git clone git://github.com/ioveracker/mnml.git .themes/mnml
  • rake install[‘mnml’]
  • rake generate
  • rake deploy
  • rake preview

And that’s how it’s done

As always, don’t forget to git add . && git commit -m “updating site..” && git push -u origin master to save your changes and make them visible at yourusername.github.io/blog

If you have any questions, feel free to hit me up at mdeggies@gmail.com, or message me on twitter.