> 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.
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.
> gave me a computer (an old one, with keyboard not working properly)
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.
Another story - I walk in on my first day (this is a subsidiary of a HUGE company). Nobody remembered that a new guy was supposed to join that day - so no desk or computer for me. First couple of hours I spent reading magazines, then I was given the oldest (probably older than me, ha) computer I've seen in my life. I am not kidding - I spent half hour just cleaning the thing (not talking about software, but hardware. it had half inch of dust on it).
You know, interviews ideally go both ways. If a company was not willing to provide me with working equipment, I would likely decline any offer they might make. Not because I need the best of the best hardware or anything, but because it would be a huge red flag that they don't value the position or the people that fill it.
Our main product was developed on a keyboard that was missing a "w". It's not a big deal, though - you can use a for(;;) loop instead of a while loop without hurting performance. And it's easy to just avoid "w" words in the view templates by being clever with word choice.
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.
It's too contrived though; not having a single working keyboard anywhere isn't a real business situation. A slow bottlenecked server, sure.
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.
Whenever you need a character your keyboard won't produce - either because it's broken or because it's in a different language and you can't figure out how to get it, just google the character and copy/paste it. i.e. Google "double u"
Or just use the mouse to open your whatever "Character Map" program comes with your OS... which works when you're missing the same letters you'd need to "sound them out", or even with no keyboard at all. (Assuming you managed to log in.)
I actually like "for (;;) {}" as an idiom for an infinite loop (or at least, the terminating conditions are in the body rather than the loop construct itself.) It maybe stands out more than "while(true)", so readers can easily see what's going on. But maybe that's just a justification, and the real reason is that it looks clever because not everybody knows you can do that with a C-style for loop.
Not at a company, but in Bulgaria every year there is a National Programming Olympiad - basically high-schoolers (but some time even mid-schoolers) would compete by solving 2 or 3 exercises in small amount of time. Their code would be ran, against tests, and it should finish in time, and with correct answers. Possibly code review might be done as well. Most used languages were Pascal, C, C++, Basic.
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!
I'm sorry but I can't help to find this situation ridiculous.
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?
> Do you really want to work in a company that can't conduct a proper interview and has broken/slow hardware?
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.
I have been forced to work with really old computers connected to as old research hardware. At some point it is probably more economical to let someone figure out the interface and solder something together with an Arduino or similar so we can start using a new computer. But that point is never now. Until then we have this old chain of hardware just to get the data from the old machine via 5 1/4 floppy disks.
Maybe it's why I'm not a developer anymore, but my approach to a broken "w" key wouldn't be figuring out a workaround to using "while", but rather copying and pasting a "w" from somewhere else.
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.
^^^this is the correct answer. as a manager I want to know if my team is experiencing an obstacle that should be simple for me to fix for them. A managers job is to remove these kind of obstacles. I don't want them wasting time with poor workarounds.
My would be to (in order): jury-rig the keyboard to make it type "w" anyway, rebind it to some unused key, or just bring my own keyboard from home (if this would not be an interview but probational period setting).
It does, but having to click to type that one letter would be annoying as hell, and a last-ditch resort (after copy-pasting the letter itself from some text that contains it).
If the 'w' key is the only worn out key on a keyboard, I would suspect that it had seen heavy use attached to a gaming PC, as the "forward" key in the default WASD movement layout.
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".
Somewhat off-topic, but I'm suddenly reminded of a joke proposal for Fortran to drop the letter 'O' entirely from its character set (in response to frustration regarding its confusion with '0'), the justification being that 'GOTO' statements would suddenly be impossible and therefore incapable of doing harm.
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!
We did something similar at previous job. We handed the candidate some code that was intentionally bad, explained that it was so (so they wouldn't think we wrote like that every day), and then asked what they'd do to improve it. This let us find out a few things - whether they could read & understand someone else's code, whether they could make improvements to existing code, what levels of abstraction they were comfortable working at, and whether they had a strong enough personality to mix with everyone else.
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.
That sounds like a good way to set expectations for communication and introduce the interviewee to the way your team respects each other.
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.
And then -- and this is important -- actually follow through on allowing and encouraging refactoring, as indicated in the interviews, instead of insisting on "features first, features fast" in practice.
I agree. There are tons of ways to test for this. Write a simple library that doesn't use any good design principles and have your candidate spend some time refactoring it. You can even use the same library multiple times. Heck, have your senior engineers also do this, so that you can get a good baseline for what an ideal candidate should come up with.
It would be actually interesting to look at the commits of a candidate's any online project repository from the very start and observe how the candidate made the progress with respect to the structure of code and improvement in coding practice. To check whether the candidate optimizes and refactors the code during the development of the project leading to a stable release.
This assumes that developers' off-work behavior is similar enough to their work behavior that it's a reliable indicator of their workplace performance. Or that developers should comport themselves on their off time to a workplace-level standard.
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.
>This assumes that developers' off-work behavior is similar enough to their work behavior that it's a reliable indicator of their workplace performance. Or that developers should comport themselves on their off time to a workplace-level standard.
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.
Yeah, personal projects could be sloppy, as it's mostly for learning new technology. And it may also be unfair to say that a good programmer always produce clean code, no matter the reason for development.
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.
>But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he has motivation to do best.
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".
When I was writing this, I actually had only new grads in my mind. You got me there. But, I think this would especially helpful incase of recent graduates. What I am trying to say is that if a candidate can show the life-cycle of some academic/personal project in a public/private manner, it would help the employer make a better decision, which will inturn benefit the candidate.
> 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.
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.
And that online repo is fully complex and developed. And has a stable release, isn't a work in progress. That code you hacked together in a couple hours to solve a quick problem isn't going to be an indication of how you handle a mature project with multiple developers.
>I think this is quite a discriminating practice - what if i don't do public projects?
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.
> 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.
>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?
Like I said: the amount of time you realistically need to get something out there is about a couple of weekends.
The bar is not necessarily as low as you think. At companies like Amazon you have to get approval for even the simplest personal projects, which could take months if you're unlucky.
Generally speaking, I preferentially hire developers with public projects--though I do not just pick one at random and ask for one they're particularly proud of. I think open source development is virtuous and is something that I want to promote and encourage; in the process, I get what I think is a better view into how somebody works.
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.
Only in the weirdly defensive world of Hacker News does preferring people who contribute to open source software imply throwing out resumes without it, does it imply "missing out" on those people. Of course I consider resumes without open source work. It would be stupid to not do so. But I will look first at those with a publicly auditable track record. Is that a surprise? I look, earlier in the list, at people who've worked at a number of large firms with strong technical teams, too. They shrink the error bars on hiring.
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?
So I have a small side project I have hosted on Heroku. Getting stuff working on Heroku was a pain, and involved a commit for every thing I changed to try and make it work. How would you view a ton of commit messages in that context?
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.