Spec Work (take-home projects or working for free)

Spec Work (take-home projects or working for free)
0

#1

I’m just curious how many of you here have done Spec Work without the guarantee of what a prospective employers can do with your work, or getting hired. Are you guilty or not guilty of it?

I have once, and it was an absolute waste of time. No feedback on the work, no response on whether or not I made it to the next step of the hiring process. Whenever future employers ask me for a take-home assignment as a part of the hiring process, I politely decline. There are better ways of assessing your capabilities such as a whiteboard exercise. We as developers shouldn’t work for free for a for-profit organization.


#2

Whiteboard Exercises test for your ability to perform under pressure in front of a Person,
and solving problems in minutes.

It’s like testing a Soccer Player by giving him a Basketball,
because Balls are round.

Sounds sensible, but has nothing to do with everyday work-life.
Moreover you filter out people, that don’t perform being watched.


#3

I would say that you shouldn’t work for free for a non-profit organization either. The only qualification for a non-profit is to spend all of the money and not make a profit,

The worst thing that I did was do a project for half price. I made it clear that I was working for half price, because I thought they’d get plenty of traffic and I’d get more clients. When they wanted me to update the site a coupe of years later, the cost was about the same. They got mad and said I was ripping them off. It was a lesson learned – I don’t discount for anyone.

If you put together a good portfolio of your work, then you can show that to potential employers, and avoid giving them freebies.


#4

But it does have to do with everyday work-life. Developers have sprints. The point is to demonstrate your thought process or how you would approach the problem. Just go to any interview for tech giants like Google.


#5

A sprint is just some work that a team will work on over the next n weeks where n is however long the sprint is, it’s got nothing to do with whiteboarding. Whiteboarding doesn’t show you can solve problems in minutes. You’re never really required to do the same thing in real life because in real life you have time to carefully prepare for a presentation on a subject that you’re familiar with (ie because you’ve been working on it).

I get that judging people’s skill is often very difficult, because the only way to be sure is to actually work with someone for a period of time. So whiteboarding can be very useful, but it doesn’t have much practical application beyond interviews. And it strongly favours people who can memorise large numbers of common problems and severely penalises people who don’t deal well with speaking to an audience under stressful conditions.


#6

In real life, you are pressured for continuous delivery to your customers. A sprint is not “however long” or an unlimited amount of time. In fact, they encourage you research and experiment with subjects that you are not familiar with. You can’t be an old dog with no new tricks in this industry.

Whiteboarding can be practical because it can look at a person’s thought process. It’s not memorizing “large numbers of common problems” since someone can still possess great skills even if the solution he or she presented is unexpected (which is different than a right or wrong answer).

As of people who don’t deal well speaking to an audience… you do know that speaking to an audience is important, right? You have to be able to articulate your idea and communicate in this day and age.


#7

I get you think it has some super special importance, but it’s just a possibly useful interview tool. Yes, it can show thought process, that’s the point. But it’s a blunt tool, and interviewees generally hate doing it. It isn’t a super well regarded technique, but its been used for a long time and is pretty easy to implement.

An interview is a special case: it’s generally [for most people] extraordinary stressful, so don’t be so disengenuous. Obviously being able to speak well in front of groups of people is a useful skill: not essential for a developer, but useful in most jobs (at any point in history, not just “this day and age”).

Continuous delivery is technique for reducing bugs in software. Unless your customer is your operations team, customers don’t normally pressure for continuous delivery.

As I said

A sprint is just some work that a team will work on over the next n weeks where n is however long the sprint is.

It is however long has been decided on by whoever implemented the system. And unlimited amount of time describes Kanban, basically, that is also a valid approach. Not sure how this has anything at all to do with whiteboarding though

“They” being employers, who need to make profit. Yes many companies will train employees. Yes, many companies advertise that they offer a certain % of work time dedicated to exploratory software projects (which has tax benefits, + in reality this time will always be the first to be cut). But this has zip to do with “sprints” which are just as described, a set period of time in which some work is to be done.


#8

Maybe you should look for work at a real tech company if you have the chance. Companies don’t exist to please developers as demonstrated by your posts. Requirements change. Technologies change. If you think you can take as long as you want to deliver, then you’ll get fired really quickly. Unlimited time in Kanban is an illusion. Time is money. Human labor is expensive. Companies want to cut costs as much as possible and you have to constantly prove to them that you’re worth keeping.

Whiteboard exercises can be a reflection of how you perform under pressure. I get that most people here don’t have years of real world experience, so they just like to or reply with comments of a very rosy picture of how the industry should be like.

Anyways, this is getting off topic.


#9

To your point, I think that a small coding project is probably a more realistic measure of an individual’s ability to generate code that solves a problem. It would me more realistic to have a coding project that involves collaboration, but that is difficult to replicate in an interview process. Whiteboard coding utterly fails to give an accurate sense of an individual’s ability to generate real code that actually compiles and solves realistic problems in a collaborative production environment on actual computers.

I have not participated in such a hiring process, but I would support any company that is innovating in hiring processes and moving away from the archaic and outdated haze of whiteboard interviews.


#10

Obviously that’s true. I’m taking issue with the fact you don’t seem to have a good grasp of what different terms actually mean, or how they relate to one another. Agile or scrum style processes don’t have anything to do with interview tools which don’t have much to do with day-to-day software development techniques

Are you serious? You read what I wrote and thought “aha, here’s someone painting a really rosy picture of a tech industry they definitely don’t work within”

To go back to the original point, I’ve had take-home assignment on the last two jobs: both given on completion of the first stage (not as an initial exercise), with an expectation of taking approx three hours each time. Second stage interview included a review of the code. + I was paid for the time on the second project. It also has problems as an interview tool, but it’s closer to an assessment of how someone will perform in job conditions than whiteboarding is. Spec work is completely different (and is very common in design, but not that common in software development, albeit with grey areas where the two overlap)


#11

My own two cents:

Spec work: I have only heard of this in the context of freelance work (and then mostly when it’s really about a design). In that case I can understand the rationale behind it. I don’t do freelance work, but a couple of the people I know who do this sort of thing are pretty careful about making sure that they have the rights to their design if they don’t get the job and also that they get paid something during this process if it is more than a couple hours worth of work. I have never encountered it when interviewing for developer/engineer positions.

Take home assignments: This one for me really depends on the circumstances. When I was last job hunting there were jobs I was interested in but never finished my application for because they wanted applicants to do a coding test/take home exercise before they even got a first interview. For anything that would have taken more than an hour or two, that was just not a worthwhile time investment for me. If, later in an application process a take home assignment had been a replacement for several hours of whiteboarding and verbal testing, then that would have been another story. I can see why companies would make a coding exercise a prereq for an interview but in my case I didn’t see value in putting that much work in just to be considered for a phone call when I had other, more conventional options.

Whiteboarding: Sucks. I’ve written about my opinions and strategies with whiteboarding on the forum before, so I won’t go into it much here. It’s like the SATs of software development. We all know it isn’t a good representation of knowledge or skill, but it’s the standard and we collectively haven’t settled on a better option so we keep doing it. During the times that I’ve been in job hunt mode I could write a linked list from scratch in my sleep. I was being asked to do it on a whiteboard about once a week. There are a couple other frequently used whiteboard challenges that you get to the point of being able to rattle off in a few minutes if you’re actively interviewing and there are some challenges you’ll see for the first time in an interview. Whiteboarding always seems to me to be more a test of how well prepared you are for an interview than how well you’ll do as a developer.


#12

What about apprenticeships?

I define apprenticeship as working for a company or an established mentor for a predetermined number of hours a week for severely reduced pay. The company/mentor receives an improving product or service they can resell cheaply for a profit. The apprentice gains experience without relying on the company/mentor for survival. If the apprentice or company/mentor sours on the relationship, everybody goes their own way. If the apprentice reaches a certain skill level, he or she can ask for better money, hours, benefits, etc or uses the portfolio from the apprenticeship to secure a better job.

For me, I use interviews to spot red flags in a corporation. Corporations are like people. Some are crazy. Many are sane yet incompatible.