I think the "must program outside work" thing will fade once that generation (mine) start getting married and/or having kids.

The next generation will rinse and repeat, though.

I do enjoy Blacken's contention that it's still expected after having kids. Clearly spoken by someone who doesn't have multiple kids in school and sports. Aside from the time spent educating* them and taking them to activities, you also have to spend time with them. I have several projects I'd like to get done. But, when I weigh my options between coding those things that I have an itch for and grabbing one of my kids and riding bikes down to the lake, coding never wins. If some employer finds that to be evidence that they don't want me, then I've also learned that I don't want to work there.

I used to think I understood what having kids was like. Then, I had kids. You simply can't speak to it if you don't have them.

* This shouldn't be underestimated. Public schools really don't teach kids how to think or even how to do math - they teach them how to pass the standardized tests on which the school's funding is dependent. You have to teach them this stuff yourself.

* This shouldn't be underestimated. Public schools really don't teach kids how to think or even how to do math - they teach them how to pass the standardized tests on which the school's funding is dependent. You have to teach them this stuff yourself.

I showed my GF this picture, and her response was "Absolutely accurate. My students are amazing at test taking strategies..."

I'm not a fan of coding assignments. I don't think they're super useful past a certain "tie your shoes" point; almost anything you give somebody is going to have to be kind of contrived and that can be a bit rough. I prefer to talk to candidates--maybe ask a few baseline FizzBuzz questions--and then just sort of see what gets them to light up. I find that getting somebody who'll talk your ear off about this kickass project they did and the problems they had with it--without you prompting them very much--is frequently a great indicator of who has "the stuff". (It also selects for people who are at least somewhat social, which is a better cultural fit for the sort of environments I like.)

Trust me, coding assignments are useful. The distance between the best candidates and the worst candidates is enormous. And there's definitely correlation between performance on the coding assignment and performance on the job.

And even if it weren't useful past the "tie your shoes" point, it would still be useful. At least you weed out who can read instructions and who can't. And the amount of people who apparently can't read instructions is amazingly high in the pool of applicants for senior dev positions!

I do enjoy Blacken's contention that it's still expected after having kids. Clearly spoken by someone who doesn't have multiple kids in school and sports. Aside from the time spent educating* them and taking them to activities, you also have to spend time with them. I have several projects I'd like to get done. But, when I weigh my options between coding those things that I have an itch for and grabbing one of my kids and riding bikes down to the lake, coding never wins. If some employer finds that to be evidence that they don't want me, then I've also learned that I don't want to work there.

I used to think I understood what having kids was like. Then, I had kids. You simply can't speak to it if you don't have them.

* This shouldn't be underestimated. Public schools really don't teach kids how to think or even how to do math - they teach them how to pass the standardized tests on which the school's funding is dependent. You have to teach them this stuff yourself.

My daughter is also 4 months old, though somehow I'm finding time to slowly continue developing the product for the business I'm trying to start. I think you just have to be willing to code in 5 minute increments, rather than multi-hour sessions.

That said, the only reason I'm trying so hard to make it work is that the eventual plan is to go into business for myself, which means getting to spend more time with my family.

My daughter is also 4 months old, though somehow I'm finding time to slowly continue developing the product for the business I'm trying to start. I think you just have to be willing to code in 5 minute increments, rather than multi-hour sessions.

I do enjoy Blacken's contention that it's still expected after having kids.

I didn't say that. I said that the best developers I know and the developers I'd jump to work with again exhibit no trouble doing both, so selecting for that is a good idea.

"Parents" aren't a particularly noteworthy class of candidates and your Parental Mystique Engine doesn't make you better able to build good, maintainable stuff. I don't care if you have kids or not, I don't care what car you drive, I don't care if you live in a cardboard box (as long as your cardboard box has a shower and deodorant). I care if you can hack, and most people I've worked with or interviewed who don't write code on their own time, whether they're 22 or 50, can't. Which is why, as I said, it's a useful filter. It's a heuristic. It filters out some hits, but it filters out a lot more misses. To this end, I also won't look at somebody whose primary language died in the 90's, either. Those folks don't have a VB6 Mystique Engine, though, so they're not very loud.

How exactly does your everday Joe Programmer contributing to an open source project work?

Can anyone just check in changes? Is there a review process?

It depends on the project. Generally if you are just fixing a bug you can just submit a patch (plus minus mandatory tests). If you want to add functionality, most projects prefer that you write a proposal to the mailing list before you just dump a big patch.

Either way, someone else is going to have to check in your patch. No one allows random people write access to the project repository.

It depends a lot on the project--some of them are set up in ways that make it easy to contribute changes. Projects on Github with automatic testing servers are the easiest to contribute to, I think, because the maintainer doesn't have to worry about whether you're breaking lots of stuff. They can inspect your changes, make sure nothing is obviously wrong, and if the tests all pass then it's good to go.

On Github it's very easy to submit a minor patch--you just edit the relevant file(s) and submit a pull request. The project maintainers will review your code and accept or reject it. If they reject it they'll probably give reasons why (insufficient test coverage, doesn't conform to style, etc).

Good projects have documentation on contributing, and ideally they'll have a list of beginner projects that need to be done--relatively simple stuff that no one has got around to, but will get you exposed to the code base. Those projects can still be rather involved, though. If that's too much, there are always bugs to track down.

I haven't done a whole lot of contributing, but I have tracked down a couple bugs in libraries I've used (because they were biting me), and submitted tickets and sometimes patches to fix them (if I could figure out the best solution). It's easy to contribute minor fixes and it gets you a little bit into the code.

Bigger projects can be harder to get in to (and the older ones sometimes use SVN, to boot). You have to start reading the dev mailing list and reading a lot of the code before you can contribute anything.

TripAdvisor tried to get me to sign such an agreement when I started. I asked them to reconsider and they gave me one without that shit in it without a word of complaint. No Purple Hearts for self-inflicted wounds, yeah?

Yeah, I'd cross that shit the hell out. No way a company owns stuff I do on my own time that isn't related to my day job. Even if I didn't plan on doing any of my own work, I refuse to work at a company that thinks it own me. Fortunately we work in a field that affords us the luxury to make such demands.

So recently I've been interviewing lots of devs for a couple of very senior positions (10+ yrs experience minimum) for a Java/OOP based position. I like to see how well people know fundamental data structures, it's not a deal breaker if they don't know them, it's info to add to the pile for an overall evaluation.

The question is simple (imo), on a whiteboard pseudo-code a forward-only linked list and explain what you are doing as you go. This question is meant to tell me a couple things, do they understand the data structure at hand, do they understand how an implementation would look and can they communicate an idea to me well.

What I'm finding is that a very small number of people actually know how a linked list differs from an array and they certainly couldn't code one. More dismaying than that, nobody has yet to tell me "I don't know". That would be an OK answer, at least then I can move on to other areas that they might shine better in. Instead, they fumble around and try to create a class with an embedded array and use that (2 people have done that).

Is this question unfair? Should I know expect people with 10-15 years of experience in C++/Java/C# to know this? I thought the question was "easy" and would let me see how they handle explaining things. It wasn't meant to be a trick.

It's your interview so it's not really unfair, but you might ask yourself if it's irrelevant. People coming from a background in Java/C# are most likely working on enterprise apps and spend their days solving different kinds of problems.

I'm in a senior position (granted, I don't have 10+ years) and come from what was originally a non-CS background. I have to do interviews sometimes and I wouldn't ask this question, even for a senior dev. Why? Because it doesn't address any problems we're actually trying to solve. We have quite a few devs working on our cloud app and the problems we are usually trying to solve on a daily basis are typically how to structure our code to be flexible, recyclable, and testable. We also try to figure out how to store and retrieve data as efficiently as possible as the amount of time we spending going to and from our datastore makes the speed difference between arrays and linkedlist in their best uses look pretty irrelevant. I imagine these are the types of problems that most senior devs are facing. I'm also looking for people who can learn and are creative. I ask questions like:

What are some ways that you can come up with that multiple users can work on the same document, persist it, and not overwrite each other's data? Here's a list of objects and how the reference each other, now I need to add this new feature that does this. How would you alter our existing entities and what new entities would you create to make this happen? Why would you structure them the way you have?

You get the idea, I'm more interested in that the candidate be able to look at relationships and map out in their mind how the objects relate to each other and how the system works and come up with creative solutions if that system needs to be changed. I'm also interested in how they might reduce datastore operations to the bare minimum (we are on GAE). These are the types of problems that we face on a daily basis, problems dealing with race conditions, datastore access, and inflexible and bloated code (especially true if you are hiring them to work on an old code base). Maybe it's just me, but I don't think my group would benefit from having another person who knows how to write a linked list implementation and, for us, it wouldn't be a very efficient use of time to do so.

I've thoroughly convinced the traditional CS people on my team of the wisdom of my questions as well. We're far more interested in how you would construct your solution to a problem dealing with many moving parts than how ability to write another quicksort algorithm. We simply never do the latter in our actual jobs.

I've thoroughly convinced the traditional CS people on my team of the wisdom of my questions as well. We're far more interested in how you would construct your solution to a problem dealing with many moving parts than how ability to write another quicksort algorithm. We simply never do the latter in our actual jobs.

Your post reads as if there needs to be some choice between one or the other and there's not value to both. You're right that enterprise development doesn't often involve writing a quicksort or even implementing a linked list, but that's not the point of those questions.

Your post reads as if there needs to be some choice between one or the other and there's not value to both. You're right that enterprise development doesn't often involve writing a quicksort or even implementing a linked list, but that's not the point of those questions.

Then what's the point to asking someone to write a linked list implementation when the job is a senior level position in an enterprise environment? Is the ability to write a linked list a good proxy for measuring how they think about enterprise-level problems and solutions? Imagine someone who has been working on enterprise software in Java or C# for the last 10 years. Imagine they don't have a traditional CS degree. Do you think sitting them down and asking them to write a linked list, especially phrased as such, when they haven't written one in 10 years or may have never written one is a good test of their abilities? I always thought that my interview questions should allow me to determine how they think about problems my organization actually faces. Being that my organization works with a backend that not many people have used, I've often given them assignments to make a small app of their choosing using GAE. It allows me to see how they think about generating object models and how to create those models for consistency and latency. It allows me to see how they organize data and how quickly they learn. It's just my opinion here, but I feel I get more data from this than asking someone to do something that they probably haven't thought about in a decade.

What do you mean by "enterprise"? From the list of tasks your devs routinely work on, it seems their domain is writing CRUD apps, and in that case, asking someone CRUD-related questions and not CS questions is reasonable. But it's common in enterprise apps to have to deal with technicalities like scalability of data structures, efficient memory usage, and concurrency. These topics draw on CS theory, and so having a solid foundation is important. I'd expect someone in a senior dev role to be able to answer questions on these topics in depth. And I wouldn't expect a senior dev to be spending much time on writing data objects.

What do you mean by "enterprise"? From the list of tasks your devs routinely work on, it seems their domain is writing CRUD apps, and in that case, asking someone CRUD-related questions and not CS questions is reasonable. But it's common in enterprise apps to have to deal with technicalities like scalability of data structures, efficient memory usage, and concurrency.

We have to deal with all of the issues, especially since our app is a cloud-based collaboration type apps. I'm very interested as to how users might manage race conditions and entity group contention (transactional writes limited to about once a second per entity group). GAE also limits memory on appspot instances and we ensure all code can run on F1s, a limitation far beyond what most face. I'm not sure asking someone to write a linked list is a good representation of how they would deal with these issues, at least in our case.

Quote:

These topics draw on CS theory, and so having a solid foundation is important. I'd expect someone in a senior dev role to be able to answer questions on these topics in depth. And I wouldn't expect a senior dev to be spending much time on writing data objects.

I expect a senior dev to be able to recognize these problems and come up with creative solutions, which in our case is highly related to the structure of our entities. What I wouldn't expect is our devs to be rolling their own implementations of linked lists.

At this point I'm about 95% convinced the people in this thread claiming that they can do senior-level tasks effectively without being about to write a linked list are victims of the Dunning-Kruger effect. If you can't reason your way to a trivial linked list in, like, two minutes, the claims that you have the chops to do a good job at anything more complex are setting off every bullshit alarm in my house.

Hrm, that makes me wonder whether one could get away with asking interviewees "Have you heard of FizzBuzz?" and if they can describe it, assume you needn't ask them to implement it. Recognizing it is probably a good proxy for passion about programming, in as much as they read about it in their off time. The trouble is when it makes its way to interview cram sites/books/trainers/etc. The community of engaged developers just needs to keep developing new trivial tests whose names can act as 'shibboleets' faster than the lazies [1] can keep up.

[1] Edit: I don't mean anyone who doesn't read about programming in their spare time, as lots of people note they don't. I mean people who have never learned to be competent programmers, and would rather fake their way along instead of improving themselves.

The value of FizzBuzz, assuming they didn't just memorise it (which is a reason to use something similar, but not identical) is to check they can't actually write really basic code, from the off, without a bug.

If they can't do that, why on earth would you want to hire them as a programmer?

If you cannot implement a linked list, (intrusive, non generic, node based... I dont care) then how are you likely to be to actually implement some more complex object graph of the sort you describe without a bug?A linked list is the most trivial reference (pointer, managed references, discriminated unions you name it) based arbitrary sized thing you can do!

I have worked with people in the (dim and distant) past who's approach was "eh, I think it's right let's try it", and who could then resolve the screw ups, often by layering various checks in inappropriate, but adequate locations. I have no desire to work with them again, and I'm sure my employer wouldn't want the cost associated with that sort of screw up.

We aren't asking for anything like quicksort (the naive implementation of the partition element selection having nasty overflow behaviour for example), some recursive algorithm with lots of state or anything where you need to break the problem down into serious chunks. This is so trivial to do, even for a decent programmer *without* a CS degree. If done as a class each method in there is going to be a few trivial lines, mainly dealing with the empty list.

If the candidate knows it great, a fast indication of it and move on. If not then it's going to check they can take a trivial specification, and implement a solution, and if they take longer than 5 minutes then that's a really bad sign.

Exactly. Quicksort is hard. Correctly implementing a hash table is hard. A linked list is trivial.

I find myself skeptical of the idea that someone can "forget" how to do it. I think more likely is that they never knew how and that belies some problems in their foundational knowledge. This isn't acceptable in a senior engineer, because their job (everywhere I've ever heard of, anyway) is in part to instill foundational correctness in their juniors.