Ryan's Ramblings

[newtonry]

Moved - Migrated to Medium

Hi all! I’ve migrated all my posts from tumblr over to Medium as I believe it is a platform more suitable for my needs. I even have a post about the migration in case you were thinking the same.

Anyways, catch me over at https://medium.com/@vonkunesnewton!!!

[newtonry]

Thoughts of a founder - 6 months

I'm going to use this post as notes for myself. I recently met with a founder of a company that lasted 6 months to discuss his experience. Here are some of the key takeaways:

Make sure that cofounder is the person that you want to start a company with. This seemed to be one of the primary reasons why it ended. An analogy given was "Just as friend doesn't necessarily make the best roommate, a friend doesn't necessarily make the best cofounder." Working with somebody on side projects, while they are still side projects is not the same as founding a company with somebody else.

Distribution of work. There should be well defined areas of ownership. When you're starting something there are so many hats to wear that you should be aware of what you're responsible for, and what your cofounder is responsible for. That takes the pressure off each individual so that they know that they can focus on what they're best at, whether it's engineering or marketing etc. It prevents one person from feeling that they're pulling all the weight.

A ‘nice to have’ is a cofounder that has complementary skills so that each of you can focus on what you're best at.

Founding a company is difficult, there are likely to be financial pressures that affect your personal life now that you're not getting a consistent paycheck every month.

Having a good network is key for so many parts of the process.

Finding an early investor at the start, with even a tiny amount of money, even $5,000 is extremely helpful. Nobody wants to be the first person to invest, so having that first 'buy in' makes it easier to raise money in the future. These investors can be anybody that you know or have worked with previously that is aware of your talent & work ethic.

Investors are investing in the team, not the idea. The idea pivots so many times, that they're putting their money on you.

Find 'advisors' when you can. Even if you end up giving them a portion of the company for their advice/help, it's still 'free' work that takes pressure off of you.

Always try and be talking to people who've done similar things or are in the industry you're focusing on. Talk to them about problems you're currently having, there's a good chance that they've encountered the same as well. The cost of a beer is cheap.

[newtonry]

Charsets & Collation in MySQL

Back at the end of 2014, I put a lot of time into ensuring that users uploading CSVs could throw almost anything at us and we’d be able to handle it. Recently an issue surfaced where we couldn’t handle those foreign characters that lead me down the rabbit hole that is collation and character sets in MySQL.

The issue that I was running into was our tasks were erroring out if a foreign character like the Ę in Ęlarmstrong were included. I dug deeper and we were reading it fine in unicode. However, when we tried looking up Ęlarmstrong in the with the Django ORM, MySQL was erroring out with the following message.

"Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='"

I never had any problem querying with unicode characters prior. I did a couple tests and noticed that it worked fine on our main shard. However, it always failed on the other shard. If you’re in a sql shell, you can use:

SELECT SCHEMA_NAME 'database', default_character_set_name 'charset', DEFAULT_COLLATION_NAME 'collation' FROM information_schema.SCHEMATA;

to find out what charset and collation you’re database is using. To dig further at the table/column level you can use:

SHOW FULL COLUMNS FROM some_table;

and see what it’s using. I noticed a discrepancy between our two shards. The main shard with no issues was set to utf8_unicode_ci, while the problematic shard was set to latin1_swedish_ci. It turns out that this is the default collation for historic reasons and that when the new shard had been set up, we never bothered changing it to utf8_unicode_ci. You can set the db to utf8 using 

ALTER DATABASE dev_messages CHARACTER SET utf8 COLLATE utf8_unicode_ci;

And the table with:

ALTER TABLE grail_emailunsubscribe CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

After making that change, I could then query for Ęlarmstrong without any issues! However, during code review a further point was brought up. Why don’t we aim to support emojis as well? UTF8 on it’s own does not. We needed something multi-byte.

I did a bit of research and came to the conclusion that utf8mb4 was the right charset and utf8mb4_unicode_ci the collation we wanted. Should be simple enough. So I re-ran the ALTER TABLE and ALTER DATABASE. Nope. It turned out that it didn’t work on some of the tables due to the following error:

Specified key was too long; max key length is 767 bytes

It turns out that the tables that had used some of the string type fields as UNIQUE KEYs would not work due to a size limitation. I was fine leaving these keys as normal utf8_unicode_ci because they were email addresses, and hopefully nobody has emojis in their email addresses.

However, the other possible solution to this was to reduce the size of the column as well. If the max key length is 767, then 767 / 4 bytes is 191. Currently the email column I was keying was set to a 255 character maximum. So I weighed the tradeoff and came to the conclusion that it’s a rare exception for an email address to be more than 191 characters. If it occurs, I’ll liken it to a Gangnam style situation.

Anyways, this just meant that I had to change the field size to 191 before, and then I could happily change the collation to utf8mb4_unicode_ci.

ALTER TABLE some_table MODIFY COLUMN email VARCHAR(191);

After that I was good to go! A fun learning experience.

[newtonry]

A reminder about python argument defaults

There’s an issue I’ve seen plenty of times before, but caught me off guard again today. Hence I figured I’d write about it as a reminder to myself. The morale of the story is that you should not pass non-static defaults into arguments in a method’s definition in python.

So for example:

class SomeClass(object):

def __init__(self, some_arg=[]): self.some_arg = some_arg

This will cause issues if you create more than one instance of the class with no value passed in for some_arg. It will end up re-using the same list, and different instances of the objects will share the same self.arg.

For example if I were to do:

first_object = SomeClass() first_object.some_arg.append(1) print first_object.some_arg  # prints out [1] second_object = SomeClass() second_object.some_arg.append(2) print second_object.some_arg  # will print out [1,2] even though we never appended 1 to the second object

What’s happening is that both first_object and second_object are referencing the same list, which was instantiated at the definition of the class. A somewhat non-intuitive pitfall, but makes sense if you think about it. This is also true for other mutable objects, so be careful what you set the default to.

A way around this, is to set the default to None and create a new list in such a case within the execution of __init__.

 def __init__(self, some_arg=None):     self.some_arg = some_arg or []

Anyways, just a friendly reminder to be careful about argument defaults!

Also an excerpt about it from Effective Python:

[newtonry]

Listening - an indispensable skill

Here’s solid piece of advice that’s always been true, but has recently reinforced itself several times within the past week. It’s always good to listen/read before you start doing/typing. Listening is an invaluable skill. It will save you and those around you a lot of time!

“Listen more than you talk.” - Clara Shih supposedly

[newtonry]

Browser behavior on keypress

I ran into a good reminder today. A feature I was working on has a search form, which should make an external ajax call when typed in or enter is hit. It looked something like this:

some_form.html

<form class="search-form">     <input type="text"data-action="performSearch" /> </form>

some_backbone.js

events: { 'keyup': 'performSearch' }, performSearch: function(e) { if (e.keyCode === 13) { e.preventDefault(); } ... }

The default behavior upon hitting enter within a form is usually to submit that form, hence we use javascript's event.preventDefault, which is pretty standard.

However, every time I was hitting ‘Enter’, the form would be submitted and the page would refresh. At the same time, I was still hitting the performSearch if clause, but only after the submit had already been triggered.

The solution is fairly simple, just use keydown instead (you could listen to the keypress event as well if you wanted). What was happening is that Chrome submits the form on keydown rather than keyup. It was a great reminder that a lot of the behaviors are determined by the client side browser, so there's always a possibility of quirkiness!

[newtonry]

I thought I had mocking and patching down decently in Python. Turns out I didn’t, as I spent too much time trying to figure out why my mock had no effect. I knew this was a common issue to run into, but tended not to often. Typically the issue is patching the incorrect method. After reading the docs very carefully, I realized that this was my issue too.

The clarification that I uncovered was that how the file you’re testing imports the method does make a difference. I initially thought you always needed to target the source. This is not the case. So let’s take a look at two examples.

Let’s say there’s a utils file, with a is_connected method you want want mock out and always return True.

# myapp/utils.py def is_connected(some_object): # some logic that you don’t care about right now

Now lets say another file, that you’re testing uses is_connected.

There are two ways in which you could import and use is_connected.

Option A

# myapp/the_file_that_needs_utils.py from myapp import utils called like such utils.is_connected(some_object)

Option B

# myapp/the_file_that_needs_utils.py from myapp.utils import is_connected called like such is_connected(some_object)

In Option A, utils is being brought in as a module. In Option B, we’re just importing the method. Patching works by replacing the name that an object points to with another (from the docs).

This means that in order to patch is_connected in a test, in Option A, we would want to target util’s reference to it. In Option B, we’d want to target it within the_file_that_needs_utils.py.

For example to mock out Option A, in your test file, you’d need to

# myapp/tests/test_stuff.py @mock.patch(’myapp.utils.is_connected’) def test_something(self, mock_is_connected): mock_is_connected.return_value = True

However, in Option B it would look like:

# myapp/tests/test_stuff.py @mock.patch(’myapp.the_file_that_needs_utils.is_connected’) def test_something(self, mock_is_connected): mock_is_connected.return_value = True

Anyways, read the docs!

[newtonry]

Debugging undefined variables within Chrome ajax callbacks

I’m the sort of person who learns a lot from playing around in debuggers and testing how everything works. While developing, I’m often dropping debuggers throughout the process just to confirm my beliefs, the second best way behind writing tests.

However, the other day I encountered an odd issue. I was working on a front end ajax call and dropped a debugger in the callback. Something like:

var varOutsideOfAjaxCallback = "Foobar"; $.ajax({ type: "POST", contentType: 'application/json', url: "http://some.url.com", data: data, success: function() { debugger } });

When I started to play around with variables, I kept running into the issue that varOutsideOfAjaxCallback was undefined.

That didn’t make any sense to me though. It should be defined. I’ve seen this work many times before. Javascript should look up the chain of scopes and find varOutsideOfAjaxCallback. I had no clue what was going on.

I normally work on Chrome, but decided to test it out on Safari. Strangely, varOutsideOfAjaxCallback seemed to work just fine in Safari. 

I was still pretty confused. Usually Chrome is the most stable of browsers. Scoping variables outside of ajax calls didn’t seem like something that should be significantly different between browsers?

I brought a few more eyes in to take a look, and they didn’t know what the deal was either. However, what we did discover was that if you did use the variable within the success callback block, it would work. For example, if I just even referenced it as exemplified below, it would then exist within the debugger.

var varOutsideOfAjaxCallback = "Foobar"; $.ajax({ type: "POST", contentType: 'application/json', url: "http://some.url.com", data: data, success: function() { debugger varOutsideOfAjaxCallback; // This line is the only difference! } });

It seemed pretty strange to me, but my theory is that Chrome does some memory management within blocks and doesn’t hold any variables that aren’t referenced within that.

I’ll have to research what Chrome is doing a bit more! However, it was nice to discover that I wasn’t totally crazy. Also, I’m surprised that I haven’t encountered this issue with the debugger before, but it’s always a good time to learn new things.

[newtonry]

Getting Lists from QueryDicts - Django

I was writing recently writing a test for an API endpoint and discovered something interesting. Maybe it’s a noob mistake to not already know about this, but it caught me off guard.

I was passing the following dict into a request as POST parameters

data = { 'str_key': 'A string', 'list_key': ['List index 0', 'List index 2'] }

All looks normal when I print out my request.POST QueryDict.

request.POST >>> <QueryDict: {u'str_key': [u'A string'], u'list_key': [u'List index 0', u'List index 1']}>

Now I can use .get to retrieve they keys as such

request.POST.get('str_key') >>> u'A string'

However, something strange happens when I try and get the list. It only returns the last object in the list, as a string!

request.POST.get('list_key') >>> u'List index 1'

This confused me for a bit until I asked a few people and did some digging to discover that to retrieve lists from QueryDicts, you must use QueryDict.getlist. It worked!

request.POST.getlist('list_key') >>> [u'List index 0', u'List index 1']

I’m surprised that I had not encountered this situation before, but it’s a good reminder that a QueryDict isn’t quite a Dict! So use getlist to retrieve lists from QueryDicts!

[newtonry]

Naming

Today I found myself spending a while discussing whether or not to call an enum ‘state’ or ‘status.’ Eventually I caved in and googled it to find that I’m not the only person to have pondered the difference. Although I spent a while on it, this incident reminded me of the importance of naming.

Good naming is something that seems to elude a lot of people, but is probably one of the most important aspects of being a good developer (especially one I’d want to work with). Readability is always pretty important if you want your code to be understandable by others, or your future self.

I take a very rubyist ideology; that your code should almost read like English. Being able to just read the name of a function or class and know exactly what it does makes people’s lives easier. If the name becomes too long, that’s a code smell... it should be broken down into smaller parts. Use descriptive names, with non-ambigous terms.

It’s not too infrequently I see non-descriptive short variables. Even in things like loops, don’t use single letter variable names! It may save you a few seconds of typing and another 10 seconds of having to think about a name, but down the road, it will cost people more time than that!

When an intern of mine started a while ago, one of his first pull requests used the loop:

for thing in things: # some code

Unless we’re talking Dr. Suess, thing has no meaning to me! After that, I tried to instill better naming practices.

Currently I’m working on a greenfield project where we’ve had to run pretty quickly. Even so, it’s definitely worth taking the time to think about naming. Who knows how many people will have to read it in the future. A few minutes saved right now could cost a lot of time and confusion later. Sometimes it’s a challenge, but naming is definitely a valuable skill and something to strive for!

PS: I’ll leave you with a parting fact. In the twitter api, ‘favorite’ refers to the favorite count of the tweet while ‘favourite’ refers to the favorite count of the user...

[newtonry]

Finding a job after a coding bootcamp - The most important lesson

All of the other previous posts have hopefully been helpful. However, I've held back on the most important lesson throughout my whole experience so far. And I better get to that before I talk about interviewing at all. You will be rejected!

You will have to fail a number of times before you can succeed, especially attempting to enter the field with a non-computer science background. You're going to be nervous for your first couple interviews alone. You'll fail on nervousness alone and stumble at solving simple questions that you could do in your sleep normally. You need those first few fails before you can find yourself comfortable and confident in interviews.

However, it doesn't get much easier just yet! Having picked up so much knowledge and new skills at your bootcamp, why wouldn't it though? Your ~3 months of intensive experience certainly teaches a lot, but there's a ton of missing gaps which you have to fill in yourself. The chances are you won't asked to build a simple Rails (or other framework) app. You're going to be asked about all sorts of things you don't know, and fail at those.

However, that it the best thing about interviewing! You get to go home and learn about the questions that people asked. If it was some sort of whiteboarding question I had trouble with, I'd go and practice similar questions at home until I was confident of my ability in them. If they involved some interesting algorithms, I'd go learn about those (MIT's ocw is a great place for this).

Then I'd head to the next interview and would ace the whiteboarding, fail at something new, for example data structures, which is a common thing that comp sci grads have studied, but you wouldn't necessarily have to deal with at the higher levels of Ruby. I'd go and read about all sorts of data structures, re-implement them myself, and never fail another data structure question.

Iterating through interviews and improving every time was what ultimately got me a job. Every interview was an opportunity to learn more.

One question I was once asked was "How would you build Gmail at it's current scale, that is with billions of users." I think this is an awful interview question, especially for a junior candidate, but it exemplifies new problems that I'd never had to think about before. I'd never built an email client. None of the apps I built ever had more than 100 users, if that. Sharding and denormalizing data and non-relational databases were all concepts that I knew about, but never had to necessarily implement, and alone wouldn't solve a problem this large. I went home and researched gmail as much as I could from an architecture standpoint and tried to think about all the ways to solve such a huge problem, and all the sub problems that stemmed from it. I may have done poorly answering that question on the spot, but I was able to leverage as an opportunity to learn.

tl;dr: Fail. Learn from your failures. Succeed.

[newtonry]

Finding a job after a coding bootcamp - Personal profiles

In my last post, I gave some ideas of where you can find good leads. Unfortunately, the chances are you won't be able to get an interview on your charisma alone. Typically when you apply at a company or follow up, you'll go through somebody on their recruiting team or HR, part of who's goal is to filter out candidates and not waste the engineering team's time.

You'll need some sort of tangible presence that says you're a good candidate and allows you to get your foot into the door and move into the phone screens. Below, I discuss my opinions on number of these 'public documents.'

The Resume

This is of course the classic document for any job regardless of what field you're in, so you'll need one of these! However, I also respect this the least of anything. In the past I’ve frequently encountered people with great resumes who were terrible and vice versa. I think it's generally a poor representation of a candidate.

Regardless of my opinions, it's an extremely important document! A problem which you likely face as a bootcamp graduate is the fact that you're coming from a different professional background. A lot companies even use software to sift through resumes.

It's important that you highlight your development experience and related skills as much as possible. Luckily, my previous job, although 90% video production did involve some work with mysql, and basic php/html/css. Hence, I tried to highlight instances of projects that required those skills. However, that wasn't enough to fully fill it in and many of you might not have anything similar from a past job.

The solution to this was to add a number of personal projects I'd recently worked on for fun or for the bootcamp. Surely you have some projects to add to it! Definitely list the technologies used in the project in addition to a link to the live product or github repo. Don't hesitate to repeat listing technologies for different projects, as this helps pass the software filters which look for the frequency of terms like 'Ruby on Rails.'

An example:

Revris (http://revris.fadetoproductions.com/) -A challenging variation on Tetris that reverses the board and controls on every line scored. Revris was created with Javascript, HTML, and CSS.

Hopefully you can write better than me as well :).

However, be ready to talk about every skill or item you add to your resume. Interviewers often like to pick up on skills that they have in common and discuss those to figure out your depth of knowledge, although hopefully they’re aware you’re of junior experience.

The same with projects. I know some bootcamps have group projects, so be careful what you add there if you don't have a strong grasp of how certain parts of it were built!

In addition, never say that you're an expert at a technology. This is a clear red flag because either you’re so new that you don’t understand the full complexity of the technology, or you created it (and likely wouldn’t be reading this post).

Cover letters

I discussed cover letters a bit already in application strategy, but I generally don’t believe you should spend much time on them unless you have a particular connection to a company. Often they’re required, so I use a rough template and simply state what I’m looking for and what I’d like to learn about the company. They’re used to get your foot in the door, but don't have much impact after that. Companies are generally more interested in whether you're a good engineer and cultural fit, which they figure out from the interview rather than your cover letter.

Disclaimer: My thoughts are specifically in regards to software engineering and think that cover letters may carry much more importance in other professions.

LinkedIn

This is a more interactive and informative clone of the resume in my opinion. If you don’t have a LinkedIn, you’d better create one… especially if you’re looking at joining the tech industry!

This seems quite important, as I can always see recruiters and interviewers looking at my LinkedIn profile before talking to me. This also gives you the chance to look at them and figure out what their background is! Plus once you throw a few projects on there, all sorts of recruiters start messaging you. LinkedIn is more flexible and can become a better representation of you than your resume.

A tip for your LinkedIn profile: make use of the customizable url. For example mine is https://www.linkedin.com/in/vonkunesnewton.

GitHub

Github is definitely the most important resource in my opinion! And certainly the most indicative of your ability as a developer. You should have a number of commits up there in the most recent months. It shows that you are always active and programming. It also gives interviewers a sense of the code you’ve written. You should definitely link to it from both your resume and LinkedIn profile.

One thing that I did to get a lot of attention was actually abuse the commit graph:

Personal site

I don't think that personal site is necessary if you have solid LinkedIn and Github accounts. However, it does give you an opportunity to paint a bit more of your personality and present your projects in your own manner. I built mine way before App Academy as an exercise in Javascript and writing a CMS. However, there are plenty of better ways to get a portfolio out there if you don’t want to spend too much time coding the site.

Blog

Having a blog is quite beneficial to the job hunt, and even after it! Even if it’s only once a week, it’s quite easy to come up with a topic. What was the hardest problem you faced that week, what did you discover about it, and how did you solve it?

Having to write about a problem reinforces what you learned as well as allowing you to dig even deeper. Even if it’s a topic or issue that might not be groundbreaking, it still helps you and could help other people at your skill level in the future.

Like many other things you’re hopefully doing, blogging is a way to show that you’re actively programming and thinking about it as well as creating a stronger online presence.

My current team lead also makes the point that blog posts make an interviewer’s job a lot easier. They can see what sort of issues you’ve dealt with recently and talk about those rather than having to dig to find topics to discuss.

App Academy required us to write a post every day, which I think was too frequent, although I'm certainly glad I did. Although many of my classmates stopped afterwards, I continued and know for a fact that some of the interviewers read through it.

Facebook

I don't have strong opinions of Facebook asides from either keeping it private, or creating a 'professional' profile and hiding your other behind a less accurate name. I don't want to put the effort into maintaining a professional profile, so I just keep my personal private (although there's nothing too incriminating on it anyways)!

Do make sure to try and check out your own profile from somebody else's account though and confirm what's actually public.

Conclusion

Those are my thoughts on some of the profiles you want to have out there. In the end you're looking to paint the best accurate picture of yourself possible so you can make it to the next step: interviews!

[newtonry]

Finding a job after a coding bootcamp - Creating opportunities

In my previous post about finding a job, I concluded that the best approach was to spray and pray. However, in order to do that, you need a solid stream of places to apply. Here are some of the resources I used during my search and my experiences with them.

Meetups

As I previously discussed, meetups are pretty amazing for a number of reasons! Every company that hosts a meetup is hiring. It's far cheaper to lend out your space and pay for some pizza & beer than pay a headhunter referral fee.

Many of the people that you meet there will also at companies that are currently hiring. It requires you to be social and talk to people, but hopefully you're capable of that, especially when discussing interesting topics & ideas within programming.

And did I mention: free beer, pizza, and a chance to learn something new! Ultimately, I ended up with a number of great contacts and interviews out of meetups, so I'd put this one high on the to do list.

Job fairs

Obviously everyone at job fairs is hiring! Be careful though, as it's easy to get sucked into talking to each booth for too long. In the end most of the companies tend to blend together. Also, unfortunately most of the time, the people at the booths are recruiters rather than engineers so it's often hard to get the most thorough sense of the company.

My suggestion is to visit each booth briefly, figure out what they're looking for and get a business card from everyone one of them. Then follow up!

Also, I think this was the only time asides from in person interviews where it made sense to have a hard copy of your resume present. Although, not everyone collects them, some booths did and followed up based on it.

LinkedIn job postings

This is definitely a small pool of offerings, but I discovered that the companies paying for a spot on there were very serious about hiring. I ended up with a great response rate and even offer out of it. However, I felt like once you did one loop through the listings there wasn't too much after that. So good as a one off, but no much replay value. Also, don't get sucked into any listings by CyberCoders there, as it's a giant waste of time!

AngeList

AngelList was the best resource in my opinion. It's also how I found my current job at Hearsay Social. There's a great list that lets you filter by company size (a pretty important factor). The response rate wasn't as high as something like LinkedIn job listings, but it was also very easy an quick to send off messages.

There's a limit to the amount of text you can send into a message, so my standard was a lean paragraph explaining my background and asking what they were looking for. It essentially allowed me to send off requests easily with very little time investment, adhering to the spray and pray. And the response rate was very high for this strategy!

WhiteTruffle

WhiteTruffle seemed quite similar to AngelList, but much smaller. I did get a few good responses from it, so I would suggest checking it out. However, it definitely shouldn't be your main source of applications (although maybe it's grown a bit more by now).

Bootcamp Associates

I imagine this varies quite a bit between bootcamps, so I can't speak for all. However, they're a good start since they're obviously considering hiring bootcamp graduates.

When I was at App Academy, there were about 4-5 during our demo day. That number has grown now from previous visits I've done to demo day. The companies also change during each cycle, as they're looking to hire a few junior engineers then hold off for a while before they have enough seniority to mentor a new group of junior engineers.

Although bootcamp associates are a great way to get some of your first interviews, I most likely wouldn't count on them being your final stop during the search.

As far as I'm aware, some of the other bootcamps have to pay a rather hefty referral to the bootcamp. Although it may not seem like it, chances are part of that is coming out of your salary, so be careful of getting low balled this way.

Headhunters and recruiters

When it comes down to it, nobody will work harder for you than yourself! There were a few headhunters and recruiters that I approached me throughout my search. However, no leads ended up coming out of them.

One even took the liberty of changing my resume adding stuff that I didn't necessarily want on there, adding her company's logo, and destroying the layout. As somebody with a visual background, it's new sloppy look bothered me.

Another suggested there was no way I'd get an offer above a certain amount, which was proven wrong by a strong margin. This reminds me of an idea presented where homeowners and their real estate agents are at a conflict of interest. A house selling for $100k accepting an offer at $80k would mean a ~$20k loss for the homeowner, but only $1-2k loss for the real estate agent, which probably wouldn't make up for the extra time and effort the agent would have to put into selling it. Hence, the agent is eager to have you take a lower offer since they don't lose much.

I think that companies are also skeptical of recruiters. Like the bootcamp referral fee, some of it could be coming out of your pocket. Ultimately it's much nicer to find a company organically and reach out to them yourself. There's really no need for the middle man in this scenario.

That's not to say don't let them send your resume around a bit, but definitely don't rely on them. I often wished I'd sent my resume myself than through them.

PS: Also if they ever ask you what other companies you're applying at, don't give them that info.

Hacker News monthly who's hiring

Hacker news is generally a great source for information! They also have a monthly job posting thread. For example December 2014. Companies that are on here are probably relatively smart and likely to be the sort of people you want to work for. Also, in any contact with them, definitely do mention that you spotted them on Hacker News (back to showing off your love of programming)!

Conclusion

There are a ton of other places to find opportunities. There are a lot I missed as well, I'm sure. But keeping on searching! Also, don't forget to apply to Hearsay Social, as we're hiring. Shameless plug!

grnh.se/u2ibsa

[newtonry]

Finding a job after a coding bootcamp - Application strategy

There are multiple ways of approaching the application process. One is to take it slow and send very precise applications out to companies. The other is to spray and pray. During my search I tested both strategies.

The slow approach Initially I took the slow approach and spent  ~30-60 minutes per application, picking out companies that looked particularly interesting to me. Companies that I was able to ‘emotionally’ connect with based off their website or marketing materials. I would then craft a custom cover letter specifically for them. This method yielded a higher response rate than spray and pray.

Although the response rate was higher, it actually led to few technical phone screens and in person interviews. It did lead to more non-technical phone screens, but the result was frequently the same as both parties would come to the conclusion that we were looking for different things.

This was a very costly in terms of time. If I spend 30-60 minutes to get my foot in the door, only to talk to them and both agree that they weren't looking for junior engineers, then I've just spent my time quite inefficiently. It reminds me of a paper about why Nigerian scammers say they're from Nigeria and reducing false positive rates.

Basically I don't want to put much time and effort into a company until I know that there is a higher chance of success. Sometimes spending the 30-60 minutes even yielded no response. I'd rather be spending that time working on my own projects or learning more.

Another major issue with this method is that by being selective in where you apply, you’re substantially limiting the company pool and number of possibilities out there! While looking at company sites it’s often difficult to decipher exactly what they do. After looking at enough company sites, the all sound like they do the same thing anyways, described with random buzz words (yes, this might be a problem on their end).

Not only are you limiting your selection pool, but you are likely to miss out on some potentially great fits. Frequently the problems companies are solving sound very dull from the outside, but can be very complex and interesting once you really dig into them.

Spray and pray

Although far less personal, I consider spray and pray to be a superior approach. Just apply to as many companies as possible! Try not to spend too long on each, especially when it’s a blind application. AngelList was great for this because the number of characters per message was limited, so I could just write a quick inquiry and not spend more than about 5 minutes on each application.

The advantages with this are huge. You’re not investing almost any time looking at companies that will be dead ends for you. Once you get a positive response, you can then research them a bit more before the phone screen. This frees up a lot of time!

More importantly, even if you end up interviewing with a company that you don’t initially want to work for, it’s a free practice interview! Engineering interviews are more intense than almost any other profession. They are generally long, require complex thinking, and great communication of that logic.

Any additional practice to get over the nervousness means that you’ll appear to be a much stronger candidate when you do land the interview at the company you want. You can learn something from every interview no matter what! You definitely don't come out of a bootcamp knowing everything, so interviews often give you a good idea of new topics to learn about (more about this in a future blog post).

Plus, who knows… maybe you’ll end up really liking the company or people! If you do happen to get an offer from a place you don't like, it's still good leverage for the future offers coming your way.

Conclusion

Don't be too selective in applying, apply everywhere! Don’t skip out on any opportunities! Don't spend too long on writing applications, cover letters, and learning about companies until you know there's a high chance of moving forward with them. That time is better spent elsewhere!

[newtonry]

Finding a job after a coding bootcamp - Demonstrating passion

When it comes down to hiring, I'd always rather work with somebody who's passionate, loves what they do, and is a self starter. Having gone through a bootcamp, I assume you love engineering (otherwise the 80-90 hour weeks wouldn't be tolerable). Here are some ways in which to demonstrate your passion!

Always be working on a project! One question that almost everybody you encounter will ask: "What project(s) are you currently working on? What sort of challenges have you faced with it?" You better be currently working on something. If you aren't, then you're probably not enthusiastic about programming anyways.

Plus who wouldn't love the spare time to just come up with a quick idea and just build it? Any new technologies or tools you wanted to play with? Or areas you want to learn more about? This is the perfect opportunity to work with them! You not only get to build stuff and learn more, but use it as leverage in the job search.

The projects can definitely vary in terms of scope. Some can take a day or two, while others weeks. For example, I threw together Revris, aka reverse Tetris, just because it was fun to build.

Another type is contributing to open source projects. These are great because they show that you are a dedicated member of the community. In addition it helps build the valuable skill of how to work with other people's codebases, which is not necessarily an area much time is spent on in bootcamps, but is guaranteed to happen when you join a company.

Some more projects that can be fun to work can be larger scale coding challenges. Often times companies have coding challenges as a means of filtering out candidates before they even talk to you. Sometimes the challenges are quick, and other times they take a few days. If a challenge is large, that could potentially be another cool project to work on and learn from. Although, don't jump at all the coding challenges you encounter (time management is something I'll discuss in a future post). In the end, I gained a lot of depth in certain topics by working on coding challenges.

And don't forget hackathons! Just another awesome opportunity to build something in a couple days and make a lot of good connections.

Go to meetups! Meetups are awesome for a number of reasons! Foremost, you get to learn more about a particular topic. Sometimes even obscure topics can turn out to be really enlightening.

The company that's hosting it is most likely hiring and the majority of the attendees probably work at companies that are currently hiring. You can definitely pick up a lot from the people there, and the fact that you're at a meetup sends a strong signal that you're interested in programming in your spare time!

However, let's not forget my favorite aspect of it... free food & beer! In tech heavy cities such as SF and Boston I'm convinced that you could eat for free every night of the week just by going to meetups. And that's definitely not a bad thing when you're jobless!

Those are a couple solid ways to be constantly improving and showing your love of programming. Although working on projects and going to meetups is a good start, the sum of those won't land you the job. There's a lot of other things that need to be happening in order for you to succeed.

[newtonry]

Finding a job after a coding bootcamp - Setting expecations

Having gone to a bootcamp is not a credential

Let’s start off by bringing you back down to earth. You’ve been working 80 hour weeks studying for the past 3 months and learned a ridiculous amount at an impressive pace that isn’t for the weak. Having just made it through such a rigorous period is a huge accomplishment… but not to employers.

No matter how difficult the program was, smart the people were, or the prestige of the bootcamp, employers don’t care. It’s actually often a detriment to mention it (although don’t avoid talking about it if it finds it’s way into a question or conversation).

I’ve often heard recruiters talk negatively about coding bootcamps. They’ve interviewed people from similar programs before, often with disappointing results. This is a result of a lack of regulations and standards amongst bootcamps. They all get lumped together regardless of how intense (or not) a program was.

In the end, why does it matter anyways? You didn’t go to bootcamp for a certificate or piece of paper (I hope). You went there to learn as much as possible because you love programming, and demonstrating this will give you a far higher chance than any mention of a bootcamp.

In the next section, I'll describe different ways to demonstrate your passion for programming, if you're not already doing some of them!

[newtonry]

Finding a job after a coding bootcamp - Intro

Intro

A number of people have asked me about the process of finding a job after App Academy, and I even ended up giving a talk to a recent RocketU cohort. Hence, I’ve decided to write about my experience as a coding bootcamp ‘graduate’ in order to help out anyone else who’s going through the same process.

Finding a job is complex and there are numerous topics to discuss, so I'm breaking this out into a multi-part series of blog posts.

And a disclaimer: All these conclusions are based off my experience, which is likely to vary for different people so don't take them as absolute truths!