Give me a resume that shows a long list of castles they helped design. I can use my own knowledge to decide the quality of that work. If they list being in charge of high-profile castles that have survived many raids, or helped design the emperor's fortress, I can consider that. If they list several castles and I know they were all repeatedly captured and difficult to defend, I can consider that as well.

As @Shyr stated when you work for a company your role is embedded with the work of others, so what you are checking and what you mean by success, is so much the work of the applicant + the work of probably 20 other developers + the project business viability worked out by the company + plus well funded project. All these still very good, but...

A portfolio showcasing a castle-maker's skills may show me a beautiful throne room or a remote structure that has never seen conflict, but I would wonder how the castle would survive an onslaught of siege engines, battering rams, and scaling ladders.

....before you consider the solo project untested you can check the link for this solo project/portfolio and run the game. Check the the mechanics of the project... Don't determine its untested or cannot withstand those rigorous onslaughts... because its a solo project.

....before you consider the solo project as untestable, consider this project may not have had any funding at all, business side may not be solid (but (s)he is not applying for a business position) and also the vastness of the work completed by a team of say 20 people is overwhelming when compared to the work of a single person.

I once completed a project that failed in getting to the market because the business side and funding wasn't solid (but I never applied for a business position, instead i applied for a programmer's position). But then this project wasn't even looked at at-all before or during any of the interviews that i subsequently attended. So the project and all those years work just sank to a wasted black hole.

I think its a combination of laziness go to web-links and thoroughly test projects and the illusion of seeing only company/professional work as the only viable testable work

Your portfolio can just as easily be a patchwork of half understood code cobbled together from the internet just as easily as it is totally you own original work.

I agree with frob that your professional work history is a bit more important. Making games is a job, generally a fun job, but a job nonetheless. Granted you didn't do 100% of the work and may have coasted from time to time but it shows you were able to work with a team and get things done on a reasonable schedule. Working on and hopefully completing projects on your own is great and isn't something that a lot of people can do. But working on something when you want to isn't the same as working on things when you have to.

Your portfolio can just as easily be a patchwork of half understood code cobbled together from the internet just as easily as it is totally you own original work.

I agree with frob that your professional work history is a bit more important. Making games is a job, generally a fun job, but a job nonetheless. Granted you didn't do 100% of the work and may have coasted from time to time but it shows you were able to work with a team and get things done on a reasonable schedule. Working on and hopefully completing projects on your own is great and isn't something that a lot of people can do. But working on something when you want to isn't the same as working on things when you have to.

In that case (and this doesn't apply to me currently though, but it did in the past) before your first job, you are trapped because no one takes your projects seriously. which is all you could have before your first job

For the long period I was trapped in that situation, my project was my job, I didn't work on it when I wanted to, but because I had to, because I worked as an Indie developer and had to get things done to deadlines as a lot was at stake, personal reserve funds were very limited, and my wife was up on my neck.

And I bet apart from students and hobby project, a lot of lonewolf Indie developers are in that situation. So from your your logic their work is not so important

I'm not saying many people don't cobble stuff from the internet and work less seriously on their projects as you described, but you can't put everyone in that box. More so people do exaggerate or even lie about their work history and experience anyway. So depending work history from CV isn't bullet proof either. So how do employers sort the difference between professional personal projects and hobby personal projects? The same way they would sort out exaggerated (or lies) work history from genuine work history

I'm not saying many people don't cobble stuff from the internet and work less seriously on their projects as you described, but you can't put everyone in that box. More so people do exaggerate or even lie about their work history and experience anyway. So depending work history from CV isn't bullet proof either. So how do employers sort the difference between professional personal projects and hobby personal projects? The same way they would sort out exaggerated (or lies) work history from genuine work history

After reviewing a few hundred of them, much of it becomes easier to spot. Some of them are harder to spot, but the obvious filler becomes obvious.

It is also typically easy to spot people who are exaggerating on their work versus those who are humble yet still accomplished a lot. I've read quite a few resumes that are understated and short, but each item leaves a powerful impression. A history of successes is easy to spot, far easier than looking for grandiose items.

For game industry jobs the game credits are quite easy to verify before calling the person in, several sites show the game credits, other times you can find the credits shown on a youtube clip and search for their name. But that usually isn't necessary.

The thing about hiring is that many people could potentially do the job well. Given a pile of job applications probably a bunch of people would all be fully qualified and could do the job immediately. As an employer we've got a big stack of applications to sort through. We make a quick pass through it to find perhaps five or ten that look good on paper. Usually many of them look good on paper. Unless the job listing specifically asked for junior developers, usually a high number of them have prior experience in games, a high number have a degree, a high number have reasonable credentials. We pull out a handful that look best among them and start calling them in for interviews.

Once they get in to the interview, after the introductions, you can go down the list and ask detailed questions. What did you do on this project? What challenges did you have? How did you solve them? What technologies did you use? How satisfied were you with the result? What are you most proud of? What do you consider your biggest success on the project? It is unlikely that they claim they stayed at a company several years but really didn't work there, or that they managed to hide in a company for years somehow without being discovered as a fraud. Drilling down you can typically get a good gauge on how skilled the person is at various technologies or types of problems, how smart they are generally, and how likely they are to succeed at the new project.

Usually it is pretty easy to see approximate skill levels on paper and even more direct to accomplish in interviews. But even if the person managed to deceive on paper and deceive everyone involved in interviews, if they don't pick up the job most of the world has laws that make it is easy enough in the first few months to tell the person: "This is not working out, sorry. We're terminating employment."

Your portfolio can just as easily be a patchwork of half understood code cobbled together from the internet just as easily as it is totally you own original work.

Please explain to me how a resume is different. It is entirely possible to do the same with both, so I feel this is a moot point.

It appears that you and frob do not share the same viewpoint as greyhounder and I. Agree to disagree? This discussion doesn't seem to be going anywhere. We are just restating our points.

I can say from my own experience that without personal project, I'd likely be flipping burgers today. Instead, I lead development of software that is used to plan all roadway projects funded by the state I live in.

Being able to prove that you actually know what you're talking about is huge when you're competing against a bunch of college grads who only took computer science because someone told them it was where the jobs are.

My 2D platform game and level editor got me a job developing business software.

I wouldn't personally hire a programmer who didn't have personal projects. If all you showed me was coursework, I'd assume you lacked the passion we all share here.

Frob, If an interviewer judges your ability to do the job on the quality of completed professional projects, them can working on a bad game go against you in the long term?

After all you're just one of a team and you develop what you're told. It's not really your fault that you once worked on a really bad licensed title that flopped and got a bad review.

I know someone personally who worked for a games studio famous for bad licensed games, who are now long gone.

What are your thoughts on this?

I've interviewed for developers but of business software not games, some is similar in that a professional job history is more important than any hobby project for showing you can do the job. This we both agree on.

Frob, If an interviewer judges your ability to do the job on the quality of completed professional projects, them can working on a bad game go against you in the long term? After all you're just one of a team and you develop what you're told. It's not really your fault that you once worked on a really bad licensed title that flopped and got a bad review.

What are your thoughts on this?

I can only speak for myself and the interviews I do.

I look for a pattern of success. I look for a pattern of smart behavior.

If the person worked at a game studio for five or six years, even if the games they released were not top quality, I can see they have several years of professional work experience completing a bunch of games. That is a pattern of success.

If the person held a job while working through school, achieved good grades, put together a portfolio, that is also a pattern of success.

For COMPLETED GAME TITLES, I don't hold that against the person. They work on the job titles they are given. If their studio brings them a job making shovelware, I look to see if they were successful in their own merits. Did they do the job well? I don't expect a two-developer marketing game to be a AAA product, and if the person finished the product, that is a success to me. If the person worked on a AAA product, that is also a success to me. If the person completed a degree that is a success to me. If the person completed an independent game that is a success to me. If the person has a passion for completing some other type of projects, that is a success for me. I want to see a pattern of success. I want a pattern that shows the person sees a project through to completion, applies their brains to overcome problems, and knows how to finish things.

For EMPLOYMENT HISTORY, termination and work length can be a factor of success.

If a person worked at a studio and was terminated in under a year, or even under three months, I don't hold that against them. Studios have layoffs, studios have financial problems, I've seen first hand where studios hire a bunch of people, corporate contracts suddenly shift, and all of them are unexpectedly left jobless. No problems. Other times the person gets in and discovers the boss is a jerk, the company owner has unrealistic expectations, and they need to leave while they still have their sanity. Again, no problems. One data point does not establish a pattern.

If a person has TWO successive job losses in short order, I see that as a warning but not fatal to the application. I won't use that to pass up the job application, but it is something I will consider. If the "should interview" pile is already well-stocked it could be enough to keep it out of the pool, or it might not if there is something else interesting on it. I might search Google to see if there were mass layoffs at the time, otherwise I'll ask in the interview. Two back-to-back jobs may be some bad luck, or may indicate something is going on. Two data points is the start of a pattern.

If they have a short job, then a job for 2+ years, then another short job, I see that as a minor concern to ask about in the interview if they otherwise look good, but little more. The pattern of short, long, short is also the start of a pattern, but the positive item in the middle leaves me plenty of hope. Again, it is potentially the start of a pattern but not necessarily a problem.

If a person has THREE OR MORE successive job losses in short order, that is enough to cause concern for me. In that case I will absolutely search on the company names before putting them in the "should interview" pile. That is starting to show a pattern. If they lost their jobs three times in short order and they weren't on games news sites like "Studio shuts doors", or "Studio layoffs, 250 unemployed", it will take a huge positive on paper to turn that around. I can understand it might happen with a stroke of bad luck, and if I were the worker I would change my resume around a little bit, perhaps treat the resume as "relevant experience" versus "all experience", or show their side projects during that break. Unfortunately at that point it is a pattern, and not a good one.

One of the interesting trends for employers, assuming you occasionally read business magazines, is how some people after they have been struggling to find a job after a certain amount of time sometimes become unemployable in their old job. Companies see the gap in employment and assume other employers passed over them for good reasons. Typically this knocks the individual back a few levels in their career. I try hard to consider that sometimes job markets are difficult, and I personally don't hold an extended unemployment over a person's head. I've had my own experiences with difficult layoffs that hit hard and took time to rebound from, so I am sympathetic. Programming is a meritocracy more than other fields, so if the person has completed jobs that are meritorious I consider it a positive.

I do not care if the person has spent a decade on Barbie products or cheap knock-off games. I care if they are successful at creating games first and foremost.

A resume that shows a pattern of success is typically quite clear. I've got four of them on my desk right now. They're covered in things like "3.8 of 4.0 GPA", "Masters degree", "completed projects include", "Release a well-received Android game (link)", "Designed and implemented from the ground up", and so on. I've got another stack in my wastebasket right now, pulling a few out have terms like "Acquired requirements", "Helped build a section of", "had a summer internship to experience the corporate environment", "followed procedures to". Those last few might be able to do the job, they might be assertive enough, they might be wonderful developers. But I won't know because I'm not interviewing them. They don't compete in a vacuum, and other resumes look better.

Many of the resumes in my wastebasket right now are not "bad". They didn't do anything wrong. None have an inexcusable error. It is quite probable that most of them would make great workers. Their problem was that others looked better on paper.

And unfortunately for these four, we only have one position available. Based on experience and what I see on paper, I'm guessing all four of them would be technically capable of doing the job, that all four could potentially succeed here. They all have good credentials and several years of work experience in the industry with several completed titles. But 75% of them are not going to be hired, we only have headcount for one of them.

Again, I won't be excluding them because they are bad at the job, or because they failed at the interview (people rarely bomb interviews), although if they happen to do particularly bad that might be a factor. I will not be hiring them because they aren't in the vacuum, one of the people was objectively better than the other. We'll offer the job to the one, and if they don't take it, offer the job to the next.

And sometimes, not even then. Sometimes we look through resumes and find a few good ones, we bring them in for interviews, and we discover we have two or three people that we would love to hire. We might ask about increasing the budget, but if they all look good, sometimes we just pick one at random and offer them the position first.

For a junior level worker, I usually do not consider an incomplete hobby project as a success. I'll look at it, and I'll try to objectively consider it as their effort as an inexperienced developer. I might consider it a partial success. I might consider it a failure. I might consider it poor but still a small success given their background. But even though it may be a success or partial success, I don't hold a non-commercial hobby project as high of a success as a completed commercial product. The standards involved and the level of care required are fundamentally different.

Also, be aware that a fully completed commercial success IS a commercial product. I've seen people whose hobby project went mainstream and had tens of thousands of downloads and users. I don't consider that a hobby project, but a big success. Those products are extremely rare, and I've only seen a handful over the years.

Trying to bring it back toward the topic, personal projects are beneficial as they show a pattern of success. In my mind they are a smaller success than a professional project.

"They're covered in things like "3.8 of 4.0 GPA"

You do you care about it? Google used to be very bullish on GPA, and not that recently, HR head at Google done some studies and they found NO correlation between grades/GPA and how good the employees were. There also found out that asking quiz/gotcha questions on the interviews was also no prediction of future employee and only made interviewer feel smart.