Choosing a Technology Stack for Startups

Work BridgeArticle by Miles Thomas, Practice Manager in Workbridge Philadelphia 

Tech startups from all over the country come in a variety of shapes, sizes, and types. From established entrepreneurs who have already sold multiple companies to college seniors working out of a basement, software engineers and businessmen alike have dreams of solving the ailments of the world, one solution at a time. To start an LLC isn’t all that difficult these days either; all you need is an idea, a working space, a computer, and (for some) a bottomless pot of coffee. Sounds easy, right?

Well, as integral as elbow grease and caffeine are for any start-up, a direction may be the most important thing for any would-be entrepreneurs out there. One direction that is integral to technology companies is the different layers of technologies used to accomplish whatever problem they are trying to solve; this is known as the technology stack. There are many different kinds of technology out there, but most companies land either between one comprised of open source technologies (also called Open Stack) or a proprietary technology owned by another company (.NET owned by Microsoft, or Java owned by Oracle). So, what is the best choice for all you startups out there? Read on…

An illustration of some of the different layers of a technology stack, and the options that an entrepreneur would have for each.

Above, is an illustration of some of the different layers of a technology stack, and the options that an entrepreneur would have for each.

It's well known amongst most tech savvy individuals that open source tech stacks seem to be all the rage amongst startups. After all, not only are open source technologies free to use for you bootstrappers out there, but there are a variety of different programming languages to use depending on what you’re trying to do. Need to use a functional programming language for reactive application design? Use Python or Scala. Need to do simple website development for clients big and small? Use PHP or Ruby on Rails. With so many tools at your disposal, the possibilities truly are endless.

Hire Tech Savvy Individuals Today

Java and .NET may not be as flashy or wide-ranging, but they do offer an array of different tools. With different frameworks and API’s designated to each company’s respective programming languages, Microsoft and Oracle do not leave their users without ammunition. Furthermore, there are defined boundaries for what tool to use and when- this can be extremely valuable for someone who doesn’t necessarily know their way around the latest and greatest.

Work Bridge

The lack of boundaries is the biggest hurdle for people looking to implement an open stack. For example, if a company decides to use Python as their language of choice, what frameworks should they use? Django? Flask? Tornado? CherryPy? What about JavaScript libraries and frameworks? Angular? Backbone? Ember? There are so many possibilities with no guidelines for first timers that it is easy to get caught up in all of the different technologies. Another easy pitfall is ambition to use technologies that are not necessary- I can recall a small web design shop that was trying to implement Amazon WebServices as an example (they are no longer around).

The boundaries presented by a Java/.NET stack come at a cost, quite literally. The obvious downside of proprietary programming languages is that they can be quite costly; this can be a huge deal-breaker for a small startup with little to no funding. For a smaller company looking to stay afloat, spending what little money they have on-hand for something they can get for free seems foolish (on paper, at least).

At the end of the day, picking programming languages is all about circumstance. If a company has the money to spend, Java/.NET may be the way to go. If a company is strapped for cash, or if one of their founders has a background in some kind of open source language/framework, then open source may be the way to go. Given the convergence of the current technology landscape, however, it may not be long before it won’t really matter!

Work Bridge

4 Desirable Traits of Open Source Job Seekers

Article written by Jaime Vizzuett, Practice Manager of Workbridge Orange County

Work Bridge

As many know, the tech market is a candidate’s market.  There are very few exceptional engineers with a solid background, and a lot of job opportunities - with the Open Source market being no different. People hire people because of a particular skillset, whether it’s an architect or a junior candidate, regardless of the industry. As Practice Manager at Workbridge Associates Orange County, specializing in placing candidates with Open Source Technology backgrounds, I’ve found that in addition to a particular skillset, hiring managers desire a candidate who displays selective traits, especially in the Open Source market.

Before getting into these traits, it is important to understand that companies which use Open Source technologies are most likely startups. This doesn’t mean that every company that uses Open Source technologies falls in the same category, but there is definitely a trend. That being said, I spoke with a few of my managers from Corporate to Startup companies and asked them what they look for in a potential employee or contract employee.

The following are the top four traits hiring managers are looking for in tech job seekers with an Open Source background.

1. Jack Of All Trades, Master of One

You can do a little of everything, but if you aren’t great at something, then find out what you’re most interested in and hone those skills. One of my hiring managers mentioned, “It’s always nice to see a wide variety of skills on a candidate's resume, but I also expect them to know the fundamental basics of whatever they have on their resume.”  There is no problem with having a variety of skill sets, or being a “full-stack” engineer, just make sure to focus on one skill, and be great at it. Bottom-line is no one wants to hire an engineer that is a, “Jack of all trades, and a master of none.”

Join Companies Who Hire on These Traits

2. Be Trendy

You will hear it over and over again, but keeping up with the newest technology is crucial in any market, and especially in Open Source. The Open Source market is always going to have a floodgate of new technologies, whether it’s Angular.js or a new version of Symfony. Every company wants someone with the trendy new technology that very few engineers have, so being ahead of the curve will set you apart. Having newer technologies in your arsenal could really make the difference between simply getting an interview and getting the job.

Work Bridge

3. Get Social

Github should be every engineer’s best friend. This is not necessarily a trait, but more like a “nice-to-have”, as one of my hiring managers put it. This is especially crucial for junior Open-Source developers trying to land the job, simply because sometimes Github may be the only example of work that a hiring manager has to look at. Whether it’s through Github, a forum, or social media – having some type of social presence that shows you are passionate and invested in technology is a plus. As the Director of Software Development at a company I work with put it, “I’d rather bring in a junior engineer who shows initiative, passion and hunger to learn more, and Github helps me depict that.”

4. Know Who You Are And What You Want

Hopefully you are looking to find a company that is going to challenge you and allow you to continue to expand your skillset, but also one that fits what you look for culturally. As a hiring manager, building a culture is all contingent on the people they onboard, which is why the face to face interview is the most important interview of the process. The onsite interview really allows both the candidate and company to figure out if they are a fit for each other. Neither every candidate nor every company is necessarily going to mesh perfectly, but they should mesh enough to be able to spend most of their time together.

While technology is always advancing, hiring managers will continue to look for these traits in open source job seekers. Companies will always be looking for the next best talent that can take them to the next level and if you’re a job seeker, I hope the points I mentioned will be taken into consideration as you progress through your career.

Work Bridge

The Benefits of Working and Hiring Contract-to-Perm

Article by Andrew Sleptiza, Division Manager San Francisco.

There seems to be a lack of candidates and hiring managers these days looking to go contract-to-perm, and as recruiters we sit here and wonder WHY? A contract to perm position is where employers would like to bring on a full-time employee but don’t want to commit to a permanent hire right up front. In most cases, a contract-to-perm employee will work on a specific project for a few months in hope that their role will be converted into full-time. 

For an employee, working a contract-to-perm job benefits you in three ways: resume, money, and the job itself.


Enterprise companies are constantly looking for contractors to work on their various projects. Names like IBM, Microsoft, and Apple don’t look too bad on a resume, now do they? Not only that, but because the contract phase of the job only lasts three to four months, if you aren’t onboarded, having the option to leave can open up the opportunity to work for larger companies.


Another reason why we stress contract-to-perm is because what could be better than making money while actively looking for another job? If for some reason you don’t like the job, you don’t have to accept the offer to be converted to full-time at the end of the contract. It’s okay to keep your options open. Contract-to-perm jobs also have a higher hourly rate than salary positions when broken down. It’s the best of both worlds!

The Job

Contract-to-perm positions have some of the fastest onboarding processes we see. These companies are looking to get the job done as fast as possible. The interview process tends to be easier as well – “Can you do the job? Yes? Great!”  In most cases, you also have the ability to be flexible with your hours. As long as the work is getting done, and you’re committing the appropriate amount of hours each week, your employer will be happy. Remember, the bottom line of these positions is to complete a project.

This ‘trial’ period is mutually beneficial for the employee and the employer. That's right, there are benefits for the employer, too. With contract-to-perm positions, employers win in terms of hiring process, the job itself, and the future.

Hiring Process

Like we said before, the onboarding for contract-to perm-positions is typically pretty quick and painless. When looking for contractors, you’re looking to fill an urgent need and thus don’t have to sift through as many resumes and worry about the right ‘culture’ fit.

The Job

Being that contract-to-perm positions are more like ‘trial’ periods, if you find the candidate isn’t a good fit, you are not committed to taking them on full-time. The arrangement lets you weigh their skills vs. how they are as an employee without having to commit right away. As recruiters, that fact alone trumps any argument about not hiring contract-to-perm. It’s like test driving a car before you buy it. Sure, it may look nice, but how well does it actually perform?

The Future

There are two scenarios that can happen with a contract-to-perm employee that can affect your future, both for the better. Say the hire is great and gets the project done but for whatever reason, doesn’t take/get offered to be put on full-time. That candidate will always be someone you can add to your network. If ever there was a time in the future when you need a project done, you know that you can call that person to get it done. On the other hand, if you flip the employee into full-time, you already know what you’re getting. The employee has already proven themselves as an asset and is a great cultural fit.

If you haven’t thought about hiring contract-to-perm or accepting that sort of position, we definitely suggest giving it a shot because it can open up a whole new avenue of potential opportunities.

How to Hire a DevOps Engineer

The competition for engineering talent is at an all-time high, especially in tech hotbeds like New York. Here in NYC, the tech sector is thriving like never before, and companies large and small are setting up shop and building out teams of engineers. Many of these new teams, particularly those in startups and growth-stage companies, are open-source based, and working in lean, agile development environments. As these companies grow, they develop a need to scale their infrastructure to support an increase in customers or traffic. Enter, the traditional ‘DevOps engineer’. So hot right now. Everyone is looking to hire one, and most are spinning their wheels trying.

Now, it’s important to note that ‘DevOps’ is not a discipline in itself, but a movement focused on increased collaboration between development and IT. Technically, a DevOps engineer can be someone with any number of backgrounds, but essentially they are someone who can work collaboratively with other engineers ranging across the tech ecosystem.

By running a basic search in a job search engine, you’ll notice that most ‘DevOps’ titled roles are calling for the same thing: a senior engineer with a strong background in Linux systems, a knack for programming, using modern languages like Ruby and Python, and experience implementing tools like Puppet or Chef for Configuration Management. Great. As a recruiter, and a non-technical person, those skills are easy enough to identify, and tangible enough to evaluate within minutes of meeting a prospective candidate. Here’s the problem: there aren’t many of them out there.

Because the core DevOps tools (Chef, Puppet, etc.) are relatively new, the pool of candidates who have had the opportunity to master them is small. Until recently, only the most forward-looking of engineering teams opted to implement these modern configuration management tools, and complimentary tools (Hudson/Jenkins, Foreman, mCollective, etc.). This has not only created a bottleneck in an already competitive candidate recruiting landscape, but a catch-22 for many prospective engineers who lack exposure to the technologies required by many of the companies they’d like to work for.

The result of these conditions is 200+ open jobs- the majority of which have been open for more than two months (some as long as seven or eight months). With this comes significant salary inflation for those qualified to fill these positions. My team has seen several instances this past year where candidates in NYC who have been courting multiple suitors have generated offers of more than $40k above their current salaries.

So, if your team is looking to onboard a DevOps engineer, and you can’t afford to compete with the top tech firms in your area or wait months on end, what can you do?

At Workbridge Associates, my team and I have overseen many successful DevOps hires by clients who have decided to employ someone who is more junior than they had in mind, but with some training, can grow into the role. In these cases, our clients bring on someone who is eager and grateful for the opportunity to expand their technical depth. After all, the DevOps ethos is predicated on cultivating a collaborative technical team. In the past two years, we’ve noticed that junior hires in the DevOps market have resulted in candidates who stay longer. What better way to build a true DevOps team than to develop it in-house versus bringing in a hired gun?

Of course, every team has different needs, but here are a few things to remember if your company is actively looking to bring on an elusive DevOps engineer:

  • Be realistic. Every CTO thinks that their product is great and should attract top talent. It will become apparent pretty quickly if this is the case or not, and it’s crucial to adjust accordingly.
  • Be creative. If you’re not having success bringing in the ‘finished product’ right away, it’s time to explore other options and weigh training costs.
  • Sell the candidate on what you can do for them. Beyond salary and benefits, the best candidates want to know how they can increase their technical capital. Make it clear from the first interview how your team can help the candidate grow their skills.
  • Talk about the long-term role that the candidate will be able to take on with your company. This is a concern I’m hearing more and more. Many senior DevOps engineers are hesitant about roles that require them to do a lot of upfront automation, because there are cases where once that initial work is done, they have essentially automated themselves out of a job and are relegated to ‘keeping the lights on’, so to speak. This is dissatisfactory. Give prospective candidates a long-term picture of how they will fit in.

While these points may be common sense for some hiring managers, there are a surprising number of companies that are behind the curve. The tech hiring market has shifted in favor of the candidate, and it’s going to remain that way for the near future. Those who recognize that shift, and adjust, will continue to hold the edge in hiring.

The Top Five Reasons Your Engineers are Leaving


Article by Abby Rose, Lead Recruiter in Workbridge Boston

I don’t work on a software development team and I don’t understand the ins and outs of what an engineering team does on a day-to-day basis. But do I talk to engineers daily? Yes, and they frequently divulge information to me that they never share with their manager prior to giving their notice.

I talk to them about why they are looking to leave their company (emphasis on looking because we all know that software engineers across the board are all passive in their job hunts). This article is not meant to tell IT professionals how to run their teams or manage their developers. I hope this analysis provides insight to the most common reasons as to why engineers do end up leaving companies and how it might help in your efforts to prevent losing top talent.

I evaluated the candidates that Workbridge Boston has placed and their “reason for leaving” since the beginning of 2013. We have three teams within our organization that place Java, Open Source, .NET and System Engineers, with approximately 150 placed candidates in the past 2 quarters of 2013.

Below are the top 5 reasons why, in our experience, engineers leave their companies:

1.   New Challenges/Growth/Strategy

We’ve all heard it. “I have no room for growth in my current company” or “I am not challenged here anymore.” But what do those statements really mean? Our first reaction, as a recruiting firm, is to ask the engineer if they have addressed these concerns with their manager. Many times it is a simple fix and all parties avoid the ever dreaded acceptance of a counter offer.

But what if it’s not a simple fix? Engineers that are not continuously challenged or aren't given the resources to grow their skill set will immediately look elsewhere to do so. Challenge and growth definitions vary for each individual, but what we see as a good solution is to consistently check in and promote an honest and open environment so engineers feel comfortable speaking about their career growth. If an engineer cannot believe in the strategy of a company and their approach to accommodating engineers, it’s easy in this market for them to find another company.

2.   Technology

This may seem obvious, but engineers thrive on teams that foster open mentalities on the use of new technologies. An old and stagnant tech stack is the quickest way to lose talent. Engineers are not necessarily chasing companies that use the newest technologies, but they are looking to leave companies that have closed mindsets.

Again, I know I don’t sit on a software development team. The pains of adapting new technologies to a platform may be difficult, but it could be a good way to challenge your engineers (referring to the first point) to integrate or use the technologies they are interested in.

3.   Team and Management

I’ve never had a candidate say they hate their boss or that the management staff is horrible. The reasons engineers leave their companies due to management is usually because of a shuffle in upper-level management that trickles down to operational changes on a technical team.

If a leader in space leaves the company, or a VP is promoted to a hands-off role, or a new CTO is hired, changes occur that effect day-to-day routines of an engineering team. The most common pain points engineers talk about are added responsibilities and unrealistic new expectations, a new SDLC that kills the current flow, disorganization of priorities, or lack of new/continued mentorship. Management transitions are a crucial time to communicate with a team and again, foster an honest environment.

4.   False Expectations

“I was hired to be a back-end Ruby engineer and I’m developing HTML templates.”  That’s no good! It usually surprises me how much I hear about engineers being hired for a certain position and end up spending the first 3-6 months doing a completely different job. It usually roots back to an interview feeling like a honeymoon without diving deep, and truly deep, into what this specific role and this specific engineer’s timeline will be. If they are going to be developing HTML templates for the first 3 months, say that. Don’t hide it.

Again, communication in the first six months on a weekly basis can prevent a situation getting too far out of hand. Many times, as human beings, we wait until it’s too late to talk about being unhappy with our job. Instead what engineers decide to do is jump ship and find something new where they can ditch the unwanted parts of their current role.

5.   Money/Stability

Yes, every recruiter encounters a job seeker that is driven to receive a higher salary than what they currently have. Good recruiters proceed with a lot of caution prior to representing that candidate.

It is more common, however, to find an engineer that is looking for a job because of the following reasons associated with money.

  1. A startup didn’t get funding
  2. Company is going under and can’t pay engineers their market value salary
  3. Haven’t received a raise in over a year

Some of these factors are not preventable, but setting up realistic goals and incentives for raises will help you keep valuable engineers around longer. Clear cut steps to a bump in salary and honesty about the stability of the company will increase the longevity of your developers. If other people in the company are being laid off, talking about why and what is going on behind the scenes will prevent engineers from looking around. When employees get laid off, it shakes up the nerves of others. Many times engineers in our office say “a few people were laid off last week, so I’m looking because I want to be proactive about finding something new before I’m out of a job.”

Good news is that reason 5 is an easy fix by being communicative, open, and honest about what is happening within an organization and about how each person can be held accountable for their next raise.

Take away what you would like from this information. Hopefully it helps companies reflect on the way they approach retaining talent from an “aftermath” perspective.

Three take away points:

  1. Create a truly honest environment
  2. Communication, communication, communication
  3. Proactive and not reactive check-ins with all engineers

Considering a Contract Job? Ask Some Questions First!

First and foremost, contracting can be a great way of landing your next job or adding some new folks to an engineering team, very quickly. After we find a job seeker a great new contract opportunity and they complete their project, we make an effort to ask our candidates how their experience was – time after time the response has been “Wow… that was fast.” 

Work Bridge

The discerning critics of contracting may say: it’s certainly not a full-time job. They’re right, it’s not; it is, however, an easy way to gain employment in this fast-moving IT industry and sometimes even better than a full-time job. Have kids? Imagine not being tied to a 9-5 work day so you can get paid for the hours you work, whenever you choose to (so long as your manager is okay with it). On your spouse’s benefits plan? Great, there’s no need for you to consider the employers benefits package then. Trying to get your foot in the door with this huge company you already applied to in the past? Get in there as a contractor first, where both the interview process and hiring criteria are often simpler.

Find a contract or contract-to-hire position near you on the job board.

The list goes on, and the proof is in the pudding – temporary staffing firms have seen rising and record profits over the last few years across nearly all sectors. California-based research firm Staffing Industry Analysts predicts that the industry will see a 6% revenue increase annually over the next few years, and hitting close to $140 billion by 2014.

Now that we’ve covered the benefits of considering a contract or contract-to-hire positions, let’s make sure you get some answers from your recruiter before committing:

How long is the contract? Is the business already won?

Know how long you’ll be working on this contract. That way, you’ll know when you need to start thinking about the next contract/project or the next steps to converting full-time. In my experience, I have seen anything from 4 weeks all the way to, well, forever. 

The other thing is to know if the business is already won by the contracting company because sometimes firms like to start the interview process BEFORE being awarded the business and having the ability to put contractors on. You certainly don’t want to turn down the other offers you had when the job you accepted technically doesn’t exist yet. A simple way of asking is: “If I accept the offer, how soon can I start?” The answer you’re looking for is something like immediately, on Mondays, or right after your two week notice.

Am I going to be hired as a W-2 employee or as 1099?

The main differences come down to taxes. As a W-2 employee, you will receive pay checks with tax withholding already taken, and you’ll receive an IRS W-2 from your employer in January of the following year. If you are hired as a 1099 contractor, you’ll get full pay with no tax deductions, but you are also responsible for paying your own taxes come April 15th of the following year.

It’s tempting to opt for the 1099 route since your pay checks are bigger, but that smile quickly goes away when you realize you not only have to calculate how much you owe at the end of the year, but in fact you OWE MORE! You get tagged with self-employment tax which is another 13-14% of your income on top of the taxes you already pay.  As a perk, however, you can write off multiple expenses for your work as well (transportation, computers, phone service, etc.) Think about these points before deciding which is better for you. 

What happens when the contract ends?

It’s important to know what your options are – most staffing companies have other projects they will have needs for, and it’s good to know if you can still qualify for those. The benefit of using a technology-specific staffing firm is that a great majority of their other clients will have needs that match your skill set so that when you’re done with the current contract you increase your chances of landing another quickly with minimal downtime.

What is the realistic time-frame of converting temp-to-hire? What salary can I be expecting?

If the contract is a temp-to-hire position, it’s a good idea to know when you might be converting to full-time status. That sets the expectations on both sides, and both you and the employer are on the same page. Typically that can be anywhere from 3-6 months, and if you find yourself in month 8 with no talk of conversion, then it’s time you bring that up again.

Work Bridge

Now most people get a bit nervous when talking about salary and compensation, but you should know what the potential salary can look like when you convert to full-time. It may be an uncomfortable conversation for you to have now, but it’ll save you a headache down the road – you don’t want to find yourself having worked 4 months into a contract only to find that the salary they’re thinking of doesn’t even come close! Of course, it’s important to be realistic as well. If you are a W-2 employee getting paid $45/hour, you should be considering a base salary of around $90,000 (inclusive of benefits and such).

Have more questions about being a contractor? Ask the nearest office to you here.

For a first-timer, a contract position can look intimidating, but don’t let that stop you from considering those opportunities. There are countless stories I come across and personally experience where contractors are thankful they took the offer. Don’t forget to ask your recruiter some questions, so that you’re fully comfortable before moving forward.

Work Bridge

Showing 8 of 38 posts