Looking for your first Developer Job?

It’s been a while since I’ve posted on Rails Mama, and I want to let my readers know about my new site, Dev Ready.

The new site is all about the path to becoming a professional web developer. I’ll be sharing tips on interviewing, job search, surviving coding bootcamp, and finding the best online resources for learning.

Check out my first posts (all related to the Junior Developer job search):

I would love to hear your feedback on the site. Good, bad, or neutral, all feedback is appreciated!

Join me at Dev Ready!

The Interview Coding Challenge

As part of the “Get a job as a programmer” ordeal, you are required to walk the catwalk in your skimpies. Well…not really, but you are required to complete a coding challenge, which feels pretty much the same.

This torture tactic generally takes one of two forms:

1. Screen Share, a.k.a Virtual Peeping Tom: The interviewer uses a screen sharing program to watch you complete a coding challenge. You are uncomfortably aware of their presence, but Thank God you at least have access to documentation and text highlighting. You still feel dirty even after uninstalling the Screen share program, restoring your system to the factory image, and taking several showers.

2. Whiteboard (not to be confused with Waterboarding): You use a dry erase board to complete a coding challenge with no access to documentation, and without the comforting feel of your beloved keyboard. I have not had to experience this, or if I have, I am currently repressing the memory and would appreciate it if you steer clear of possible trigger words, such as “FizzBuzz” or “dry erase marker”.

Okay, so I’m being a bit melodramatic. In actuality, the interview coding challenge was not nearly as horrific as I had imagined. The night terrors ended after a few weeks, and my husband tells me the I’ve stopped mumbling in my sleep.

“Recursion. Don’t eat me. You can have the Rspec. Arrays and polymorphism. Hide the children.”

Because the goal of a coding challenge is to see how a developer thinks, the interviewer is supposed to be quiet while the programmer is supposed to talk out loud about what they are thinking.

It’s kind of like practicing a speech in the mirror, only it’s a double-sided mirror, and the person on the other side gets to decide if you get a job. And you’re in your underwear.

I have been told the underwear part is optional, but being inappropriately dressed makes me feel more like a developer. Flannel pajama pants and a stained Metallica t-shirt also do the trick.

Throughout the entire coding exercise, I was distracted by thoughts like, “Wow, Julie. You are totally bombing this” and “Oh my God, did you really just say that out loud?” and “I’m sure he has interviewed pumpkins with a more intelligent approach to this problem.”

After enduring about 15 minutes of awkward one-sided conversation, I solved the problem. Or at least, I thought I had, but I wasn’t really sure because I had no way of checking my answer, and apparently the interviewer hadn’t worried about being able to check it either.

The whole point, apparently, was to prove that I could talk to myself while faking confidence.

After I finished, the first thing he said to me was, “Well, clearly you have skill.”

My immediate thought was “I do?” followed by “Oh, yeah…of course I do. I should pretend I knew that.”

Junior Developer Interview Questions

As I mentioned in my last post, I interviewed with a total of 4 companies before accepting my first job as a Junior Developer. I also spoke with several other companies that I’m not counting in my interview tally because the discussion never went far enough.

The interview experiences differed wildly from one company to another. Perhaps that’s the reason it’s so difficult to find information on what to expect from a Junior Developer interview: there is no standard experience.

Nonetheless, I wanted to give aspiring developers some insight into what my experiences were like, in the hopes of shedding some light on the mysterious vortex of misdirected energy and flying chairs that is commonly referred to as “the job hunt”.

Here are the answers to the questions that Me-From-2-Months-Ago would have loved to have asked Gainfully-Employed-as-a-Software-Developer-Me:

Q: What types of questions did the interviewers ask?

A: The questions were all over the place, but most of them fell into one of the following categories:

  1. Standard Interview Questions: All the same interview questions you hear from any other type of job, such as “Tell me about a time you had to deal with conflict at work. How did you handle it?” or “Why do you want to work for this company?”
  2. Overview of Skills Questions: “How well do you know Jquery?” or “Tell me about the project you enjoyed working on most.” or “How long have you been working with Ruby on Rails?”
  3. Definition of Terms Questions: “Tell me everything you know about Object Oriented Programming.” or “What is (insert term here)?” A few of the terms I was asked to define: Encapsulation, Polymorphism, MVC, Service Oriented Architecture, SOAP API, RESTful API, Anonymous Function. —> Before you panic and try to memorize every Computer Science term on the internet, please hear this advice: First, there is no way to prepare for all questions. Just make note of the questions you can’t answer and research them to be better prepared for the next interview. Second, if a potential employer fires too many of these questions at you and/or cannot handle the occasional response of ‘I’m not familiar with that. Would you mind telling me about it?’ this is a HUGE red flag that they are not equipped to mentor you and you should stay FAR, FAR AWAY. Asking 1 or 2 of these questions can be useful to gauge knowledge, but asking too many means they expect you to walk in fully trained and function as a Senior Developer with the pay of a Junior Developer. RUN.
  4. Code Problems: This is where they give you a relatively simple problem, such as FizzBuzz or a Project Euler problem and watch you solve or attempt to solve it. Some companies do this using a whiteboard and others use screen sharing. The important thing to know about these problems is that they are looking to see and HEAR your thought process. It is more about showing that you can think logically than showing that you can solve the problem. Make sure to talk out loud about what you are thinking, no matter how dumb that makes you feel. I was terrified of these problems until I actually faced one, and it was not nearly as frightening as I had imagined.
  5. Pair Programming Exercises: In my opinion, this is the best interview technique. This is where they pair you up with another programmer and you solve a coding problem together with the programmer. It helps them evaluate both your coding ability and your ability to work with others. It helps you evaluate whether your potential coworkers will be the kind of people you want to work with.

Q: How much knowledge will they expect me to have, and what specifically will they expect me to know?

A: Again, this was all over the place. Some companies seemed to think I was more than qualified for a Junior Developer position, while others didn’t take me seriously at all. Some managers clearly expected a Junior Developer to be knowledgable enough to be immediately productive, while others were looking for someone they could invest in and mentor.

At the beginning, after having one company try to steer me towards an Internship and a second steer me towards Project Management, I began to wonder if my skills were not sufficient for a Junior Developer position. I now understand that: 1) there is not a consistent, objective measure of what a Junior Developer should know, and 2) if a company likes you, they will try to fit you into whatever slot they have available, whether that is as a Junior Dev, an Intern or a Bathroom Attendant. The titles and associated pay that you will be offered are only very loosely correlated to your actual level of skill.

And now, at the risk of inciting a riot, here’s the one question everyone likes to dance around:

Q: How will being a woman affect my job search? Will it help or hurt?

A: YES. It will help and it will hurt. I have no doubt that being a woman gave me an edge with at least one company that was trying to improve their diversity. On the other hand, I am equally certain that at least one manager (and I suspect several others) did not take me seriously because I was a woman.

How do I know these things? Let’s just say, ‘A facial expression is worth a million words.’

I am also acutely aware that being a woman affects my communication style. I believe women have a greater tendency to downplay and/or underestimate their skills and are more open about discussing their flaws and mistakes.  Whether this is true for most women is debatable, but it is certainly true for me. In some cases this made me compare unfavorably with other developers who would state the exact same skill set in much less humble terms. In other cases, my communication style helped me because the managers were concerned less with (perceived) minor skill differences and more with the ability to play well with others.

On the whole, being a woman had a polarizing effect. Sometimes it really helped and other times it really hurt. In a field that is only 5-8% female, it often made me stick out, which could be good or bad depending on how well I handled the spotlight.

I would suspect that anyone who does not fit the stereotype, whether because of gender, race, disability or some other factor, might experience a similar effect.

The negatives and positives balanced each other out for the most part, but I did gain one clear advantage: it made weeding out the asshole managers 10 times easier. In fact, they graciously weeded themselves out. Perhaps I should send them a thank you note. (wink)

The Job Search Story

I’ve been promising to recap my job search, so here it goes:

It’s no secret that I was not the strongest coder in my class. Several of the students came in with prior coding experience, and others came in with years of experience working in the tech field, or with degrees in Computer Science or Math.

I also had restrictions on the jobs that I could accept. With a family, I could not accept a job at a start-up that didn’t offer benefits or expected me to work 80 hours per week. I also couldn’t accept a low-paying job in order to get my foot in the door, since I already had a decent job and couldn’t afford to lose income.

For those reasons, I suspected that I might be one of the last to find work. I thought it might take 4-6 months to find a job that fit my needs.

The reality was quite the opposite of my expectations:

Within 1 month of graduation, I had interviewed with 4 companies, had an offer pending with 2 of them, and had received an excellent offer from the third–my ideal employer.

How did that happen?!!

It turns out that, just as in any other career path, the quality of your Job Hunting Skills is much more important than any other factor. Technical skills are important, but it all comes down to people.

Do the right people know who you are and what you do?

Long before I even started coding bootcamp, I began planting the seeds for a successful job search. Here are some of the steps I took that helped me get ahead:

Before Coding Bootcamp:

  • Started telling everyone I knew that I was studying to become a software engineer. I didn’t restrict it to the people who understood what I was talking about. When I was talking to someone who didn’t know anything about programming, I explained it in very simple terms. i.e. “The language I work with is called Ruby, like the red jewel.” I got an amazing number of friend-of-a-friend leads this way.

During Bootcamp

  • Updated my Linkedin profile with the skills I was learning (hint: Linkedin is not a good place to be humble.)
  • Created a Twitter account and followed local tech companies, Codenewbies, Tech News, and programmers I met at meetups. Made sure to keep my own tweets mostly professional while still being my crazy self.
  • Blogged regularly. Yes, this DOES help get your name out there and show potential employers who you are.
  • Updated my resume and had it ready to go as soon as I was ready to apply
  • Ordered business cards to have something tangible to give to anyone I met
  • Chatted up the employees and owners of the startups in our building, asking them questions about their company, how they got started, what technologies their products are built on, etc. I DID NOT ask them about working for them–the conversation was about them, not me. I had brief conversations with 50+ people whom I met in the hall, in the stairwell or in the break room.
  • I attended Meetups and tried to make personal connections. The key to making connections at an event is to take a risk and do something to stick out. It is uncomfortable and feels risky, but the point is to be remembered. Some of the strategic decisions I made: sitting at a different table than the other students so I would be remembered as an individual instead of part of a group, attending smaller meetings more than large ones, pairing with people I did not know instead of people I felt comfortable with during learning exercises, asking lots of questions in meetings.
  • Had an “informational interview” with a friend of a friend who was a Ruby on Rails developer. I asked him a million questions like, “What is a Junior Developer expected to know?” and “What are the best resources to develop my skills?” and “What can I expect in an interview?” I DID NOT ask him for job leads. That would have been asking too much of someone I did not know.
  • Volunteered for a Rails Girls event and gave a speech about my journey learning to code.
  • Practiced Project Euler problems and the famous “FizzBuzz” problem, which are commonly used in interviews.

After Bootcamp

  • By the time I graduated, I already had one interview lined up, which came from a recruiter I met at a Rails Girls meetup.
  • A second interview came from directly emailing 2 recruiters from the same large company. I got a response from one, and then a few days later, a response from the other. I sent them a custom cover letter with my resume attached and a link to my portfolio. Read this article to see how I found their direct email addresses: http://life-longlearner.com/find-email-addresses/
  • The third interview came from a friend-of-a-friend, who introduced me to one of his friends, who happened to be hiring. After the interview, he gave me a take-home coding challenge (a pull request on his company’s public Github account), which I completed. I was not able to solve the problem, but was able to demonstrate that I understood the problem and cared enough to try to solve it. I later learned that just taking the time to try to solve the problem is more than most people do, and they were impressed enough to want to hire me.
  • The last interview (which turned into my current job) came directly from a friend-of-a-friend.

You might be sensing a pattern here. Most of my job leads came from networking. In fact, during my job search I only put in one online application and only sent about 5 emails. In contrast, I would say I talked to nearly 100 people about my career goals. Some were short, elevator conversations and others were hour-long conversations. Most of the conversations produced no fruit, but the ones that did produced GIGANTIC, SWEET JUICY MANGOS.

I’ll write another post soon about the details of the interviews, but feel free to post any questions you have as a comment.

I’m Officially a Software Engineer!

Today I officially became a Software Engineer.

You might be thinking, “Wait a minute! I don’t remember you saying anything about a new job! How could you be so quiet about that when you blog about every other ridiculously minuscule event in your life?”

(sheepishly) Um, yes. Well, I might have been just a tad bit paranoid about making the announcement.

I just might have had thoughts like:

What if it turns out this is all a big joke, and I walk in to my first day of work just to have a Candid Camera crew jam a microphone in my face, tearing up from laughter as they ask me, “Did you REALLY believe you had become a Software Engineer? Truly?! That is just priceless!”

What if, when they run my background check, it turns out that I’m a sleepwalker and I’m wanted in 13 states and 2 distant continents for a rash of pillow-related crimes?

What if I’m innocent, but I have an evil twin with similar fingerprints, and it takes months to sort things out, by which time my entire family ends up living in a single cardboard box while we save up for a larger, refrigerator-sized box, and then the city floods and we end up homeless?

What if I am the margin of error on the drug test?

What if I only think I’m a US citizen, and really I’m from another country entirely, like Rhode Island or Jupiter?

What if I do have a job, but when I sit down at the computer and start coding, my skills are so pitiful that I get laughed out of the office, in my underwear?

Yes. In–my–UNDERWEAR. These things happen. True story.

I might just be a little crazy.

Then again, I might not be crazy, and might be exaggerating a smidge. If you happen to work with me, let’s go with that one.

Anyway, crazy or not, I am officially a Software Engineer! Job hunt story and first day story to follow.

How To Network Without Being a Douche

Try this exercise:

Stick your finger down your throat and try to find the exact point where you feel your uvula quivering, but don’t actually gag.


If you look like this, you’ve gone too far.


Got it?


Remember that feeling. That’s exactly what effective networking feels like.

If you believe the statistics, 70% of jobs are filled through networking. Even if you believe that the statistics are only loosely based on truth, it’s still hard to dispute that networking–done properly–is one of the most effective strategies for job hunters.

So, why don’t we spend more time networking?

Because it makes us feel like a Giant Douche.


With that in mind, here are some tips for Douche-Free Networking:

1. Find Your Almost-Gagging Point:

If you don’t feel like you’re going to gag, you’re not trying hard enough. If you actually gag, you’re trying too hard. It’s a delicate balance, and the Gag-point is different for everyone.

My Gag-Progression Looks Like This:

No Urge to Gag: Chatting with the person next to me at a small networking event.

Gagging: Mingling in a networking event of more than 20 people.

Uvula (Sweet Spot): Mingling in a networking event of less than 20 people.

The only way to find the right balance is to keep trying progressively harder types of networking, reach your Gag Point, and then take a step back. You’ll notice that the more you complete your “Uvula Challenges”, the farther you’ll have to reach to hit your Gag Point.

2. Make it About Them, Not About You

Everyone worries about coming off as a Douche when they’re talking to someone they don’t know.

You can stop worrying about that as long as you do this one thing: talk about them, not about you. Everyone loves to talk about themselves, and you will always make a favorable impression if you keep the conversation centered on things that they are interested in.

How do you know what they’re interested in? …

3. Look for Clues and Ask Questions

To the guy who’s wearing a Cubs hat: “How are the Cubs doing this season? Are you from…whatever state the Cubs are from?” (Just kidding, I’m not that hopeless. I have Google.)

To the guy who has a giant green Praying Mantis sticker on his laptop: “Are you an entomologist or is that your favorite band?”

To the wild-eyed lady with a line of lipstick streaked across her face: “How old are your kids?”

Whatever you do, just don’t ask what they do for a living or where they work. That has the feel of “Let me see if you are a worth-while human being before I get too far into this conversation.” It also triggers a really awkward silence if they:

a) are a rocket scientist or

b) spend their days wading through sewage in a rubber jump-suit

Don’t go there until you know them reasonably well.

4. Let Them Teach You Something

The fear of looking stupid is responsible for 99.9% of all cases of actually looking stupid.

Sitting at a conference, we’re afraid to ask the speaker, or the person next to us, a question because it might make us look stupid.

We are forgetting that everyone on the planet is too self-absorbed to notice if we’re stupid. They only care about whether they are stupid.

So, you ask a question.

What you think the speaker will remember: “John is so dumb, he doesn’t even know what septuplet means.”

What the speaker actually remembers: “John made me feel smart. I like John.”

5. Network When You Don’t Need To

Networking is actually most effective when you don’t need it. Why? Because people can smell desperation, and it doesn’t smell like flowers.

I know. That really sucks if you needed a job yesterday, but the good news is, you can keep yourself from being in that situation tomorrow. If you are looking for a job, don’t let that be your excuse to put off networking until later. There’s a good chance you’ll get an immediate payoff, but your odds for long-term benefits are truly excellent.

The most effective networking tactic is not a tactic at all: Just help other people when they need help.

If you help someone when they need help, they will mysteriously appear and wave a magic wand when you need help. If they don’t, someone else will. You can call it Karma if you want to. I call it “being the kind of person that other people want to help”.


Congratulations! Now you know how to Network Without Being a Douche! Go out into the world and find your Gag Point!

First Mini-Interview

The other day, my teacher announced that a company in the building may be looking for a Junior Developer, and we should make an effort to stop by to introduce ourselves.

The class collectively recoiled and hissed.

“I have some fingers I’m not really attached to. Could I just chop one of those off instead?”

As if job hunting and networking weren’t already painful enough, as a new developer, you are absolutely guaranteed to get questions that make you feel like a moron.

Perhaps that’s why most, if not all, of the other students nodded their heads and then deleted the suggestion from memory. I can’t say I blame them.

I did manage to drag myself to the company’s office and ask for the lead developer.

Thinking he’d probably be too busy to spend much time with me, I prepared only for a quick conversation:

“Hi, I’m Julie, and you probably don’t care, but now you have seen my face and hopefully it will trigger a foggy memory a few weeks from now when I’m closer to graduation.”

What happened instead was that right there, on the edge of a large room packed with maybe 15 employees, he started to ask me some basic interview questions.

For me, the defining feeling of being interviewed is the sense that my brain and mouth have been forcibly separated. Time seems to slow down as my brain processes questions first as a query to my inner monologue, and second as data that is appropriate to be uttered out loud.

The questions went something like this:

Him: “What is your favorite thing about Ruby?”

Brain: “It’s not Javascript.”

Mouth: “I like the flexibility of the language.”

Him: “But what about something more specific?”

Brain: “It’s not Javascript. It’s not Javascript. It’s not Javascript. Need to be more specific….. It’s not Javascript.”

Mouth: Something random about hashes.

Him: Thoughtful silence.

Brain: “Okay, shut about up about Javascript for a second, and think. ‘How floating point numbers are handled?’ No, that’s what I hate. What’s something I like? ‘Ooh! I know! It’s not Javascript!’ Come on, brain! Focus!”

Mouth: Something random about if-then statements.

Brain: “Nice one, mouth. Should have gone with Javascript.”

Him: “On a scale of 1 to 10, ten being the highest, how would you rate your skill with Ruby?”

Brain: “As compared to who? My fellow students? Yukihiro Matsumoto? The average person on the street? Let’s see…. We’re looking for an integer between 1 and 10 that is roughly equivalent to what I think of my Ruby skills.

Okay, got it. No—–wait—–you always underestimate yourself….Here, try this:

i = best_estimate_of_ability

i += 2

Okay, go for it, mouth.

Mouth: “An eight!”

Brain: “Nooooooooo! Did you just say eight? What were you thinking? How did you come up with an eight? Oh, there’s the problem. You did

i *= 2.

Nice job there, genius.”

Mouth: “Yeah, definitely an eight.”

After a few moments, he told me they were pretty full right now ( brain: “Shot down!”) but I was welcome to send him some code samples (brain: OMG, my Github is a disaster right now.)

As I walked back to my classroom, my brain and mouth took one more accusing look at each other and then re-merged.

I hadn’t intended to tell the other students about the about the experience, but my filter was exhausted, and I ended up spewing out a recap immediately.

Brain and Mouth as Joint Entity: “I just talked to (the company). I think I’m going to vomit.”

Friend From Class: “Wow, you have more balls than the rest of us.”

“Yeah, I have some artificial ones I keep in my pocket. They’re more durable than the real ones.”

“Wow, that’s awkward.”


In case you wondered, I am going to email him a code sample.

I’m also sending him a link to this post.

He will either think I’m crazy and write me off immediately, or think I’m crazy and be curious as to just how crazy.

Either way, it should make me kind of hard to forget, and in job hunting, that’s half the battle.