The classic debate between the ranks and roles of all digital professions, these days, is as old as the dot-com crash itself. The permanent role vs. contracting/freelancing foray. In the careers of many who enter the game of digital, either or both roles have been experienced. Are the freedoms of one but a mere hindrance to the other? Is the clock of completion and bounty hunter antics the call of many in our space?
As the restless warriors that surround that game, We #TechMasters vary on this subject based on our personal exploits. Whether it’s a 6-month lift and shift, to that dream position at the tech company next door, we’ve been there enough to split the difference.It’s a big world out there.Go Full Time!Full time gigs are probably the best bet for building the beginning of a career. They allow you to be mentored by people around you with more experience, and give you more time to focus on a given problem to solve. — Brian Irish
I agree with Brian’s point. Problems to solve — the best way to level up in a company. Particularly for a beginner in their vocation, mentoring becomes organic. I also disagree because permanent roles do not always have to be geared towards the new start. This can also be considered for those who have already gone down the path of freelancing and contracting, and now they’d like to be more stable. Other amazing benefits include:
- Less risk and uncertainty.
- Financial trust with banks, loaners, car dealerships, etc…
- You have a built-in retirement and protection plan (for example, in Canada all full-time employees contribute to a federal pension plan, and employee insurance in case they lose their job).
- Health benefits (in most cases).
- A clean separation between work and play.
- Being surrounded by people, which may boost your energy if it complements your personality.
- Perm has its own challenges, but in turn: the rewards are just as great.
Permanent roles usually come with these goodies, but the treat is in the people, I usually find. Some people I have met, and still keep in touch with, were from perm role exploits more times than the Wanted: Dead Or Alive life that is contracting.
I agree with the uncertainty to an extent because of skill. One should always be prepared when it comes to a permanent role. Unexpected firings and layoffs can happen. In both instances, the network that one attains and body of work is crucial to the success regardless of direction. There are ways to keep original work through paying attention and negotiating the details of the project/works.
Work life balance? well, I guess that’s true in the respect of perm roles, but I also believe that this is a product of the individual. If one cannot handle the responsibilities given to them in a day, there should be a conversation to be had, at work, for the balance. In my experience, there have been instances where the job takes precedence and, in turn, takes a toll on those who needed “extra time” to complete a project. Some of those stories became horror stories more gruesome than that of a certain Crypt Keeper that scared me straight. Though in some occurrences, overtime cannot be helped, but if it becomes a habit: there has to be a discussion.Contracting/Freelancing: On the Fly — Living on the Edge?!”The only real difference between [full-time] and contract is benefits and bonuses.
— James Wilkinson
It’s unanimous with the #TechMasters community: one’s reputation must be built through work first before one starts down the freelancing path. After a certain point, freelancing/contracting might be for you even after 2 to 5 years of full-time fun. All in all, it’s a decision made by yourself. The benefits can intrigue, such as:1) Technology moves faster than organizations can keep up with them, so if you want to pickup new trends and be on the cutting edge, contract work will be the only way as organizations are most likely to invest in a new technology for a short lived term before creating a full-time position.2) Shorter commitment, higher rates, more money.3) Back to #1, it typically doesn’t look good if you’re changing full time positions often.. but in tech, you will most likely want to move after a year for whatever reason (salary, technology, politics, etc…) so contracts don’t make it look like you’re a job hopper.4) Tax write-offs
— Yan Shcherbakov
Freedom. It’s a great thing in your work. Especially there. What projects to choose, what framework to use, where you can work. Freedom, freedom, freedom. Sure, yet there’s a price for everything nice. Outside of the office, you are the responsible one for the off-court things, too, such as tax prep and finding your next gig. The latest trends seem to point towards this methodology that adapts on a project. This witchcraft is called agile. New frameworks can be added into projects. The write-offs are one of the highlights where trips, meals, training, and even supplies, can be written-off deductibles.
Contracting is somewhat similar to Freelancing. Sometimes, this is controlled by a middle man or third party. Employment agencies or recruiters (shudder) would be responsible for the off-court items that are contracts and payments between the provider and the company. You’re an employee, just an employee to the recruiter’s firm. The firm makes a certain percentage for themselves, paid by the company they deal with in order to employ you. You’re having to undertake looking for the next line of work usually since the recruiter may not have anything at the ready. Networking is always a best friend for handling the issue, whereas relying on the sole recruiter, for positions and the aftermath strategy, could fail you in the process. After at least 50% of the duration, it’s best to have some idea as to where the next adventure will begin. It’s the boy scout’s motto of “always be prepared” because of the high chance of uncertainty. The variety of recruiter firms has changed in the last decade because of various places looking to offload their business to capable hands that do not need to be a member of their organization.
There are write-offs and taxable benefits to obtain, yet when it comes to huge purchases, this might not be the best route when approaching banks for those special lifetime investments (e.g. house, car loans). Business tax is also a hit-or-miss depending on how well-advised one is while approaching the subject after a year of freelancing. Audits can happen, and the financial history should be ready at any time for this.Flexibility with Freelancing
In my career shelf life, I’ve seen resources get extensions for years. The contract’s flexibility can be spelled out in the agreement itself. Freelancing, in itself, can happen in the case of several different instances. One being just bringing in a secondary income or a hobby.
In that instance, contracting/freelancing as a side job is another route. The client knows that this is happening after hours, and will sometimes understand the plight of the said freelancer/contractor, but the estimates would come from the one providing the service. I would stress that there would need to be an understanding of what one is capable of doing in this and any capacity. It comes along with the responsibility point. The ability to set boundaries is an essential skill to have to be successful on either freelancing and permanent. Weekend and evening are mostly expected in the after-hours contracting/freelancing position.
In the end, a decision to choose either or, or even a place to work with, should boil down to the ecosystem and environment chosen. Forget “working from home” — which is close to being a norm that even bigger corporations are making a standard practice. As in, make this benefit less of a priority. It doesn’t matter if you can while working on yet another vaporware, 2-year shelf life app that may need to be redesigned the minute it hits production. If you’re into building the next greatest app or the soon-to-be ad campaign, chances are there is always something for everyone and a company for everyone. Fit totally not needed or included.Further Reading
Here are some items to add to the conversation and the choice between both:
- Are you a contractor or an employee — The Balance
- Should I Be An Employee Or Independent Contractor — Forbes
- 14 Ways To Juggle Freelancing While Working Full Time — Sitepoint
- Contracting Vs. Freelance Vs. Full-Time — Udacity
I’m curious to see what your thoughts are on this subject. Contract/Freelancing or Perm? Join the conversation at TechMasters.chat! We discuss something new every week and will feature a write-up like this one afterwards.
You are a manager and it’s time to hire a new developer to join your impressive team of A+ players. Do you give them a technical interview?
You are a developer and it’s time to be interviewed by a new company. Do the upcoming technical interviews excite you?
Technical interviews are a contentious topic. During our weekly discussion, we set out to ask the #TechMasters community how they felt about technical interviews. There was a pronounced discord between opinions which made for a lively discussion. Why are technical interviews such a polarizing topic?
Two Sides to the Argument
Whether you are looking to hire or you are the one being hired, one cannot hide from technical interviews. They have penetrated the recruiting process of many companies in North America, Europe and Asia. A survey of the #TechMasters community shows there is a clear rift between the two sides. One side uses technical interviews whereas the other side does not.Survey results from the #TechMasters community
There is a slight proclivity to conduct technical interviews within the companies that comprise the community. We set out to come up with a hypothesis to explain this and found an interesting parallel. From a survey of Myers-Briggs personality types, 67% of people are protector, visionary and intellectual types whereas 33% are creator types. How strongly correlated these datasets are is still in question, but we speculate that the company culture and consequently the hiring process closely follows the founder’s and/or executive team’s personality types.
During the discussion, there was a nuanced reasoning behind supporting or rejecting technical interviews. There was, however, a coalescing around two central ideas: (A) technical interviews are terrible at assessing fit, and (B) technical interviews are the only way to judge if a candidate has the required technical skills.
Why you should do technical interviews
The main argument to support conducting technical interviews was to ensure that the new hire doesn’t backfire if it turns out that they don’t have the skills. For example:In a different time and place, I interviewed someone for a WordPress theming position, and although they had a vast portfolio of themed sites, they later admitted to not knowing any PHP or CSS — they just grabbed themeforest stuff and applied them. In a case like this, maybe a basic technical test is necessary. — Enrico
The discussion continued, and it moved into why doing whiteboard or pen/paper tests are useful. If the sole purpose is to assess the candidates learning/problem-solving ability, then it is generally supported. However, technical interviews are a tool that can be misused as eluded in the following:I’ve never given a crap about asking someone how good they are at a programming language, let’s be real, in the real world we will always reference the man pages or docs to get the necessary details. I generally ask them questions to understand how they solve the problem. I tend to ask them to pretend I wasn’t there and have them go through solving the problem whether on whiteboard or paper. What I like to look for is how quickly they give up vs. how dedicated they are to coming up with a solution (workable or not). — Puleen
Technical interviews and the tests within them are used as a leading metric to indicate the discipline and dedication of the candidate. Being able to solve problems, communicate your thinking and learn quickly was repeatedly mentioned as the main traits you should be looking for in the interview. If the technical interviews are being used as a means to eliminate candidates due to the ‘wrong’ answer, then you aren’t doing it right. For example, there was a recent story about a candidate being interviewed for a Director of Engineering role at Google where a non-technical HR person following a script eliminated him. This is an example of when technical interviews fail, and it is our duty as part of the industry to work towards ensuring this doesn’t happen. After all, the primary purpose of doing technical interviews is to ensure A+ players are identified and are persuaded to join your team. If your process is preventing this, then you are doing it wrong.
Why you should avoid technical interviews
Interestingly, the main argument for doing technical interviews can be reversed and used as a means to dissuade from doing technical interviews. The main reason being that technical interviews can cloud ones judgment insofar as you miss the intangibles that the candidate has to offer. Assessing fit has more to do with the intangibles of the candidate, i.e. soft skills, learning ability, then it has to do with their hard skills. Eloquently stated:Regardless of role and position in a company, what possible insight does questions like “solve a Fibonacci sequence” + whiteboard + no internet give you to know about a person fit for a development role?Ability and willingness to learn is my number one criteria for hiring developers. Besides, nowadays, you rarely rely on writing algorithms when developing SOFTWARE. — Ahmad Nassri
The other problem is that the interviewing process at most companies does not evolve at the same pace as the industry. Candidates enter the recruiting process expecting the latest and greatest technology and are thrown into a time machine needing to work on technologies that are sometimes decades old. Due to this the interview questions are almost irrelevant devolving the interviewing process to one of hubris:Working with leaders who haven’t evolved their interview questions or shape them for the candidate/role. It is just ego strokes. — Adrian Mauer
Having a new-hire backfire is not an enviable position to be in as a front-line manager trying to climb the corporate ranks. Therefore, an objective tool meant to assess one’s skills can become biased and intuition-driven. In mature companies, extra diligence is needed to ensure technical interviews are not only used as a means to cover your ass (CYA).
Lastly, whiteboard or pen/paper tests are not the strong suit of certain cultures, demographics and/or personality types. Putting a candidate through these tests is akin to throwing a fish into a shark tank:I have failed the Amazon interview twice and the Google interview once but I always seem to get a job with SOMEBODY slinging code or fixing sick servers. For some reason I don’t do well with coming up with working algorithms on the first try. I submit that I am totally making excuses for myself at this point but I learn and re-learn through play and experimentation and I don’t think there’s really time for that in short white-boarding sessions. — Anonymous
If the candidate is required to do whiteboard thinking in their day-to-day job and can’t do it during an interview, will they be able to do it afterward?
The Technical Interview Spectrum
Black and white thinking is dangerous and after further discussion we began to remove the binary lens and uncover a spectrum of approaches. We found that the definition of a technical interview differed between individuals. Some folks considered algorithmic tests as the technical interview whereas others consider taking practical tests the technical interview. Our survey results clearly show that there is not a single approach and in fact, most companies deploy multiple technical interview techniques (with none using algorithmic pen/paper tests):Survey results collected from the #TechMasters community related to the type of technical interviews conducted.
To illustrate this, one individual described his experience with an engaging, evolved and integrative process. One that not only assessed the candidates hard and soft skills but used the spectrum of technical interviewing tools to accurately assess fit:An interview I did at Venmo/Braintree/Paypal 3 years ago was very well set up. After all the usual phone screens (tech and generic personality “fit” screens) I did a take-home test in a language of my choice, it was a generic CRUD thing with a single “algorithmic” function, so the test was mostly about code organization and structuring, I thought that was great (took me ~3 hours from start to sending it in).Then they flew me over to SF, put me in a very nice hotel and the day of interviews went like this: — Walk around the office, meet the team — Interview 1: talk with someone senior about what you like, what kind of programming you specialise in — Interview 2: similar chat, honestly I don’t remember all the details — Lunch with the team at a nearby restaurant, they paid — Pair programming! On my own gear, in my comfortable setup.They asked me to extend the little app I wrote for the take-home test. — Data modelling time on a whiteboard. That was another great test. They give me a real life scenario and asked me to define the data model both on the application and on the relational DB side. All in all, would do again, except not more than 1 a month because flying across a continent and back for 1.5 days is gruelling.— Simon
Lastly, James Wilkinson described a process which may be representative of the trend many companies are following in North America:If you are going to do a technical test it belongs at the very beginning of the interview process after HR has said ok you meet the requirements. Because doing a test after you’ve spent time with the company getting to know them is a slap in the face. No one ever uses the technical test as a gauge of how you solve problems despite them saying that. Having done so many I know that you don’t pass you don’t move forward no matter how much you can talk through it. So IF you have one, have it firstThey have a place for people who are fresh out of school and have 1–3 years or 1–3 employee experience. You need to check on these people to make sure they can code they’re very young and probably been using a single pattern.What is more effective is a conversation about technical subjects, where the interviewer ask questions like explain inheritance in JS, what is a prototype, what is a closure. These are ways to gauge if they know the langue without making them write code. You should never ask a developer to write anything from scratch, or write anything.Some of the best tech test are solving bugs, make a fake bug and ask them to solve it, the code is already there, it more like how you would expect to work in that environment. This code is suppose to post but it not working, in the code it set to GET change to POST and done, Small simple tasks.You must trust in experience. If someone has code online, a portfolio and company names you’ve heard of on their resume, don’t waste their time or insult them saying we want to do a technical interview.Ask the developer, or as the developer, ask to come into the office for an hour and have them shadow a developer, see the real code and the real problems. I do this after an offer is extended before I sign. — James Wilkinson
Go Beyond Fibonacci Pen/Paper Tests to Assess Candidates
If you are a manager interviewing candidates, you should take a long look at a process that employs multiple technical skill assessments. Combined with pair programming and lunch with the team will certainly give a holistic overview of the candidate’s fit. For those being interviewed, a good indicator of the culture is the process you go through. A pejorative and humorous term emerged towards the end of the discussion, namely being Fibonacci’ed:For someone with 1–3 years of experience without an extensive Github, it’s useful [to do technical interviews]. I would definitely not Fibonacci anyone… but for intermediate to senior level candidates, asking them to spend time answering textbook problems isn’t the best use of time for anyone.. — June Coffey
If you get Fibonacci’ed in your next job interview, perhaps you should look elsewhere? If you are the one doing the Fibonacci’ing, you are doing it wrong.
The Weekly Picks
The following articles posted during the discussion are enlightening:
- Interviewing Programmers (Eli White)
- The Terrible Technical Interview (TechCrunch)
- You Suck at Technical Interviews (Laurie@Seldo)
- Technical Interviews are bullshit (Anonymous Author)
Future Articles in the Series
Two interesting questions were raised, to paraphrase:Do companies that have a religious TDD culture ask more hardcore algorithmic technical interview questions? — Jason ChenAre technical interviews predominantly a North American trend? — Ahmad Nassri
These will be the topics of future blog articles.
How do you feel about technical interviews?
Do you have a technical interview story to share? Tell us on TechMasters.chat. We discuss something new every week with hundreds of perspectives and backgrounds to learn from.
If you would like to help us with the technical interview series, our 7 question survey is available here: Technical Interview Survey.
Your story may be featured in an upcoming article!
Special Thanks to Andrew Moore and Ahmad Nassri.