Entrepreneur First (An Applicant’s Guide)

Today, I’m going to attempt to write a comprehensive guide to the Entrepreneur First application process, or version 2.014, at least. The process between submitting your application and receiving a final outcome is certainly a long one, and one that will challenge you and stretch you in ways that you may never have experienced before, but it will also be one of the most enjoyable applications you make. Do bear in mind that this is one person’s perspective on proceedings, and there are 49 other cohort members who each had their own unique experiences.

Before launching into this guide, I should begin by explaining exactly what EF is for those who don’t know. EF is a graduate tech accelerator designed to harness the potential of pre-idea, pre-team individuals just out of university, and in doing so, aims to help foster a real startup culture in London comparable to that of the Valley. After gaining a place on the scheme, graduates attend part-time ideation/team building sessions throughout July and August, before beginning full-time in September and finishing at the end of February, when a demo day is held in front of investors, angels, and others.

From the first 2012/13 cohort, 11 tech startups emerged from the scheme which now have a combined worth of $50m, and I’m eagerly awaiting the results of the 2013/14 cohort demo day which took place yesterday! AdBrain, of the 2012/13 cohort, just recently raised $7.5m in their series A funding round, managed to lure Googler Jesse Hurwitz from Google Mobile onto their team, and already have offices in both London and New York. Success stories like this are what make EF so appealing to young grads, and I, personally, cannot wait to get started.

I should also add that the entry statistics are quite scary, and I’m very glad I didn’t know about them until after I got in! Of the 700 applicants for the 2014/15 cohort, only 50 offers were made – some quick mental maths shows that there were 14 applicants for every place. I’m sure the ambitious amongst you won’t be put off by such figures, but let it serve as a warning for how competitive the process will be.

So let’s begin.

The first step in the process should be obvious, and that is a check that EF is suited to you and your goals. Signing onto EF also means signing onto the riskiest year of your life, and failure is a very real, very viable option. A lot of people are keen to go into a stable job with a decent salary straight out of University, and the startup lifestyle certainly isn’t for everyone. Whilst the success stories may make the scheme seem very glamorous and prestigious, I’ve been warned that the full-time aspect of the course is gruelling and draining, and I’ll be sure to update you over the next year through this blog. If you’re sure that you want to do EF, it’s time to fill in the form.

The form is offline for now, so you won’t be able to access it yet, but I can give you a rough idea of what to expect. As well as all the usual basics, you’ll be asked about skills that you think would be valuable in a startup context, and in my opinion, a varied and broad knowledge of web technologies will stand you in good stead here. You don’t need to be an expert in all of them, but technical proficiency seems to be more of a baseline than the official EF literature perhaps lets on, and the fact that 96% of the 2014/15 cohort describe themselves as technical really speaks for itself. You’ll also be quizzed on impressive achievements and startup ideas you’ve had, so if you’re reading this now and are unsure of how to answer the first of those questions, get building! Start with a simple website or app over the Summer and continually expand it from there. Honestly, it’s the best way to learn.

The deadline for these forms will be around New Year’s Eve, but I’d advise finishing it before then! (See here for some relevant stats.) If you manage to impress the EF team, you’ll be invited for a short Skype interview, and by short, I mean 10 minutes. This will be almost quick-fire in nature, so make sure you can get your ideas across succinctly and effectively. One or two of the questions at this point threw both myself and some friends, and covered things like current tech trends and achievements of ours that we thought were particularly exceptional. I don’t want to give too much away, but make sure you can really sell yourself as a one-of-a-kind rarity.

If you’re successful, you’ll then be invited to the EF offices in London for a half-day interview, and this is where things start to get really interesting. My experience lasted from 9am until 11.30am, and consisted of a challenging interview with Alice, a technical interview with a current EF cohort member and an EF grad, and then an hour-long coding test. Again, I don’t want to give too much away, and I definitely don’t want to be providing you with interview questions, but the questions Alice fired at me were tough. Prepare to have a lot of your ideas rigourously challenged and critiqued, and be ready to either defend them or objectively analyse them. This interview was really enjoyable, and I got a lot out of it, but it was unlike any interview I’d experienced before!

Next up was a technical interview, which I really enjoyed. We chatted about web technologies that I had used in the past, what I liked and disliked about them, and examples of things I’d built with them. This quickly changed into a good chat about tech trends and what we loved about certain programming languages, and I got to demo my dissertation project, which was also really fun. (Expect a blog post on that in the coming weeks…)

Finally, the coding test. We were given three algorithms problems to solve in an hour, but as a student on the notoriously theoretical Cambridge CompSci course with very little experience of these types of tests, I don’t think I performed very well. I believe I can code well, and with some time, I could have figured out good solutions to the problems, but I had rarely been exposed to such time-sensitive coding tasks, and the pressure of coding quickly was quite overwhelming. Some people thrive on these things, even taking part in competitions, but I don’t (yet) and so I can say with honesty that this was the toughest part of the whole process.

Thankfully, my performance in both of the interviews made up for any shortcomings in the coding test, and I was invited to the final-stage selection weekend, again in London. This was an awesome weekend, and served as a really cool introduction to a lot of my fellow cohort members. I reckon I was the youngest there (ages seemed to range from 20-30), which was intimidating at first, but after some fun icebreakers involving dancing around, pretending to row, and generally acting like pirates, we got stuck into the Unconference section of the weekend, and I quickly settled into proceedings. An unconference is a “participant-driven meeting”, meaning we would host discussions and workshops rather than lectures, and topics ranged from the importance of good design in a startup context (co-hosted by myself) to behavioural economics, and polyphasic sleep. (The general consensus? Don’t do it) I learned a lot from each of these workshops, and had some really engaging discussions with some brilliant individuals.

The bulk of the weekend, however, took place in the form of a hackathon, and as a self-confessed hackathon-virgin, the prospect terrified me. The idea of a hackathon had always massively excited me, and I had been meaning to compete in one for a couple of years, but something or other had always gotten in the way, and I had stayed firmly in my comfort zone. I’m sure anyone who’s ever competed will remember the fusion of raw fear, adrenaline, and excitement in the moments leading up to their first hackathon, and by the time we were pitching our ideas to the group, I had become so overawed by some of the other pitches that I completely neglected to pitch my own. Thankfully, I had discussed my idea for an informative, objective website about the fast-approaching Scottish Referendum with a fellow Scot over lunch, and after checking it was okay with me, he pitched it to the group.

“Now, James over there originally came up with this idea, and I think it’s awesome.”

This very short pitch was both extremely validating, in that someone had faith in my idea, and also potentially disastrous. (More on that later…) After the pitches, I decided to throw myself fully into the ScotRef idea, and to my surprise, quite a few people wanted to get on-board with it; we actually had to turn people away once we reached a team of five!

We started brainstorming around 5pm, and decided we would build a crystal-clear, highly interactive guide on the Referendum. The page would be split into two columns, one for each outcome of the vote, and we would inform users on how different dimensions of Scotland, such as the Economy, Defence, and Healthcare, would be affected. We were also going to ask users to vote on which outcome they wanted, and planned to display some engaging, real-time graphs at the top of the page showing which way our visitors were leaning. Further to this, we were going to allow users to add their own reasons to the bottom of the page, which would then be voted up and down by others. Essentially, we planned to build Reddit for the referendum, and this was only a small aspect of the site.

Yes, we were very ambitious.

As it transpired, building Reddit in under 24 hours proved extremely difficult, as did creating the dynamic visualisations we had planned. Fortunately for us, one of our members was a Node.js wizard, so we went with that as the driving force of our site. Unfortunately for him, few of the rest of us had ever worked with it before, and this very quickly created a HUGE bottleneck.

I could write for hours on the various successes and failures of my first hackathon experience, but instead, I’ll summarise with three lessons that I took away from it:

  1. Choose a stack that the majority of your group are comfortable with. As I mentioned earlier, choosing Node.js seemed like a bright idea at the start, but our wizard got extremely frustrated when none of us Muggles could jump in to lend a hand, and it was equally aggravating for myself to watch him drown in tasks whilst I could do nothing of use on the server-side.
  2. Always be assessing how each individual is spending their time. A lot of the time, it felt like a few of us were working on non-essential features, or sometimes, just barely working, when we could have been using our time much more effectively. This definitely doesn’t involve slave-driving, and by all means, take breaks, but don’t be afraid to ask someone about the urgency of their current focus, and likewise, don’t be offended if someone else keeps you in check. Egos should be left at the door.
  3. Even if you feel like you’re on a sinking ship destined for disaster, all can be saved by a great demo. It’s very unlikely that your code is going to be exhaustively inspected or tested, so if something really isn’t working, just focus on making it look good. There were moments throughout the 24 hours when I worried that we might not have anything good to show, but by channeling my efforts into making the site look damn good, tailoring our presentation towards aspects that worked, and speaking with passion, conviction, and importantly, humour, we received a lot of good feedback on our efforts. HALF OF IT DIDN’T EVEN WORK, and we were experiencing crashes and failures right up until the last minute, but by making it look slick, we created an impressive vehicle for the original idea.

Midway through the hackathon, we were each interviewed on a one-on-one basis by a member of the EF team, and this brings me back to the “disastrous” aspect of my idea being pitched by someone else. I was grilled on this during my interview, and I vividly remember being asked

“So, do you think you struggle convincing others to get involved with your ideas?”

I definitely don’t, but this was a tricky question to parry; to the EF team, who were closely assessing us throughout the weekend, I seemed to have come up with an idea and then failed to pitch it. In all honesty, I had simply been overwhelmed by some of the ideas presented by the others. As I mentioned before, I was probably the youngest there, and though this is no excuse for a lack of self-belief, there were some applicants who planned to hack on top of their own seriously impressive projects. This threw me a little, and made me question whether my idea was of a high enough calibre to compete, but I’m so glad we went with it. I’ll remember this experience for a long time, and in future, I definitely won’t be shying away from the opportunity to pitch my ideas, even if some of the others seem better at the time.

Following the final presentations, the weekend was brought to a close by Matt & Alice, and we enjoyed a few drinks before parting ways and heading home. I was absolutely exhuasted, and one final piece of advice I would give is this: make sure you get enough sleep. I stayed with a friend who I hadn’t seen in at least a year on the Saturday night, so we were chatting until the early hours, and I was absolutely exhausted by the end of Sunday. Unhealthy amounts of caffeine can only sustain you for so long, and eventually, the fatigue will catch up with you, so do yourself a favour and make sure you’re well-rested.

The EF team were wonderfully prompt with their final decisions, and I received a joyous call from Alice the next day letting me know I’d been accepted! It had been a long road, and definitely something of a rollercoaster, but I gained an immense amount of experience (and fun) from it, and I’ve emerged with a whole treasure trove of new knowledge.

As I mentioned before, the process will stretch you to your limits, and there will definitely be questions that you can’t answer. There were a few for me, and being at a complete loss for words isn’t a pleasant experience. However, if you’re good at thinking on your feet, building things quickly, and proving to the team that you’re a worthy candidate, you’ll be just fine.