Archive for the ‘Fog Creek’ Category

How Fog Creek Got Started

November 20th, 2014 by Gareth Wilson

Starting out as a consulting company in 2000, Fog Creek was founded with the goal of creating the best place for developers to work. The video covers the early years of Fog Creek. Hear from our founders, Joel Spolsky and Michael Pryor, how they navigated the Dot-com crash and bootstrapped the company in to a growing, product-based business.

Effective Code Reviews – 9 Tips from a Converted Skeptic

November 17th, 2014 by Gareth Wilson

I knew the theory. Code reviews help to:

  • Catch bugs
  • Ensure code is readable and maintainable
  • Spread knowledge of the code base throughout the team
  • Get new people up to speed with the ways of working
  • Expose everyone to different approaches

Or, they’re just a giant waste of time. At least, that was my first impression of code reviews.

I was the new guy, a recent grad, developing plugins for a software company in London.

Over time I had to submit blocks of identical or similar code. They would get reviewed by the same poor, put upon guy (“he’s the best at it” my manager told me. No good deed…). Yet each review would come back picking at something different. It seemed needlessly picky and arbitrary.

Worse still, reviews would take days, if not weeks. By the time I got my code back I could hardly remember writing it. It wasn’t the guy’s fault. He’d asked for a senior dev, but had gotten me. He was sick of dealing with the issues every inexperienced developer makes, and code reviews were his way of exorcising that frustration.

Add to this the time lost in syncing the different branches, the context-switching… I was not a fan, nor were the rest of the team and it showed.

Skip forward a few years though and I find myself nodding along whilst reading a tweet quoting Jeff Atwood:

“Peer code reviews are the single biggest thing you can do to improve your code.”

What I had come to appreciate in the intervening years is that it wasn’t that code reviews were bad. Code reviews done badly were. And boy, had we been doing them badly.

I had learned this the hard way. And it certainly didn’t happen over night. Although on reflection, code reviews have saved me from more than a few embarrassing, build-breaking code changes! But after I had worked elsewhere, I gained experience of different and better ways of working. This gave me opportunity to see first-hand the benefits of code reviews that I had dismissed before. So now I consider myself a converted skeptic.

So that you can avoid such pains, check out our video and then read on for tips that will skip you straight to effective code reviews.

9 Code Review Tips

For everyone:

  • Review the right things, let tools to do the rest

    You don’t need to argue over code style and formatting issues. There are plenty of tools which can consistently highlight those things. Ensuring that the code is correct, understandable and maintainable is what’s important. Sure, style and formatting form part of that, but you should let the tool be the one to point out those things.

  • Everyone should code review

    Some people are better at it than others. The more experienced may well spot more bugs, and that’s important. But more important is maintaining a positive attitude to code review in general and that means avoiding any ‘Us vs. Them’ attitude, or making reviewing code burdensome for someone.

  • Review all code

    No code is too short or too simple. If you review everything then nothing gets missed. What’s more, it makes it part of the process, a habit and not an after thought.

  • Adopt a positive attitude

    This is just as important for reviewers as well as submitters. Code reviews are not the time to get all alpha and exert your coding prowess. Nor do you need to get defensive. Go in to it with a positive attitude of constructive criticism and you can build trust around the process.

For reviewers:


  • Code review often and for short sessions

    The effectiveness of your reviews decreases after around an hour. So putting off reviews and doing them in one almighty session doesn’t help anybody. Set aside time throughout your day to coincide with breaks, so as not to disrupt your own flow and help form a habit. Your colleagues will thank you for it. Waiting can be frustrating and they can resolve issues quicker whilst the code is still fresh in their heads.

  • It’s OK to say “It’s all good”

    Don’t get picky, you don’t have to find an issue in every review.

  • Use a checklist

    Checklists ensure consistency – they make sure everyone is covering what’s important and common mistakes.

For submitters:

  • Keep the code short

    Beyond 200 lines and the effectiveness of a review drops significantly. By the time you’re at more than 400 they become almost pointless.

  • Provide context

    Link to any related tickets, or the spec. There are code review tools like Kiln that can help with that. Provide short, but useful commit messages and plenty of comments throughout your code. It’ll help the reviewer and you’ll get fewer issues coming back.


Register Now for ‘Code Reviews in Kiln’ Webinar

Join us this Thursday, November 20th at 1:00 PM – 1:30 PM EST for our ‘Code Reviews in Kiln’ webinar. This webinar will help first time or novice users learn the basics of Code Reviews in Kiln.

We’ll cover:

  • What are Code Reviews
  • Why use Code Reviews
  • When use Code Reviews
  • What to look for during Code Reviews
  • Creating a Code Review
  • Commenting and Replying on a Code Review
  • Code Review Workflow

Secure your spot, register now.

Scaling Customer Service by Fixing Things Twice

November 10th, 2014 by Gareth Wilson

As a bootstrapped company we’ve always had to work within a budget and avoid unnecessary costs without harming our mission. One area that has the potential for suffering in the face of limited budgets is Customer Service. When a company is growing, customer service can suffer or it can grow to consume a considerable amount of your budget. We’ve been able to grow our customer base by more than 10 times, maintaining a high level of customer service while keeping our support costs manageable.

How? By Fixing Things Twice using the 5 Whys.

Check out the video and read more about how these techniques can help you scale customer service without the cost.

Fixing Things Twice

When a customer has a problem, don’t simply resolve their issue and move on – but rather take advantage of the issue to resolve its underlying cause. This is Fixing Things Twice.

We think that for each customer issue, we have to do two things:
1. Solve the customer’s problem right away
2. Find a way to stop that problem from happening again

How we solve the first depends on the specific problem at hand, but to resolve the second we use the 5 Whys method.

Resolving Root Causes with 5 Whys

The 5 Whys is a problem-solving method and form of root-cause analysis. It involves recursively asking the question ‘why?’ five times when faced with an issue. Doing so enables you to get to the bottom of it, allowing you to fix and stop it from happening again.

Just ask why

This technique was recently popularized by Eric Ries in his book ‘The Lean Startup’. Yet it was developed by Sakichi Toyoda in the late eighties at Toyota. Over the years its use has spread beyond the motor industry to software development and other areas such as finance and medicine. It’s a recommended technique used by the UK’s National Health Service for example.

Lets take a look at how it works using a hypothetical situation:

  • The initial problem – The machine won’t start
  • 1st Why? – There’s no power
  • 2nd Why? – The power supply is not working
  • 3rd Why? – The capacitor has broken
  • 4th Why? – The capacitor was old but had not been replaced
  • 5th Why? – There’s no schedule to check for ageing parts in the power supply units. This is the root cause.

This technique is especially useful when you’re able to focus on processes as causes, like in the example above. Whilst other factors like time, money and resources might play their part, they’re beyond our immediate control. 5 Whys quickly exposes the relationship between the various causes of a problem – yet it does not require any analysis tools. This means it can be adopted and applied throughout an organization. We’ve extended its use beyond Support to include System Administration too. Watch the video above to see an example.

What does Fixing Things Twice mean for Support?

Here’s a couple of examples of using Fixing Things Twice provided by Adam Wishneusky, Technical Support Engineer here at Fog Creek:

When we had people asking a lot about our security practices. We fixed the problem once by giving the customer an answer. Then fixed it twice by putting up public docs at

Another example from a few years ago, is when we found that FogBugz wouldn’t let you create a new LDAP-authenticated user if one already existed in the database with the same LDAP UID even though that user is deleted. We showed customers how to manually fix the data to get them working, but we also pushed the dev team to fix the bug.

support and development
From this example you can see that Support must have access to the Development team. It’s often the only way the underlying issues will get fixed.

It takes commitment too – it’s easy to skip the second fix and it’s tempting to do so as it means spending more time on any one issue. But it’s a false economy to do so. When the issue crops up again and again, you’ll have to spend even more time on it.

If you stick to Fixing Things Twice then over time all the common problems get resolved. This frees up your Customer Service team to look in to the unique issues that need more time. Resolving your most frequent issues overcomes the support overhead that typically comes with adding new customers.

The Only Three Types of Meeting You Should Hold

November 6th, 2014 by Gareth Wilson

A perennial problem within software development teams is communication. Making a software company fast, nimble and effective is a function of reducing the amount of communication that takes place to a minimum. This means finding the right balance. Too much and you can’t get any work done, too little and no-one knows what to do or it’s un-coordinated.

Meetings, in particular, can be a real time sink. So to keep the balance right we actively try and reduce the number we hold. There’s only three types of meetings that work for us:

1) Mass Communication Meetings

These are meetings where you have a lot of information to communicate to a large group of people. After all, you don’t just want to send some epic email opus that no-one will read (Sorry Satya!). We have a regular ‘Town Hall’ meeting for example. In these we all come together, both office and remote staff, in the cafeteria and via video link. We hear about some pre-planned topics, suggested and organized in a Trello board. These work well because everyone hears the same thing and they only cover issues relevant to everybody.

2) Brain-storming Meetings

We use these when we just want to come up with a lot of ideas, fast. They aren’t great for discussing the ideas in detail, but can work for pure idea generation.

3) Stand-up Meetings

These are great for keeping teams on track, by providing a brief update on what you did, what you’re working on and flagging up any blockers to progress. These are especially useful in remote teams, by bringing people together you help to form that team bond. It’s important to keep them focussed though, so we’re strict and avoid over-runs and people going off-topic.

“If you have a meeting with 8 people in the room that lasts an hour, that’s a day of productivity that was lost” Joel Spolsky

And that’s it. For all others we find a more effective alternative. That might mean linking up with people on chat, ad-hoc conversations via Hangout and through extensive use of collaborative software, like FogBugz, via cases, discussion groups and the Wiki. We never use a meeting for example, when we’re trying to solve a difficult problem. Getting people together in a room just means that no-one can think things through properly. They might generate a lot of discussion, but lead to few real conclusions.

When we do have a meeting, we also limit the number of people invited to just the ones that have to be there. Those with only some relevance can catch up with the minutes added to the Wiki at a time that suits them.

We’ve found that sticking to this really saves us time. What ways have you found to minimize communication overhead? Tweet them to @fogcreek and we’ll retweet the best ones.

Improve Your Culture with these Team Lunch Tips from 20 Startups

November 4th, 2014 by Gareth Wilson

Fogcreek Team Lunch
The importance of eating together has long been recognized in positive child development and strengthening family bonds. Eating together is a great equalizer and it can be a good way to help form better and more valuable relationships amongst teams of co-workers too.

Daily Team Lunches

We swear by daily team lunches here at Fog Creek. Having stumbled across their positive impact at Microsoft, Joel Spolsky, one of our co-founders, has said that whilst “there’s a lot of stuff that’s accidental about Fog Creek… lunch is not one of them… The importance of eating together with your co-workers is not negotiable, to me.”


I’m similarly enthusiastic having seen the benefits myself whilst working in Support at a previous company. In my role, I was the bearer of bad news to the Development team – sending and escalating the bugs raised by customers. I had little interaction with the team beyond raising bugs, so forming positive working relationships with its members could be tough. But this was no longer an issue once we started having team lunches. They were a great way for people from different functional areas of the company to come together. We’d chat about both work and non-work stuff, and it meant that we could get to know each other as people and not just colleagues.

Long lunch tables
At Fog Creek, we deliberately have rows of long tables in our cafeteria. Having round tables means that when looking for a place to sit, you have to pick a group of people. But with long ones you just go and sit at the end of the row. You end up speaking to different people every day, helping to avoid cliques. It’s good for new hires too – they don’t have to sit alone or force themselves upon an unfamiliar group.

Like StumbleUpon, AirBnB, Eventbrite and others, we have lunch catered. It’s served up at the same time every day so everyone knows when there will be people around to go eat with. For the foodies amongst you, we share photos of some of the tasty dishes on our Facebook page.


Others, like MemSQL and Softwire have hired in their own chefs. And of course there’s the likes of Facebook, with their own on-site Pizza place, Burger bar and Patisserie, and Fab, who have their Meatball Shop and Dinosaur Bar-B-Que.

It Doesn’t Need to be Expensive

It doesn’t need to be expensive though – you don’t have to provide the food, people can bring their own lunch. The important part is the set time and place to eat together. Make them optional, so that people don’t feel obligated and can get on with critical work if need be.

If space is a problem, then eat out. A group at Chartio for example, eat together at a different place in San Francisco every day.

Can’t do it every day? No problem. Take Huddle, they have a team lunch once a week. FreeAgent do too and they keep things interesting by picking a different cuisine from around the world each time.


Stay Productive

TaskRabbit, Softwire and have their ‘Lunch and Learn’ sessions. One team member presents on a particular topic of interest, whilst the rest munch away. Twilio use their team lunches for onboarding new hires, who demo a creation using their API to colleagues in their first week.

Small Groups or the Whole Team

It doesn’t have to be the whole team either. Warby Parker for example has a weekly “lunch roulette,” where two groups of team members go out and share a meal. HubSpot allow any employee “to take someone out for a meal that they feel they can learn from”.

Get Creative!

There are many creative ideas, too. Shoptiques provides lunch with its Book Club, LinkedIn gets in food trucks every Friday, and GoodbyeCrutches have themed lunches – “Jimmy
Buffet Day, Smurf Day, and Pirate Day” being amongst their favorites.

No Excuses

You don’t even need to be in the same country! oDesk hold virtual team lunches where its employees from the US, Russia, Brazil and India gather together and eat whilst on a Hangout.

So there you go, there’s no excuse to have another sad lunch, sat alone at your desk reading some random blog post…

How have you improved team culture at your work place? Tweet your tips to @fogcreek and we’ll re-tweet the best ones.

Sysadmin Hiring at Fog Creek

November 3rd, 2014 by Mendy Berkowitz

Here at Fog Creek we’ve spent a lot of time honing our recruiting processes. From writing the book on technical recruiting to dealing with masses of resumes. Recruiting is woven into the fabric of our company.

Our task-oriented interviewing style works for technical and non-technical positions alike, but for all the ink we’ve spilled about recruiting and interviewing, you’ll notice it is mostly focused on developers.

Interviewing developers, hiring developers, helping developers create awesome software; one might get the wrong impression that Fog Creek was composed solely of developers. And we all know this isn’t true. We have a diversity of skill sets here at Fog Creek and while we mostly hire developers, some of the other recent job listings have been for sysadmins/devops, support engineers, designers, sales, product marketing managers, accountants and receptionists.

As a member of the sysadmin team, I wanted to add some more ink to how we approach hiring sysadmins here at Fog Creek. (I’m using the term System Administrator because that is what I was called when I started my career. At Fog Creek our team responsibilities are some amalgamation of what is colloquially called SRE or DevOps or Sysadmin.)

What are we looking for in a sysadmin?

Hiring DevOps
Many of the principles of the recruiting process are the same, but the responsibilities of a developer and a sysadmin are somewhat different. Here are some of the things we are looking for when hiring sysadmins.

  • Ownership: If something is broken, fix it. We are a small company and ‘the buck stops here’. There are no other teams we can blame or foist problems on.
  • Can operate independently: We don’t believe in micro management. We need people who can take a high level task and self manage their way to completion with minimal oversight.
  • Find and Solve problems: We have a term we’re rather fond of, “Fix it Twice“. Reacting to problems after they occur is an important skill, but we must think of ways to fix things so the problem doesn’t happen again.
  • Create reasoned architectures: We aren’t biased towards any particular technology. We want to use the best tool for the job. This requires us to evaluate the pros and cons of the latest and greatest while being familiar with the old standbys.
  • Ultimately smart and gets things done.

Our Interview Process

Our interview scheme has three parts:

  • Sorting
  • Screening
  • Interviewing


Sorting through resumes and candidates can be time consuming. I wish there was a hat to help us as we spend a couple of minutes per applicant and look for the following markers:

  • Can they write well?
  • Did they read the job posting?
  • Have they worked on tough problems?
  • Did they introduce something at work?
  • Are they passionate about technology?
  • Did they work on something that requires in-depth knowledge of the subject?
  • Do they have experience with high pressure incidents or high risk decisions?

Most of these questions are subjective. This part of the process is just to separate the blatantly unqualified or obviously disinterested. I can’t stress how important the cover letter can be in the overall process. A boilerplate “Dear Sir or Madam” letter won’t catch anyone’s eye. Referring to the job description, showing an interest in our company, showing you are just as invested in this process as we are, these are ways to stand out and make people interested in talking to you.


The next part of the processes is screening. Before we invest in a full day of interviews we conduct phone and code screens.

First, we’ll have a phone conversation with the applicant. As much as we would all love to just interact with machines most sysadmins also have to interact with people.

  • Can they carry on a conversation?
  • Can they explain what they are working on and why it is (or isn’t) important?
  • Can they take a piece of technology or an interaction that they use every day and explain the technical guts that make it work?

After the phone screen we’ll send the applicant a “take home problem” that involves solving a real world log analysis problem. The only real constraint we give is time. We provide the candidate a relatively small log file, and explanation of the format and the context of the log file. They have 24 hours from their chosen start-time to come up with a solution and send us their answer and their code. It shouldn’t matter if they send the solution in 5 minutes or 23 hours and 59 minutes. We look to see if we can understand their code, whether it works, and if it returns the correct result.


This is most common and often most difficult part of the process. You can find plenty of articles about interview questions, but we wanted ours to be as close as possible to the situations we find ourselves dealing with everyday. In the end you are hiring someone to be on your team. That means they will be doing the same types of tasks as you are doing. We tried to find generic examples of those tasks and observe how the candidate acts while performing them.

In general, a candidate will talk to five people:

  • The first interview focuses on architecture. The goal is to get them to whiteboard as much as possible. Can they plan out an architecture to solve a problem. Do they cover the components that are needed to support that architecture?
  • Second, we talk about troubleshooting. Can they figure out what is wrong (and fix it)? Can they figure out what is causing the system problem? Can they then write customer communication explaining the problem and what will be done to fix it in the future.
  • The third interview challenges them with learning through implementation. We are always interacting with new technologies. Given a pre-designed system, can they build it even if they aren’t familiar with all the components?. How do they approach things they don’t know and learn about them?
  • In the fourth interview they’ll talk to a real live developer in its native habitat. We interact with our developers and support engineers every day. Can they interact with our developers? Can they have a constructive conversation with them about code and ideas?
  • Lastly you’ll have a chat with our founders.

There you have it. This is the process we’ve been using to hire sysadmins at Fog Creek. Think you can make it through this process? Want to work in a great company with awesome people? We’re hiring!

How to Get Started –and Stick with– Usability Testing

October 27th, 2014 by Gareth Wilson

As you’re working on a piece of software, you get to know it well. Perhaps too well. How to complete common actions become so obvious to you that you don’t need to think about them any more. This isn’t the case though when someone new comes to use your product. So getting your product in to the hands of users to test is a key step in its development. But of course, you already know this. Almost everybody does. Yet few people get around to actually doing it, and those that do, often stop after an initial release or phase.

Check out the video below featuring usability expert and author of “Don’t Make Me Think”, Steve Krug. Then read on for tips to help you get started, and stick with, usability testing.

Usability Testing doesn’t have to be complicated

Keep it simple
Usability testing doesn’t have to be complicated. Upon hearing the term ‘usability testing’, you might begin to imagine a testing lab, with cameras setup to film eyes, face, clicks and the screen. But it doesn’t need to be like this. All you really need is to find someone, provide something to test and a place to do it.

Take anyone you can get
Test participants don’t need to be familiar with your product. They don’t even have to be from your target audience. So grab a colleague (in our video we roped-in our Office Manager), a friend or anyone else who is around.

You don’t need hordes of people either. In fact, there’s little benefit in testing with more than 5 people.

Test early
You don’t need to have built something to begin user testing. Some sketches, linked screenshots or a simple prototype will do. The earlier you start the better, so you can avoid building unnecessary stuff later. A paper prototype can be enough to begin and start getting useful feedback.

Don’t get caught up with design preferences and feature requests
Your testers come with pre-conceived ideas of what’s expected of them. Most common is the idea that you’re after design feedback, in particular colors. Layout and design issues are important, but things like color are rarely your major problem. Unless people have a strong reaction (using words like “puke”), it’s often safe to ignore such feedback. Same goes with feature requests. You will already have loads of your own. So unless their idea immediately makes sense to all, you can skip these too.

Start with a few theories
Generate a few theories about why something important is happening. Such as why users aren’t converting, not using a particular feature or how they might complete a particular task. Think of a scenario to test this, and then run that test. After each test, debrief – discuss amongst you what you observed and why that might be.

Test once a month
Once you have carried out a test, make some changes, create more theories and set about testing them too. It doesn’t need to be too often – just one morning, once a month. This will provide a constant flow of feedback that will keep you on top of your major issues.

Once you’re in to it, use tools to help
There’s a bunch of useful tools which can help you with usability testing. Use Five Second Test to get quick feedback on UI, web pages and sketches. InVision for creating prototypes. LookBack (mobile) and SilverbackApp (desktop) to get in-app user-feedback.

If you try out these tips then there’s really no barrier to you starting and sticking with usability testing. Don’t forget to check out the video above to hear more on usability testing from Steve Krug and some of the Creekers.

7 Ways to Get More Out of Beta Testing

October 23rd, 2014 by Gareth Wilson

The weird and wonderful bugs that get thrown up when real users first start using your code never ceases to amaze. There’s always some odd edge case that had been overlooked, despite you having thought about little else for several weeks. We’ve been through this many times whilst developing FogBugz, Kiln and Trello. Beta testing is an important stage in the testing process. To learn a little about them check out the following video, then read on for our key tips:



Here’s 7 things you can do to get the most out of our your beta tests.

1. Ask for a commitment to provide feedback
Response rates will be higher if you ask your beta testers upfront to commit to providing feedback. This doesn’t have to be formal, just part of an application form. But having agreed to it, people are more likely to follow through.

2. Do not release with known bugs
Most beta testers will only provide feedback once. So you don’t want to burn any tester to just hear about known issues.

3. Allow enough time
Use the following as a rough guide. For a major development effort, say about a year’s work, then you’ll want 10-12 weeks for beta testing. Decrease as necessary – so if it took a month to develop, then around a week will suffice.

4. Be feature complete
Only beta test when you’re feature complete. Adding in things as you go sets you back to the start. Otherwise, it just means the new code and its impact on existing functionality isn’t as well tested as the rest. Something you’ll regret later.

5. Make it easy to get in touch
You want to make it as easy as possible for your beta testers to provide feedback, so give them direct emails and offer to jump on a Hangout/Skype if they’d prefer.

6. Remind, but don’t annoy
Whilst your product might be front and center for you, it’s not going to be that way for your beta testers. You’ll want to remind them along the way. But don’t over do it, they’re helping you out so you don’t want to annoy them with too many emails.

7. Don’t forget to provide feedback
Make sure during and after the test that you send them updates about how you are putting their feedback to use. People like to hear that their time wasn’t wasted. And don’t be tight with the swag – a free t-shirt can do wonders!

To learn more about beta testing be sure to check out the video above.

Announcing The Fog Creek Fellowship

July 21st, 2014 by Elizabeth Hall

The tech industry has a problem and Fog Creek shares it. Our small thirty-nine person company has eleven developers — all of them male — and only 14% of the technical applicants we have spoken to in the last six months have been women. We have extremely talented women working in various roles such as quality assurance, scrum master, finance, recruiting, and office management but no developers. We’re proud to have had (and currently have) truly amazing female developer interns. Their contributions to the team and company at large are apparent, but alas, we have none working with us full-time.

Everyone here at Fog Creek wants to help reverse this gender disparity. In the past, we’ve focused on our intern pipeline by recruiting heavily from schools with high percentages of female students. We’ve hosted and sponsored hackathons and events with a focus on women in tech. We provide continuing education programs for female employees who want to learn how to code. These efforts have helped some, but it’s not enough.

We want to do more. We need to do more. We will do more.

As part of a larger solution we’ve joined forces with our neighbor, The Flatiron School to create The Fog Creek Fellowship. The Flatiron School has an unprecedented commitment to diversity, training women and underrepresented groups through partnerships with government and self-funded scholarships. Their highly selective admissions process, their focus on incredible teachers and great curriculum, and their dedication to the programming community, have led to an exceptional track record of helping alumni launch programming careers with great companies. Their passion for providing women the skills they need to succeed in tech is contagious — making them the obvious choice for our partnership.

Fog Creek wants to keep The Flatiron School’s positive momentum going. A select group of female Flatiron School graduates will join us for a two month program where they’ll be paired with a Fog Creek or Trello mentor. The program kicks off with brainstorming breakfast where fellows arrive with three project ideas. Once they flesh out the details with their mentors they’ll begin working right away. Throughout the program they’ll also undergo technical interview training from our developers.

Fellows will experience what it’s like to work at a company that values developers. They’ll each have access to their own height adjustable desk, Aeron chair and all the snacks one can imagine.

Fellows will receive interview training from their mentors and be provided with immediate technical feedback, which is extremely rare in an interview setting. Our developers undergo months-long recruiting training and have conducted hundreds of coding phone and in-person interviews. They have priceless information to share with our fellows.

Fog Creek values the camaraderie and closeness that eating lunch together provides. Every day, fellows will either join the Fog Creek and Trello employees for a catered lunch or have a special 1:1 lunch with their mentors. Participating in these conversations, or just listening in, is a great way to dive into the tech community and continue learning.

Additionally, all fellows will have 1:1 pair programming sessions with their mentors. Fog Creek currently has a 0.4% acceptance rate for full-time developers; The fellows will be working with the best in the industry.

The Fog Creek Fellowship provides women, who have just learned a new skill-set and are eager to start their career in tech, the tools they need to get their first programing job. If we can help fellows prepare for coding interviews, offer assistance comparing offer packages, build confidence, and help create a long-lasting professional relationships with their mentors then we’ve done our job. We want to be a resource long past the program’s end date.

We are beyond excited to start this new endeavor and we hope it brings change to not just Fog Creek but to the tech community at large.

The Fog Creek Fellowship is only the beginning though; we know we have more to do. We are currently working with other amazing organizations in the industry to help all underrepresented groups in tech. Future exciting announcements to come!

* * *

Do you know of other organizations, schools, or people advocating for underrepresented groups in tech? I’d love to learn more, tell me about them!

Eight Jackalopes Walk Into An Office

July 9th, 2014 by Elizabeth Hall

Intern Group Final

As always, our interns are working on real features for our real products and have already made tremendous contributions to the Trello and FogBugz teams. We think they’re pretty special – not only did they stand out amongst the 776 applications we received but during these first few weeks they’ve had the chance to teach us a thing or two. Whether it’s coming up with new strategies for dealing with the Tanner during Werewolf or showing off cool video games they’ve made at hackathons, the class of 2014 is constantly impressing us.

Before we blink and it’s all over we want to take a moment to show off this year’s amazing talent. Here they are our eight wonderful interns (lovingly dubbed jackalopes*) in their own words.

Alex Lew

Hi! My name’s Alex, and I’m an intern on the Platform team this summer. Obligatory fun fact: I grew up in North Carolina, and my high school’s library had the largest collection of books and music in and about Esperanto of any library in the United States (excepting the Library of Congress).

Laura Watiker

My name’s Laura and I’m working on the Trello team this summer. During the school year, I go to Oberlin College in Ohio, studying CS and Econ. I grew up in the New York City suburbs, but I’m happily living in the Brooklyn housing this summer. Aside from pushing lots of computer keys, I do work with Oberlin’s co-ops, play a bunch of instruments, and theorize 2048 strategy.

Graham Carling

My name is Graham, I just finished my Sophomore year at Brown. I am originally from Manhattan and a graduate of Stuyvesant high school, a short walk from the Fog Creek offices. I am majoring in Computer Science (I know, shocking) and for the last couple semesters I have been working as a TA for some of Brown’s CS classes. Outside of work I like going to concerts, mainly of the electronic variety, along with seeing my friends from high school and working on a side project of mine. So far my summer has been packed full of fun events, and when I’m not going fishing or shooting arrows I’ve been working on the new notification center feature for FogBugz.

Jonathan Pevarnek
Hello, I’m Jonathan, a masters student in Computer Science at the University of Michigan. I’m from a small island called Grosse Ile in south-east Michigan. When I’m not working, I like to read books, go on bike rides, and work with a campus community service organization (Circle K). This summer, I’ve mainly been working with Doug to extend Trello email integration.

Matthew Hayes

I am Matthew Hayes, from Syosset, Long Island, NY. I just finished my junior year as a CS major at Cornell University upstate in Ithaca, and will be working on a FogBugz activity feed this summer. Fun fact: I caught the biggest fish on this year’s fishing trip (evidence below).

Peter Johnson

My name’s Peter, and I’m working on adding saved searches and list sorting to Trello this summer. I just finished my junior year at William & Mary in Virginia, and in my free time I enjoy running long distances and playing Dots!

Steven Lyubomirsky

If you’re inclined to take me at my word, my name is Steven Lyubomirsky, I’m a rising junior at Princeton, I study computer science, and am incredibly handsome. If you’re not, at least three of those can be independently verified. I live under the watchful guard of my blue parakeet in Fort Lee, NJ, a safe distance from the incredibly radioactive center of the universe (NYC, of course), where I like to demarcate my domain with my nightly walks. This summer I’m working on the Platform team.

David Patrzeba

My name is David Patrzeba and I am an intern on the FogBugz team (Project Jackalope). I started on June 6, 2014 because the newest addition to my family decided to arrive on my original start date of June 2, 2014. I am a NJ native and will be traveling home every weekend to be with them, but during the week I will be staying at the Clark St. residence in Brooklyn. I am a rising senior at Rutgers University (The State University of New Jersey) where I am studying Electrical & Computer Engineering, Computer Science, and Economics. Fun Fact: I served in a Special Operations unit in the Army for 7 years, and I may be Fog Creek’s oldest intern ever.

Matt wasn’t lying. He really did catch the biggest fish.

*Each year the intern class is named after the next letter in the alphabet. This year is “J”. Do you have a fantastic “K” animal name recommendation for next year? Talk to me!

Looking for more?

Visit the Archives or subscribe via RSS.