15 ms·

This is incredibly true. I once turned 60kLoC of classic ASP in VBScript into about 20kLoC of python/django including templates. And added a bunch of features

This is incredibly true. I once turned 60kLoC of classic ASP in VBScript into about 20kLoC of python/django including templates. And added a bunch of features that would have been impossible on the old code-base. It turned the job from hellish (features were impossible to add) to very nearly boring (there wasn't much to do anymore). So with this newfound freedom I built some machines to automate the data entry and once that got rolling the job got even more boring. Because it was a small company with a very long learning curve the owner didn't let people go, but instead kept them on so that he didn't have to hire and train new people as growth accelerated. But with all the automation some slack found its way into the system and problems that had normally required me to stop working on my normal job and help put out fires now got handled by people who weren't stretched a little too thin. Sadly there's (seemingly) no way to interview people for this ability so we're stuck with the standard "write some algorithm on a whiteboard" type problems that are in no way indicative of real world capabilities.

jfoutz 11y ago
"Tell me about writing a compiler" 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?
- pavlov 11y ago
  In typical software today, much of the complexity arises from interactivity. There are user actions, network events and all sorts of contingencies that make the program flow non-deterministic. 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.
  - jfoutz 11y ago
    Compilers are a nice example because they require a lot of code, and all the code has to be right. If you can't impose enough organization there, you don't have a chance at getting a distributed event driven system to work.
  - barrkel 11y ago
    I used to work on the Delphi compiler, for 6 years or so. That compiler was not a simple function of file input to file output. It lived in an IDE. It had to do incremental compilation, throwing away the compiled version of an in-memory file and recompiling it, but avoid recompiling the whole world of downstream dependencies if not necessary. It had to provide code completion, which meant parsing and type analysis of a file, but skipping codegen, with reasonably sophisticated error recovery. It had to provide the debug expression evaluator, which lived intermixed with the constant evaluator, and needed to know how to set up calls to symbols in the program being debugged. And it had to do all of these things in a long-lived process, with no memory leaks and high reliability. 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.
- qznc 11y ago
  Compilers are simple. They are organized as a pipeline. Frontend, middleend, backend. In more detail: lexer, parser, semantic analysis, optimzation 1 to n, instruction selection, scheduling, register allocation, assembly. 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.
  - jfoutz 11y ago
    Yes, but there are a bunch of tradeoffs. do you try to lex the floating point format, or push that back to the parser? Do in introduce an extra pass for constant folding or do you try to shoehorn it into AST generation in the parser? 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.
- kazinator 11y ago
  Compilers aren't real-time, distributed, multi-user, ... basically anything that is hard from a software engineering perspective which includes deployment and testing. Compilers have reproducible test cases (if they don't, that is a bug in itself). You can catch regressions in a compiler with an automated test suite, and bisect their version history to see where it was introduced. Bug reports from the field tend to be easy to confirm. A compiler isn't going to work well when it has 10,000 users, but mysteriously spiral to a crash when there are 10,100. 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".
  - jfoutz 11y ago
    If the point is looking for organizational skills, i think compilers are legitimate. They're big complicated beasts. Sure, some people in isolation can make amazing things with a few thousand lines of code - I think most people would be happy employing Fabrice Bellard. 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.
    - dpark 11y ago
      "Tell me about writing a compiler" seems mostly to be a question intended to restrict your hires to fresh grads who took a compiler course or if you're trying to poach compiler writers from another company. You're not likely to get a very useful response from someone who hasn't written one recently or at all. You could just as well ask "Tell me about writing a POSIX shell", or "Tell me about writing a browser", or basically any "Tell me about writing a <FOO>". It's not a useful question unless you're specifically hiring them to write a <FOO>.
odonnellryan 11y ago
I've done a few similar things at my previous employer. Basically, taken it upon myself to write internal reporting applications, to much success. I've also done some other small things (AHK, etc..) which worked out well. 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.
- msandford 11y ago
  I was fortunate to be a valued player on a small team. But what you're talking about is basically trying to hire yourself in as a tech exec when you're just applying for a job as a programmer. I think that's because management (generally) doesn't really want to hear that they've got a blind spot even if they do. 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?
  - vonmoltke 11y ago
    > 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. :(
    - odonnellryan 11y ago
      Why's that? I've been thinking about starting my own side company. It is a lot of work!
icbat 11y ago
> Sadly there's (seemingly) no way to interview people for this ability 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.
- cpursley 11y ago
  Yeah, a combo of a scanning a candidates github projects and some doing some pairing on real code is much better than whiteboarding.
  - JustSomeNobody 11y ago
    Except not all of us keep our stuff on github.
    - krapp 11y ago
      And some of us use Github as a rubbish bin for half-baked projects and hobby code, and not a resume.
- Balgair 11y ago
  Yeah, that is cool and lets you get a hand on the job and a feel for what you'd be working on, but it makes me a little wary. Doing work for some employer without getting paid is a red flag. It's not a total klaxon blaring, but it does raise eyebrows.
  - Gracana 11y ago
    Spending 45 minutes working on "a contrived piece of legacy code" with an employee competent enough to evaluate your effort doesn't sound to me like "doing work" for the employer. I get what you're saying, though... I think if the evaluator were incompetent and you were solving an important problem for them (things that would be pretty obvious), it would be an awful interview. But hey, that's 45 minutes well spent if it shows you for sure that you wouldn't want to work there.
moron4hire 11y ago
I got fired from a job because I had done this and they couldn't figure out how to keep me billable after that. Well, I got fired because I would "show up late" and "leave early" because there was nothing else for me to do (even though I was actually pulling a full 40 hours, they were expecting 60 out of people). 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.
- msandford 11y ago
  I read this story and had a bit of a chuckle. And then I read your username and had a real laugh. Thanks for that!
- xacaxulu 11y ago
  Great takeaway. Debt tends to make 'good little workers'. Stay free my friends!
  - moron4hire 11y ago
    I think P.T. Barnum wrote the prototypical "Self-help: finance/entrepreneurship" book in "The Art of Money Getting: Or, Golden Rules for Making Money" [0]. A lot of it sounds like the stuff you hear getting hammered to death on motivational TED talks. It's a pretty short book and he doesn't go into too much exposition on a lot of the issues he addresses, with the exception of debt. He probably spends half of the already short book on talking about the evils of debt, especially debt put into things that aren't assets. It's not the debt that is the problem, it's the mindset you have to be in to take the debt, the mindset that the debt puts you in, and the mindset of the type of person that continues to use debt, especially destructively. There are some closely related issues with spending money, which tie in nicely. 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 http://www.gutenberg.org/files/8581/8581-h/8581-h.htm
ska 11y ago
> Sadly there's (seemingly) no way to interview people for this ability 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.
- vijayr 11y ago
  This happened to me once. I went for an an interview at a huge real estate company. They had a chat with me for exactly five minutes, then gave me a computer (an old one, with keyboard not working properly) and some legacy code. I wasn't asked to fix it, but I was asked to make a small change and given half hour for it. That code had no documentation and no comments. Then 5 more mins to explain what I understood about the codebase - no questions, just me talking about the codebase as much as I understood in that half hour. The whole thing took like 45 mins or so in total. No whiteboard questions etc. And they made an offer.
  - machinshin_ 11y ago
    Did you accept?
    - vijayr 11y ago
      No, I had another offer that I took. I'm an average programmer and was able to do the task easily, but that codebase really scared me. Plus the other job was to build something from ground up and I really liked the CTO, so I took it. They were primarily hiring someone just to keep it running than adding new features. 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!
  - w1ntermute 11y ago
FLUX-YOU 11y ago
The interview simply doesn't have the time required and both sides will have to be okay with spending more time evaluating each other if we want to move forward. 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.
JohnTHaller 11y ago
Back when I worked corporate I loved when I got time to make the apps I was responsible for better. Getting free time to refactor an outdated procedure written by four different developers who'd all left that just barely worked, albeit slowly, was something I enjoyed. As was getting a couple days for minor bug fixes and small feature adds. I happily had the freedom to sit with the users directly and ask them about how they used the software in their jobs as part of those few bug-fix and feature days for the "late lifecycle" apps (read: they worked OK, so almost zero time was spent updating them other than major crashes and no major versions were scheduled). So, I got to implement unique features based on how they needed to do their jobs that previous developers hadn't thought to add because they'd only done the official 'users get together and ask for features, department head filters it, hands it to our department, department head filters it, assigns it to one of us to do in spare time not working on more important software' thing.
- duderific 11y ago
  That sounds really nice. At my current position, we never get time just to refactor, though supposedly that time is "just around the corner." We are always cranking against tight deadlines. Consequently, we end up with some pretty jacked up code, since as the saying goes "you never get it right the first time."
  - JohnTHaller 11y ago
    It was. It wasn't as often as I'd have liked. But it was nice to have once in a while. And the users loved it. It's amazing how much someone likes a developer sitting down next to them applying their full ability to try and make their job better.
deleted 11y ago
[deleted]
BurningFrog 11y ago
> Sadly there's (seemingly) no way to interview people for this ability 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.
- wpietri 11y ago
  I had an interview recently where we did something similar and it was awesome. They had picked an especially good example: the code was small enough that it didn't take long, but it has a variety of sorts of badness, from coding errors to bad names to bad method grouping to logical errors. I'm definitely stealing this trick.
  - azundo 11y ago
    I wrote one of these for my work as well. Definitely our go-to for getting a sense of how well people can understand others' code and how they think about data modeling/complexity. A very small initial page of code can go a long way.
- HaloZero 11y ago
  I'm curious, how complex was the code. I would love to try this out at some point. Did it fit all in one page?
  - BurningFrog 11y ago
    I think it was a class of 30-50 lines of Java code. 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.
- fezz 11y ago
  Agreed, being able to read and reconstruct models from OPC (other peoples code) is such a big piece of coding but hardly ever a part of the interview process. (OPC also refers to one's own code that when you can't remember wtf you did and the comments aren't useful)
anowell 11y ago
There's a lot of hate for whiteboard coding. Having been on both sides of whiteboard, code reading, and code pairing interviews, I like them all for different reasons: 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.
s73v3r 11y ago
You could give them some mild spaghetti, and ask how they'd try to improve the code. 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.
msandford 11y ago
Something I just realized that I wanted to write, but didn't, was that I generally don't do well in whiteboard interviews. I've done a few and it's always algorithms that I didn't learn in school because I was EE/CE (not CS) and while I took Data Structures and Algorithms, I didn't take Advanced Data Structures and Algorithms or anything like that. I took two compilers classes (which were great!) and a pile of classes dealing with hardware and the practical realities of computers rather than the theoretical aspects. 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.

jfoutz 11y ago

"Tell me about writing a compiler" 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?

pavlov 11y ago
In typical software today, much of the complexity arises from interactivity. There are user actions, network events and all sorts of contingencies that make the program flow non-deterministic. 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.
- jfoutz 11y ago
  Compilers are a nice example because they require a lot of code, and all the code has to be right. If you can't impose enough organization there, you don't have a chance at getting a distributed event driven system to work.
- barrkel 11y ago
  I used to work on the Delphi compiler, for 6 years or so. That compiler was not a simple function of file input to file output. It lived in an IDE. It had to do incremental compilation, throwing away the compiled version of an in-memory file and recompiling it, but avoid recompiling the whole world of downstream dependencies if not necessary. It had to provide code completion, which meant parsing and type analysis of a file, but skipping codegen, with reasonably sophisticated error recovery. It had to provide the debug expression evaluator, which lived intermixed with the constant evaluator, and needed to know how to set up calls to symbols in the program being debugged. And it had to do all of these things in a long-lived process, with no memory leaks and high reliability. 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.
qznc 11y ago
Compilers are simple. They are organized as a pipeline. Frontend, middleend, backend. In more detail: lexer, parser, semantic analysis, optimzation 1 to n, instruction selection, scheduling, register allocation, assembly. 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.
- jfoutz 11y ago
  Yes, but there are a bunch of tradeoffs. do you try to lex the floating point format, or push that back to the parser? Do in introduce an extra pass for constant folding or do you try to shoehorn it into AST generation in the parser? 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.
kazinator 11y ago
Compilers aren't real-time, distributed, multi-user, ... basically anything that is hard from a software engineering perspective which includes deployment and testing. Compilers have reproducible test cases (if they don't, that is a bug in itself). You can catch regressions in a compiler with an automated test suite, and bisect their version history to see where it was introduced. Bug reports from the field tend to be easy to confirm. A compiler isn't going to work well when it has 10,000 users, but mysteriously spiral to a crash when there are 10,100. 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".
- jfoutz 11y ago
  If the point is looking for organizational skills, i think compilers are legitimate. They're big complicated beasts. Sure, some people in isolation can make amazing things with a few thousand lines of code - I think most people would be happy employing Fabrice Bellard. 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.
  - dpark 11y ago
    "Tell me about writing a compiler" seems mostly to be a question intended to restrict your hires to fresh grads who took a compiler course or if you're trying to poach compiler writers from another company. You're not likely to get a very useful response from someone who hasn't written one recently or at all. You could just as well ask "Tell me about writing a POSIX shell", or "Tell me about writing a browser", or basically any "Tell me about writing a <FOO>". It's not a useful question unless you're specifically hiring them to write a <FOO>.

odonnellryan 11y ago

I've done a few similar things at my previous employer. Basically, taken it upon myself to write internal reporting applications, to much success. I've also done some other small things (AHK, etc..) which worked out well. 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.

msandford 11y ago
I was fortunate to be a valued player on a small team. But what you're talking about is basically trying to hire yourself in as a tech exec when you're just applying for a job as a programmer. I think that's because management (generally) doesn't really want to hear that they've got a blind spot even if they do. 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?
- vonmoltke 11y ago
  > 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. :(
  - odonnellryan 11y ago
    Why's that? I've been thinking about starting my own side company. It is a lot of work!

icbat 11y ago

> Sadly there's (seemingly) no way to interview people for this ability 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.

cpursley 11y ago
Yeah, a combo of a scanning a candidates github projects and some doing some pairing on real code is much better than whiteboarding.
- JustSomeNobody 11y ago
  Except not all of us keep our stuff on github.
  - krapp 11y ago
    And some of us use Github as a rubbish bin for half-baked projects and hobby code, and not a resume.
Balgair 11y ago
Yeah, that is cool and lets you get a hand on the job and a feel for what you'd be working on, but it makes me a little wary. Doing work for some employer without getting paid is a red flag. It's not a total klaxon blaring, but it does raise eyebrows.
- Gracana 11y ago
  Spending 45 minutes working on "a contrived piece of legacy code" with an employee competent enough to evaluate your effort doesn't sound to me like "doing work" for the employer. I get what you're saying, though... I think if the evaluator were incompetent and you were solving an important problem for them (things that would be pretty obvious), it would be an awful interview. But hey, that's 45 minutes well spent if it shows you for sure that you wouldn't want to work there.

moron4hire 11y ago

I got fired from a job because I had done this and they couldn't figure out how to keep me billable after that. Well, I got fired because I would "show up late" and "leave early" because there was nothing else for me to do (even though I was actually pulling a full 40 hours, they were expecting 60 out of people). 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.

msandford 11y ago
I read this story and had a bit of a chuckle. And then I read your username and had a real laugh. Thanks for that!
xacaxulu 11y ago
Great takeaway. Debt tends to make 'good little workers'. Stay free my friends!
- moron4hire 11y ago
  I think P.T. Barnum wrote the prototypical "Self-help: finance/entrepreneurship" book in "The Art of Money Getting: Or, Golden Rules for Making Money" [0]. A lot of it sounds like the stuff you hear getting hammered to death on motivational TED talks. It's a pretty short book and he doesn't go into too much exposition on a lot of the issues he addresses, with the exception of debt. He probably spends half of the already short book on talking about the evils of debt, especially debt put into things that aren't assets. It's not the debt that is the problem, it's the mindset you have to be in to take the debt, the mindset that the debt puts you in, and the mindset of the type of person that continues to use debt, especially destructively. There are some closely related issues with spending money, which tie in nicely. 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 http://www.gutenberg.org/files/8581/8581-h/8581-h.htm

ska 11y ago

> Sadly there's (seemingly) no way to interview people for this ability 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.

vijayr 11y ago
This happened to me once. I went for an an interview at a huge real estate company. They had a chat with me for exactly five minutes, then gave me a computer (an old one, with keyboard not working properly) and some legacy code. I wasn't asked to fix it, but I was asked to make a small change and given half hour for it. That code had no documentation and no comments. Then 5 more mins to explain what I understood about the codebase - no questions, just me talking about the codebase as much as I understood in that half hour. The whole thing took like 45 mins or so in total. No whiteboard questions etc. And they made an offer.
- machinshin_ 11y ago
  Did you accept?
  - vijayr 11y ago
    No, I had another offer that I took. I'm an average programmer and was able to do the task easily, but that codebase really scared me. Plus the other job was to build something from ground up and I really liked the CTO, so I took it. They were primarily hiring someone just to keep it running than adding new features. 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!
- w1ntermute 11y ago

FLUX-YOU 11y ago

The interview simply doesn't have the time required and both sides will have to be okay with spending more time evaluating each other if we want to move forward. 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.

JohnTHaller 11y ago

Back when I worked corporate I loved when I got time to make the apps I was responsible for better. Getting free time to refactor an outdated procedure written by four different developers who'd all left that just barely worked, albeit slowly, was something I enjoyed. As was getting a couple days for minor bug fixes and small feature adds. I happily had the freedom to sit with the users directly and ask them about how they used the software in their jobs as part of those few bug-fix and feature days for the "late lifecycle" apps (read: they worked OK, so almost zero time was spent updating them other than major crashes and no major versions were scheduled). So, I got to implement unique features based on how they needed to do their jobs that previous developers hadn't thought to add because they'd only done the official 'users get together and ask for features, department head filters it, hands it to our department, department head filters it, assigns it to one of us to do in spare time not working on more important software' thing.

duderific 11y ago
That sounds really nice. At my current position, we never get time just to refactor, though supposedly that time is "just around the corner." We are always cranking against tight deadlines. Consequently, we end up with some pretty jacked up code, since as the saying goes "you never get it right the first time."
- JohnTHaller 11y ago
  It was. It wasn't as often as I'd have liked. But it was nice to have once in a while. And the users loved it. It's amazing how much someone likes a developer sitting down next to them applying their full ability to try and make their job better.

deleted 11y ago

[deleted]

BurningFrog 11y ago

> Sadly there's (seemingly) no way to interview people for this ability 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.

wpietri 11y ago
I had an interview recently where we did something similar and it was awesome. They had picked an especially good example: the code was small enough that it didn't take long, but it has a variety of sorts of badness, from coding errors to bad names to bad method grouping to logical errors. I'm definitely stealing this trick.
- azundo 11y ago
  I wrote one of these for my work as well. Definitely our go-to for getting a sense of how well people can understand others' code and how they think about data modeling/complexity. A very small initial page of code can go a long way.
HaloZero 11y ago
I'm curious, how complex was the code. I would love to try this out at some point. Did it fit all in one page?
- BurningFrog 11y ago
  I think it was a class of 30-50 lines of Java code. 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.
fezz 11y ago
Agreed, being able to read and reconstruct models from OPC (other peoples code) is such a big piece of coding but hardly ever a part of the interview process. (OPC also refers to one's own code that when you can't remember wtf you did and the comments aren't useful)

anowell 11y ago

There's a lot of hate for whiteboard coding. Having been on both sides of whiteboard, code reading, and code pairing interviews, I like them all for different reasons: 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.

s73v3r 11y ago

You could give them some mild spaghetti, and ask how they'd try to improve the code. 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.

msandford 11y ago

Something I just realized that I wanted to write, but didn't, was that I generally don't do well in whiteboard interviews. I've done a few and it's always algorithms that I didn't learn in school because I was EE/CE (not CS) and while I took Data Structures and Algorithms, I didn't take Advanced Data Structures and Algorithms or anything like that. I took two compilers classes (which were great!) and a pile of classes dealing with hardware and the practical realities of computers rather than the theoretical aspects. 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.