It isn't, though, and demanding a portfolio is almost as terrible a practice as Cracking the Coding Interview style interviews.

I have to believe it "is neither engineering nor science, and is purely creative"? Only those extremes? I believe it is some of all 3 and I don't think requesting (i.e. not "demanding") a portfolio or prior work is any more unreasonable than not asking for it.

On top of that, many electrical and mechanical engineers are not licensed because they don't need to be. (Everybody likes to jump to the civils in these discussions and forget about us, since civils are basically required to be licensed.). EEs and MEs don't get put through the same bullshit that this industry puts developers through.

Demanding a portfolio isn't a great hiring strategy simply because a lot of people's best work isn't out in the open. Who would demand a portfolio from someone like Mike Acton? It'd be enough to know what he's worked on and talk to him. And at the same time requiring a licensing proxy is no help either, he never went to college AFAIK and that'd probably be a minimum requirement for most actual licensing proposals.

Is your "portfolio piece" spaghetti code or well-thought-out modules? Is it doing something recursively that shouldn't be? Do you have elegant code or brute-force solutions? Is it write-only?

All of these can be seen in a portfolio or side project if you choose to look.

It's certainly not a science, and it's very rarely engineering. About the creativity, it's a craft. There is some creativity baked in, but about the same amount as for mechanics or carpentry.

Do you think a 10 minute scan of an arbitrary GitHub account is the same? I say decidedly not.

For example, an applicant that goes through the trouble of writing a thoughtful, reasonable README for every one of their projects signals a positive quality.

When comparing two candidates, that's certainly something to consider.

There are a lot of great engineers with empty or "bad" Github profiles.

1. They care enough to have a Github profile

2. I can see their actual interests.

3. I know they're interested in random experiments

4. I can see if and how they treat their projects. Are they dedicated maintainers, or do they just fire off one-shot projects without ever deciding to maintain them?

And a whole lot more. A person who maintains a single shell script project with diligence is worth more to me than a thousand developers with bullshit lisp and haskell repositories.

Yes, there's a bunch of great engineers with empty or bad github profiles out there. But those engineers aren't showing me that they're great engineers. The ones with a single or few well-maintained projects do.

Many people have their favored hiring "hacks", and they almost never actually signal for the things they purport to. It's way too easy to fall into confirmation bias or overstate one's ability to judge others.

I just know a lot of people find side projects fun because they can let loose a bit and try out random stuff that may not be their "best" code.

This is still a huge asset. It's important for a person to want to grow and learn new stuff. When it comes to hiring a person, there's a whole lot of stuff that's important. Maintaining a long lasting project is one of them. Having an interested in fun side projects, also. It doesn't have to be good code. In fact, I have my fair share of "this project is not maintained and should not be used in production code" repositories. That's just shorthand for "this code sucks".

Perhaps more tellingly I've interviewed people with seemingly impressive GitHub accounts who were just terrible. That experience leads me to believe it's easy to set up a GitHub that "looks good" without having the chops to back it up.

You can't because design isn't about style, it's not art. It's about solving problems and increasing your employers profit.

Perhaps the best solution would be a unionized right to proper credit to developers like in the film industry.

Ask questions, and do you really expect a hiring manager to have work relevant to your interview to show? But you can ask about policy, culture, etc.

First of all thanks for being so disingenuous with your responses. But a programmer is actually creating things ie, code and programs which can be shown. A manager is talking to people, going to meetings, emailing people, ie not much work to show, because their work boils down to talking to people. So basically different jobs have different job interview processes, you wouldn't hire a designer or architect without seeing their previous work.

cute, but you'll adapt.

My life drastically improved when I limited who i gave a fuck about. People who don't hire me don't make the list.

I highly recommend not giving a shit to anybody else.

Many other professions also require work samples. Even salespeople are required to produce metrics from past jobs on the number of sales they made, and get put through practicals where they need to actually do a demo pitch for something.

Not civil engineers (because it's hard to build a 4-lane suspension bridge on a Saturday) but very often candidates in electronic and electrical engineering have side projects that can help them land a job. Are the electronics breadboard projects that you did in your garage absolutely required to get a job?!? No, but they help you stand out among the crowd.

The reason that <computer programmer> is different from your analogies of marketers, lawyers, recruiters, etc is that the activity of programming is often a source of fun and play. Some children with curiosity start programming on their own and continue it into adulthood. (And hence, they might have some personal github projects.) In contrast, people typically do not do "lawyering" for recreational fun.

Programming is enjoyable enough for some that side projects on github are mostly a voluntary and organic phenomenon. Some employers are taking advantage of that signal and prefer to hire those types of programmers.

Indeed, it's the opposite - industry bodies have to mandate pro bono work, which wouldn't get done otherwise.

Whiteboard stuff selects for a particular algorithmic dexterity that I just don’t need a lot of the time. And rejects some of the grungier virtues that make a big difference in moving units in production.

Hiring folks for a couple weeks is fantastically expensive in management overhead. I gotta be highly confident you will work out to take that step.

Just hiring a bunch of dudes and firing the duds is similarly expensive and I frankly don’t want to be that guy. I hate firing people just because I was lazy interviewing. This is my job and I take it seriously.

And there are a whole lot of guys that just don’t ship. They show up. They commit code. They are prompt and attentive at meetings. But if you need to ship, they just can’t shit it out. So many organizations are rotten with these guys- you wonder how so many devs can produce so little product, this is the reason. (Also shitty management- mgmt is ten times noisier and a hundred times more expensive if you fuck up.)

Inability to ship tends to be a project planning and scoping problem, not an engineering performance problem. If you can't ship, it's not because you have lazy developers but because you either bit off more scope than you could chew, or you don't actually have a plan that gets you from-here-to-shipping--one that is more detailed than "work harder, guys".

Yeah, you're right, if shit isn't shipping, it's my fault.

But.

There are a variety of psychological profiles in computing, and they have various pluses and minuses. I need folks with kind of a... move fast and break things attitude. That's what I select for.

Furthermore, the 80/20 rule is a super real thing and the last 1% until a project ships hurts real, real, real bad. There are people who can push through that and there are people who can't. Yeah, it's my fault we're not sipping tea as we ship, but I've been doing this a long time and I'm pretty good at it, and I can't make that pain stop. I just can't. I've been on teams that shipped and suffered, and I've been on teams that didn't ship.

If somebody's cracked this code for me, man, throw me a bone. But while I'm always trying to do better, I also kind of have given up. I'll make it up to you on the other side, I promise, but it's gonna hurt a little pushing it out.

Yes, sometimes. I'm a mechanical engineer, and frequently interviewers would ask what sorts of projects or engineering related hobbies I have. They're not necessarily looking for me to have brought a mass-produced consumer product to market in my spare time... most mechanical engineers I've met seem to be excited enough if you talk about working on cars or bikes.

I can see how software engineering may be similar. They may not be expecting you to be working on some hugely popular app, they may just be trying to get a gauge on what you're really passionate about. I don't like to wrench on cars in my spare time, but I've still gotten job offers after it comes up. In the end it's just a matter of finding the team that has similar values to you.

My work is my work, and my play is my play, and I question the wisdom of judging the play in the decision to hire someone to work for you. Even when I do code at home, away from the office, I do it differently. It might be in a different language, for a different target platform, for instance. I might write more automated tests, because I can't hand it off to a tester that isn't also me. I might write something with a command-line console interface instead of a GUI, because my user base is probably just me, and I know that person is not a helpless idiot who can't read a man page--a man page that I probably will never write in the first place.

Real work is reading the crap code written by your predecessor, understanding it just enough to change something without breaking everything else, and moving on to the next thing as quickly as possible. No interview has ever tested my ability to read existing code or to alter existing code for a specific goal.

Whiteboard this: "This third-party data grid inexplicably causes all text typed into this column to come out backwards. You have 60 minutes to fix the problem, because code freeze is in four days, test needs at least a week to bang on a release candidate build, we ship at the end of the month, and you have 15 more equally-stupid issues waiting for you." And then you are judged on the quality of your horrendous kludge. Those companies that look for perfect people that write perfect code at work, then go home and keep doing it, are living in Cloudcuckooland.

Right now, my side project is getting the last two achievements in Fallout 4. After that, it will be banging out an entire novel in November. Or maybe it will be making furniture to hold DVDs, with a built-in system to deliver a painful shock whenever someone puts them back out of the correct order (which is sorted first by genre, then alphabetical by series name or title). Or maybe it will be working out a plan to terraform Venus using wormholes. When I leave work, I do whatever I want. I don't want to endlessly prep for an unending parade of stupid tech interviews.

I guess our field is so enjoyable that many people have side projects. Apparently, some recruiters think it's a good indicator of future success. I wonder if it's the case though. I teach CS and usually, passionate students (those who work on their own projects) are indeed better and spend much more time working on their assignments. But it's not the end of the story. For example, some are only motivated in things that involve coding, are stubborn, or are bad team players! Conversely, there are students who aren't hobbyist programmers but are smart, learn fast and are a joy to work with.

> a corporate lawyer purely based on their pro-bono work?

You hire a corporate lawyer based on their public reputation. For a programmer, that's their github portfolio.

Business are in a unique position to actually judge programmers by their merit, not just hearsay or bullshit references or lies on a resume. Of course companies are going to factor that into their decision!

Not everyone is happily doing FOSS projects.

But that reputation comes from his actual daily work. I as a developper don't get paid to improve my github portfolio all day long...

Side projects are a strong signal the candidate enjoys this line of work, and ideally I'd want them working on things they would enjoy.

I would also prefer if I did not had to worry about readme or css projecting this or that image.

>A growing body of research suggests general cognitive ability may be the best predictor of job performance.

Would you hire a musicians who didn't have recordings of their work and wasn't willing to perform an audition? Would you want to hire a musician who didn't practice new things?

The development landscape changes rapidly. Frameworks come and go. If you want to keep up in the industry, you will most likely have to learn a new language or learn a new framework at some point along the way. If you only code during your 9-5 you are forever stuck with your current skill set and will end up like the people in 2017 who only know COBOL and can't do anything else. Your job options will shrivel and you will not be very marketable.

Are they? I've yet to be asked about it. It might be different for new grads, but what people seem to care about most is if you've worked for a major firm, or in the case of the video game industry, a "AAA title".

Different things are different.

Also, in the actual MOOC, for which you have to register at https://www.fun-mooc.fr/, the videos are also available dubbed in English. (Except some that are not part of the "actual" course that give tips on how to use the environment.)

"Keep, ancient lands, your storied pomp!" cries she With silent lips. "Give me your tired, your poor, Your huddled masses yearning to breathe free, The wretched refuse of your teeming shore. Send these, the homeless, tempest-tost to me, I lift my lamp beside the golden door!"

The US is still very sparsly populated, especially for a country with so much arable land & relatively mild climate.

Ever been to the Netherlands or Belgium? They are quite lovely. Both also have a population density well in excess of 10x the US's.

Lots more people can fit in the country without negative effects.

But the areas that have seen job growth in the last 20 years are highly concentrated in areas that are about as packed as most of Western Europe: LA, SF, Boston through DC, and about a dozen other massive metro areas. The vast majority of available land (from the Mississippi to the Pacific and Alaska) is uninhabitable or agricultural and without jobs.

All I know is that where I live we already have way too much traffic, lack of affordable housing, and the lowest labor participation rate in decades. So by what metric does increasing population help those of us who live here (besides companies who love cheaper labor)?

    So by what metric does increasing population 
    help those of us who live here

   areas that are about as packed as most of 
   Western Europe: LA, SF, Boston through DC,
   and about a dozen other massive metro areas.

The US is sparse in any meaningful metric.

Also this part is important: "yearning to breathe free" is quite different from "yearning to establish a global Caliphate".

There's a big spectrum of behavior towards a political outcome between "opposed with deadly force" and "supportive with deadly force". Most Germans in 1940 wouldn't personally gun down Jews, nor even directly participate in organizing such a thing. But nor did they didn't oppose it with force, or energetically ensure it didn't happen.

Of course most Muslims aren't "scheming" to establish a caliphate, but they wouldn't oppose it the way you or I would.

This is an obvious reality that people just don't like to acknowledge.

They are for the vast, overwhelming majorly part, just normal people not unlike natives of the same social class. yes, if you compare the "typical" working class muslim to professional yuppies they come across a lot more conservative but not more so than the local-western working class.

And the muslim professional class (the doctors, engineers, lawyers, etc among them) are similarly not very different in this aspect from the local-western professional yuppies.

I think the discrepancy in perspective is that most yuppies don't otherwise notice the native working class.

That said, core-image-sato used to be just a simple demo image. In my old build system, we would build the Arago Project for a TI SoC every night and it would take a few hours but that included a lot of the DSP code as well which was really slow too. So a couple of hours on average is my guess.

So, you are right that visual programming doesn't represent how a computer software works.. But it's exactly how computer hardware works.

There are physical and spatial constraints in efficient implementation on FPGA's. Although I don't use them, I saw plenty of examples in my research of people looking at them visually and changing representations to make them more compact or something. Modifying the physical layout outperformed whatever the initial synthesis was.

Yes, visual tools for manipulating physical aspects of the design are used, but there is little to no abstraction there like a language provides.

In fact, my sentiment extends to hardware design, which is why I've been toying (and building real stuff for work) with SKiDL lately, a Python extension that allows for text based schematic capture for printed circuit board design.

Of course, the actual routing of the traces still must be done by hand. However, during schematic capture, instead of drawing the same Zener diode input protection 100 times with a mouse, I just call the code that builds it in a loop.