They could have given me more work, put me on new projects, etc., like I kept asking to be done, but instead they just wanted me to figure out some way to bill the client for 60 hours a week, and not call it "bug fixes" or "new features", because the client wasn't paying for it. That left data entry, which I had automated from a whole day to 10 minutes. They wanted me to go back to entering data by hand.

I would have quit then, but I didn't want to give them the pleasure. A flood had recently destroyed all of my stuff and I used the insurance check to get out of debt rather than replace the lost stuff, so I suddenly didn't need money for a LONG time. It's funny how easily debt can make you a compliant little slave towards people who want you to perform bullshit tasks.

I've been freelancing ever since, making twice what they paid me for only half a week's worth of work. And the flexibility of the freelancing enabled me to pursue a long-distance relationship that eventually lead to marriage. So I say getting fired was the greatest thing that ever happened to me.

It's an interesting read. This book was written in 1880, and if not for the dated writing style, would fit right in to the modern day self-help genre. It really helps underscore the idea that there's "nothing new under the sun."

[0] http://www.gutenberg.org/files/8581/8581-h/8581-h.htm

And of course your thoughts were "I'm going to work extra hard initially, which will make a good impression and get the product built on time and all the tasks automated, and then I can coast and it will still be worth their money."

The manager doesn't care because when your code starts rotting due to bad maintenance and badly added features (or just the fact that nobody has bothered taking it over), he'll already have been promoted or changed companies.

It means I'm not making as much as I could be, but it's not their fault I agreed to the arrangement 3 years ago.

I had one interview where the interviewer simply showed me a printed page of code, and asked me to talk about it.

I spotted a few problems and debatable constructs, and we had a good 3 minutes discussion.

Since at least I spend more time reading code than writing it, that felt like a truer test of my abilities than many of the coding tasks.

PS. Yes, I got the job.

I'm definitely stealing this trick.

(OPC also refers to one's own code that when you can't remember wtf you did and the comments aren't useful)

The problems were those you see daily in production code. Misleading names. Duplicated constants. Overly complex constructs. Off by one errors. Maybe a resource leak when exceptions are thrown. Etc.

I think there is. Show the candidate some bad code. Not WTF code, but something you wouldn't be proud of but is realistic. Bonus points if you're comfortable enough to pull this out of your own production system. Ask the candidate about adding some functionality, but be clear that cleanup and refactoring changes are fine (even encouraged). The conversation should be enlightening.

What I like most about this is how close to reality their interview model is. Less than stellar equipment, legacy code, and a maintenance task... just a normal Monday.

Good times.

Of course, that's not true at all. But giving someone a defective-but-not-entirely-broken tool can be a clever way of seeing how they work around problems or how they deal with frustration. Joking aside, we once let a guy go during his 1 week probationary period because he got a little too angry at a slow server. It's a valuable test.

If the "w" key weren't working I'd copy-paste "w" characters from elsewhere in the document, or bring up the on-screen keyboard. Writing bastardized code -- for (;;), really?! -- would be a huge negative against a candidate. And, of course, if a company really didn't have a working keyboard to provide me with, I'd never work there in the first place, because if they can't even provide working peripherals there's no limit to what else they might skimp on.

I actually have three keyboards at my desk right now -- one with Cherry MX blues, one with Cherry MX browns, and a Model M. No way in hell would I ever write code without "w"s.

    #define ever (;;)

But then computers were not provided, each school had to travel with a computer for each student. So around 1993/94 a friend of mine, who also had some terrible medial situation at the time, and was quite weak decided to compete, and to make things worse for him - his spacebar wasn't working. I think he did a lot of presses of Alt+32 (or was it Alt+20 - I haven't used this combination of entering ASCII codes in a long time). He finish pretty good for the situation and keyboard problem he had, and next year when he was healthy and with good keyboard he did just awesome!

Unless you're from a very poor country there is no excuse for not having a working keyboard.

I don't know if that was part of the test, but if it was, it's worse than the big blue chip corps asking about the number of piano tuners. Which actually can be valuable at understanding how one reasons about unknown problems/areas.

About the server being slow, well I don't know the magnitude of the slowness or the anger, but unless you're a ramen fueled startup there is no excuse for having slow machines. It's management failure. It's a waste of developer time. Instead of coding the dev is having to deal with stress inducing constant 5 second hiccups or similar things.

Put yourself in the interviewee's shoes. Do you really want to work in a company that can't conduct a proper interview and has broken/slow hardware?

And yes, I do use vim and I do like w very much.

Slow is relative. The employee in question was trying to figure out why a remote server was experiencing extreme slowdown. He ssh-ed in, but he was able to type far faster than the beleaguered remote could echo his keystrokes. So he needed to just carefully type his commands, wait for them to appear, and then press enter. Instead, he typed angrily and too quickly, swore at the connection, and eventually started slamming his keyboard in a fit of pique.

It was a totally reasonable real-world slow machine problem, and a totally useful insight into the mindset of a potential new employee.

Not egregious at all. We're developers, sometimes we have to walk into an annoying situation and deal with it like adults.

>Joking aside, we once let a guy go during his 1 week probationary period because he got a little too angry at a slow server.

If someone's approach to a broken keyboard is some workaround instead of just asking for another keyboard it is a sign they handle problems very, very poorly.

[0] http://www.truthorfiction.com/trashingthewhitehouse/

(And then make a preprocessor run where \/\/ is replaced with a w)

I have a keyboard with a broken 'w' key myself, and I know exactly why that key cap died young. It sure wasn't from typing out "while".

It was a great interview experience though. One of the engineers commented that they gave the same task to other interviewees too.

I think this is a smart and lazy way to hire people :P No need to spend an hour in the room asking random questions, having awkward pauses etc. Just let the candidate fight with the codebase - lazy and simple!

The key was in how we presented it - we didn't want to come across as elitist jerks (but we probably did to some people), so we tried to soft-sell it to them and work it in gradually during the interview.

Some teams are like "Man, what idiot wrote this code! This is garbage!" (sometimes in other words). I can imagine they couldn't do the type of interview you're doing.

In your interview, you show them some bad code, ask them to change it, and if they start disparaging whoever wrote it, you can red card them before they start dragging down team morale.

Or, if they start wondering about 'how did this code get like this? are there other issues leading to the bad code?' they've got some strengths in areas outside of development.

The problem with this is that it doesn't let my personal projects be Play. If I'm writing something for myself, it's not going to be as clean and documented to the level it would be in the workplace. And why should it? It's supposed to be for me.

And if I'm learning a new technology, I'm going to be sloppy. I'm going to make mistakes. That's the very nature of learning-by-doing.

But in the real world of managers and companies looking for reasons to say "no hire", I have to assume that every public checkin I do is another potential "no hire" justification. Which means if make all my checkins public, I have to treat my personal projects as Work, not as play. Which is an excellent way to burn out.

Or I just give you a curated look at the final product. Which ought to be enough.

Actually I hold myself to a higher standard when writing open source - A) because I know everything is open to the world, and B) because I'm not under tight time constraints.

Nonetheless, there's no perfect project, and any employer that looked at a github project and was needlessly, ridiculously picky or made a presumption that there shouldn't ever be mistakes would end up just not hiring anybody at all.

>And if I'm learning a new technology, I'm going to be sloppy. I'm going to make mistakes. That's the very nature of learning-by-doing.

Only idiots expect a perfectionist. Thus if you try to make every commit an exercise in perfection you're only selecting out the idiots.

I'd actually far rather see incremental improvement (in code quality, documentation clarity & commit messages) than sheer perfectionism.

Also bear in mind that no matter how interested the employer is in you, the chances of them taking anything but the most cursory glance at anything beyond HEAD is very small.

But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he/she has motivation to do best. If the employer can just ask the candidate for that project, and the candidate can show that project in a public or private repository, this would give really important insights to the employer about the candidate which would be beneficial for that both.

Also, this doesn't mean that the candidates who doesn't have public repository to show have any disadvantage, they are at the same point. Its just that the candidate who is able to provide a project of his choice through public repository would be a few points ahead other candidates.

For an experienced developer, that would be a workplace project, which you probably could not see. Indeed, it _should_ be a workplace project; would you hire a professional developer whose best work is their personal project?

But if what you're saying is that the mark of an ideal developer is one who has produced a personal-time product of professional quality, where every checkin is to workplace standards, and has developed the project from conception all the way to release, again all on personal time, then what you're asking for is not a developer who also codes as a hobby, but a developer who (at least part of the time) works two actual jobs. One of which they do for free for portfolio development. I don't find that to be a reasonable expectation, even if it would give employers "important insights".

Were I to have such a project that I could show to people, it would be for a company that I had founded and as such despite my having the ability to show it, I would have absolutely no incentive to do so.

Basically if I had EXACTLY everything you purport to want in an employee I would be entirely unmanageable. Someone who has not only the skill and ability to turn out such a project but the motivation to do so on their own time is probably the definition of a founder. And founders are often terrible employees.

So while you're right that it would theoretically be better for candidates to share their codebases with potential employers, in practice I suspect that it rarely happens.

Then either start one or resign yourself to not getting the best possible tech jobs out there?

As a discriminatory practice it's probably one of the most benign. There's a low bar to putting open source code out there. You can write a simple project and put it out there in a couple of weekends. That alone puts you ahead of about 80% of candidates.

It's a way better discriminatory practice than the current default assumption that the best developers out there are white, male twenty-somethings.

don't you think that there's a higher proportion of white, twenty-something people who would have public projects (because they tend to have the most spare time)?

Don't you think that the over-worked CRUD programmer at an obscure insurance company wanting to get out because they are in a difficult situation (may be financially, may be race/background etc), would find it hard to have time for a public showing of their coding prowess?

No one is saying don't use public projects, but i would only consider them after other aspects, and certainly wouldn't cull people because of it.

Like I said: the amount of time you realistically need to get something out there is about a couple of weekends.

If you don't do public projects, then you start a few steps behind the other candidates. This isn't insurmountable, but the error bars are wider, making you a somewhat greater risk.

> I think open source development is virtuous and is something that I want to promote and encourage

Then pay them for it.

Though, even if it didn't mean I was getting a view into how they actually work, I'm okay with preferring public-minded people who give things back and make the world a better place through it. I try very hard to live by the motto "pay it forward" and I find it to be rewarding and pleasant to work with those who do likewise.

> Then pay them for it.

My last two employers did exactly that. Should I need to hire directly for my consulting adventures, I'll do it there, too. I mean, this reply makes no sense to me: why would I not?

In a recent interview, I spent 45 minutes pairing with a current employee. Our goal was to take a (contrived) piece of legacy code, clean it up, and add a new feature to it. I imagine it was a very telling experience for them, and I feel it was more useful than the whiteboarding we'd done before.

Hopefully we as an industry will keep iterating on this sort of interview.

Asking for some work to be done off site before an initial on site interview, where the potential employer is getting something of value, would be a much bigger red flag to me, personally.

Code reading: In <10 minutes, I can have a basic grasp on someone's ability to read, understand, and explain new code. Usually simple examples of <50 LOC in the language of there choice. I've used it a lot in phone screens (just providing URL to the code) and gained the reputation of being able to predict fairly well the quality of a code submission to a "take-home coding challenge".

Whiteboard: in ~15-20 min I can get a grasp on how someone takes a vague problem and works toward a solution and how they are to work with. I'm actually less concerned about code, and more about how they handle ambiguity, flesh out requirements, communicate issues, and think holistically without the distraction of a compiler/syntax-highlighter/etc. I think whiteboarding is slightly more about communication than coding and can provide a lot of context in a short amount of time. Of course, not all whiteboarding interviews are equal - I spent plenty of days complaining about certain whiteboarding interviews, and now I'm clearly biased to believe that mine take the good and leave behind [most of] the bad.

Code pairing. Takes ~1hr to understand and modify some piece of code in a meaninful way. (Maybe there are simpler versions - but in an effort to feel more "realistic", I've always focused on changing a requirement to the candidate's code submission). It's more realistic than whiteboarding, but it carries the [real-world] overhead of getting syntax right, finding docs for a specific function, and other surpries that come up (network issues, desktop crashes, editor problems, etc.). I've seen it work well when there are several interviews that focus on very different skills, but inevitbaly after such interview, I've often felt like I had a very narrow view of a candidate.

Point is, I've been modestly bringing these up during interviews when asked what I've been doing the past few years. It is always glossed over.

I don't think companies want or recognize that they want someone who will be able to handle these tasks. If they knew these tasks needed to be done, they'd hire for it, right?

Seems some of the most important things that can be done for a company may be hidden to the executive team.

Ultimately all you can really do is try and work your way into a situation where you have some kind of meaningful equity. Founder, co-founder, early hire, buy a piece of a company, whatever. That's the only way to really get rewarded for your skills; knowing enough about the state of the art to see what can be done better and also having the skills to see those projects through to completion and realizing the benefits thereof.

I wish there was a job title for "good all-arounder with knowledge of the state of the art in a role with substantial self-direction", but I think that's probably "founder" or something. Or "owner of a very small business" maybe?

That's the way I am drifting. I just can't seem to get in gear on my own. :(

Part of it is having trouble focusing on a single idea. Finding the right partner would help here: see #1.

Part of it is fluctuating levels of depression sapping my motivation outside, and sometimes inside, work. I have been fighting this for almost a decade. At one point several years ago the mere thought of doing things outside of work so reinforced how miserable I was in my day job that I couldn't get anything done.

I'm slowly working through my barriers. My most recent dip into the job market has demonstrated that the only way I am going to get the job I want where I want it is to make it myself, so I have renewed motivation to get moving.

I'd be interested in working on a project together (I have a recent "good idea" but it will need to be built ground-up). I don't have a lot of money, but I'd be fine with putting some capital down for hosting, domains, etc..

It would be very casual. No pay either way of course. Ownership is something to discuss.

For your first part, I feel everyone has that to some degree. You just have to do it. Email startups.

I have a couple of friends doing a startup in the same space in which I'm writing some software, and their software is nowhere near as far along as mine, yet I don't have anywhere near the "business development" that they do. I'm not there because it's too much work for one person and I've focused on the tech. Their tech isn't that great because it's too much work for one person and they've focused on the biz.

Aaaaah, I just don't know. They're pretty inexperienced, mostly just straight out of college. I'd like to find one person who is as passionate and experienced about business development as I am about software development. Instead, I mostly get contacts from guys who've worked in government offices all their lives, looking for a free programmer to boss around on their "1 in a million idea".

Some of it is selfishness on my part, too. I want as much ownership and control as I can keep, and I want it to be on my ideas. I've tried working on other people's ideas before and it just doesn't move me. I have a pretty clear vision of where I want to go, both tech and business. I guess I'd rather keep going slow right now than get side-tracked working on someone else's ideas.

If their current project ever tanks, they might be interested in coming on board with me. I think we're both just trying to see where everything we're currently working on is going.

There's no way to interview for what you're looking for, but compilers seem to require both great organizational skills and some algorithmic chops. there's enough complexity you can't hide lack of one side or the other.

Anyway, asking about building and enhancing a compiler seems like one of the ways to get insight about how people grow code. Every program is a seed. Is this the kind of guy that will end up with a mighty oak tree, or kudzu in 10 years?

Compilers have been developed by lone developers in isolation. Some compilers are only a few thousand lines of code.

Someone who can demonstrate knowledge of making a compiler could well be completely behind in their knowledge about language design. He or she shows how calculations are turned into a tree and then into code on a register machine (i.e. "for-mula tran-slation"). But no idea how to compile exception handling, closures, and doing advanced things with type (beyond just checks) and such.

That is to say, the bar for what can be legitimately called a compiler is quite low.

On the topic of languages, I'd rather interview someone who knows about a lot of modern language features and how they can contribute to the improvement of program organization, yet is foggy about the details of how some of them are might be compiled to machine code.

There is still "compiler worship". On a previous job, I fixed a code generation bug in gcc affecting MIPS targets. Everyone was talking about that: "like wow, he fixed gcc".

Writing a C compiler seems like one of those standard undergrad activities. If a programmer can make that work, they probably have sufficient organizational skills. It seems like real-time, distributed, multi user app development is a separate filter.

I guess it's the distinction between looking for someone who is capable of solving those problems vs looking for someone who has solved those problems.

If the threads have to stop, it's still concurrency in the sense that threads are stopped in arbitrary places (just like an interrupt can stop a task at any point in its execution and dispatch another task or whatever).

But the garbage collector isn't running concurrently with the threads.

I.e. I think the term "concurrent garbage collector" is understood to be in contrast with "stop-the-world garbage collector" not with "synchronous garbage collector as a library function in a single-threaded virtual machine".

But there are a number of algorithms that most people would probably consider "real GC" that don't stop the world. Modern Java GCs use the train algorithm [2], which bounds pause times to some arbitrarily-sized constant. Erlang per-process heaps [3] also give good soft-real-time characteristics.

It is theoretically possible to run the whole GC in a background thread (eg. while a GUI is idle). Both the JVM and the CLR have options for this [4][5], but they're only useful for workloads with large pause times (eg. GUI apps, lightly-loaded servers) and so aren't enabled by default.

[1] http://researcher.watson.ibm.com/researcher/files/us-bacon/B...

[2] http://www.ssw.uni-linz.ac.at/General/Staff/TW/Wuerthinger05...

[3] http://prog21.dadgum.com/16.html

[4] http://www.oracle.com/technetwork/java/javase/gc-tuning-6-14...

[5] https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110)....

A compiler doesn't have that. It's blissfully old-fashioned, really: read files in, write files out -- no interruptions or real-time requirements. You could do compilers on punch cards.

In a way, the compiler is the most complex piece of software that you could imagine in 1960... But software has moved on and faces a different kind of complexity.

Hence I'm not sure if asking about compiler architecture is really representative of the organizational skills needed by today's software engineering.

The degree of asynchronicity is low, I agree. The most significant was just interrupting compilation on user request. But the complexity was not trivial.

These days I work at a startup on a full stack SaaS; C++, Java, Rails, and Coffeescript with as few blocking browser actions as possible. It is far less complex than compiler work, but it pays better. I've never had to debug OS code to diagnose runtime library issues in this job; nor write manual structured exception handling. I haven't had to try and build stack frames dynamically to implement reflection calls, nor unpick stack frames dynamically to implement virtual method interception. The relative complexity of potential races with SQL read-committed, or writing UI such that it can't become inconsistent, really doesn't compare.

Ok, you can do more complex. I work on a compiler, which does it lazily. Transformations are per file and depend on each other. If something goes wrong, you print out the graph to figure out the problem. No idea what the benefits could be. Might actually be a good example, where it could have been simpler.

The nice thing about compilers, it requires a ton of code.

It's the kind of thing that any programmer can do (well good ones), and there are organizational tradeoffs to be made. There is no "right" answer, it's an opportunity to talk about organization. There are blind alleys that seem like a good idea, but turn out not to be. There are opportunities to merge and split passes. Some layers might want information from other layers, some layers might look very similar to other layers.

I'm pretty happy that I did what I did in school, but I wish that people didn't rely on the whiteboard situation as much. If I can talk about what I did to find the edges and corners of a piece of mail in a picture, and how I used that I can rotate the image to be square and then crop the image so that all you see is the letter and not the background, perhaps my ability to do some kind of whiteboard coding exercise isn't terribly relevant. The odds that I can answer questions about how I developed such an algorithm while still not being able to actually write code are pretty small.

You're hiring me to solve business problems and last I checked FizzBuzz or reversing a singly-linked-list aren't business problems. End Rant.

Also we simply need to teach people the things that we want them to know after we hire them instead of looking for perfect fits.

I think one reason why what you did doesn't happen more often, though, is because they wouldn't have the freedom to reimplement in a language they felt was more suitable.