1. 6

    I solved it instantly. Yay.

    Hate interview questions, but this was probably my favorite.

    You know, what makes questions like these terrible at filtering candidates is that they have almost nothing to do with real world tasks. If you were given this task and you didn’t know the answer, you’d talk it over with a teammate and search for related work. There’s ~zero chance that a good dev would still be empty handed within a few hours.

    Most companies are not google. Stop mimicking their interview process or I’ll hit you with a leek.

    1. 8

      This is one of those criticisms where people who make it, should also provide an alternative. Which technical questions do you ask candidates? (I’ve seen some folks argue that one shouldn’t ask technical questions at all, and instead rely on pedigree. Maybe that’s your position as well, but it’s so far removed from my experience, I can’t even imagine how it could ever work, particularly for those without prior work experience.)

      Personally, I thought this was a pretty good question overall. It’s derived from a real problem that the employer has to solve, requires a bit of knowledge about data structures and necessitates some kind of practical experience with actually writing code. To be honest, given my own experience and the experience of others I know, one should feel quite good that a question like this is even askable in the first place. In many places, FizzBuzz is used as a legitimate filter on candidates, due to spectacular bureaucratic failures on several levels. (But also, probably, because the average quality of candidates in this field is probably quite a bit lower than you might imagine if the only folks you’ve ever worked with are at elite institutions.)

      If you were given this task and you didn’t know the answer, you’d talk it over with a teammate and search for related work.

      Indeed. But ultimately, at some point, a hiring decision needs to be made with respect to a particular individual. Some folks do interviews where they try to collaborate with the candidate and see how it feels to work with them. But this is artificial in its own way, and suffers from a few obvious drawbacks on its own.

      Apologies for this comment, but I mostly feel like criticism of interview techniques these days boils down to “that’s not fair” or “that’s not measuring the right thing.” No interview technique is fair, and no interview technique will measure the right thing, because you can’t always divorce reality from evaluation. Basically, what this means is that pretty much anyone can construct an easy argument to label an interview technique as “bad” in some way, because technically, it’s true. But that’s not that interesting. What’s interesting is whether you can practically do much better.

      1. 5

        Delightful reply! Thank you.

        I had a unique experience at Matasano. Basically, they hired candidates strictly and solely based on their performance on a work hire test. The test measured a candidate’s ability to do work very close to (actually, almost identical to) what the candidate would be doing if they were hired.

        As far as I know, no other company took it to the extreme that Matasano did. The only reason it works is because of those extremes: you must make hiring decisions solely based on performance on the work hire test. No “cultural fit” critique. No sudden questions during the in-person interview. In fact, there was only one follow up question during the interview, and as far as I know the in-person scenario almost didn’t matter at all when choosing whether to hire. If you could do the work, as measured by the hiring test, you were effectively hired, regardless of gender, sex, religion, political affiliation, or whether you can successfully answer ineffective Google-style pop quiz questions.

        The reason no one believes this technique works is because no one bases their hiring decisions solely and strictly on the results of the hiring test. It’s as easy and as hard as that.

        By the way, what are you working on nowadays? Do you have a Twitter? I’ve been lost in the murky depths of AI programming, which has been a weird experience. It’s a bit like starting over my programming knowledge from scratch.

        1. 3

          Interesting. I can imagine a lot of practical problems with that approach, but I grant it is interesting. I’m sure if we sat down and dissected it, we could point to a number of ways in which it isn’t an accurate reflection of reality. Which is kind of my point. But thanks for throwing out an alternative. :-)

          By the way, what are you working on nowadays? Do you have a Twitter?

          I loathe Twitter, but I have one: https://twitter.com/burntsushi5

          I’m still working on text stuff in Rust. My continuing goal for the past couple years has been to make it easier to add optimizations to my regex library. Lots of key fundamental decisions need rearchitecting. To prevent burn out, I intersperse that work with other things, such as higher level ripgrep work or fun programs that scratch a personal itch.

        2. 4

          The level/intensity of disagreement with nearly everything you’ve said has caused me to rewrite this multiple times. Perhaps I’m misinterpreting what you’re saying with my own experiential bias ( almost assuredly ), but I’d like to attempt to respond:

          Personally, I thought this was a pretty good question overall. It’s derived from a real problem that the employer has to solve, requires a bit of knowledge about data structures and necessitates some kind of practical experience with actually writing code.

          This is a terrible question, with terrible assumptions about things “people should just magically know” based on assumptions about what the interviewer themselves thought was important. First, “story problems” are strictly speaking, a poor representation of real-world problem solving. Never in the history of computing has a problem been reduced down to a story problem, until after the discovery of the solution was found. It is revisionist thinking when one decomposes a problem and solution AFTER having gone through the exercise of discovery. How long did the interviewer have to think of a particular problem? How did they have to go through the mental exercises of the problem, doing discovery, having realizations, discussing with peers and co-workers? Days? Weeks? More often than not, this creates a situation where the interviewee is more concerned about getting the answer that the interviewer is looking for than the problem itself. The author confirms this by using the even after I gave them hints trope. This is first order condescension. I know the answer; I’m going to lead you around with hints, all the while not telling you when the hint count has crossed from the “worth hiring” bucket to the “not worth hiring bucket”.

          What would be a better way? Perhaps, “Let’s discuss some problems together that neither of us have solved or attempted to solve before and maybe spend an hour talking about them and if things are going well, let’s work on solving a bit of one together; or at least talk about solving the problem. Let us ‘collaborate’ for an hour or two and see what we come up with?”

          This solves two problems: One, it gives insight into thinking, problem solving and knowledge boundaries with out artificially creating story problems that one party already knows the answer to and two it gives insight as to whether or not this person in compatible with the interviewers work style.

          Personally, I thought this was a pretty good question overall. It’s derived from a real problem that the employer has to solve, requires a bit of knowledge about data structures and necessitates some kind of practical experience with actually writing code. To be honest, given my own experience and the experience of others I know, one should feel quite good that a question like this is even askable in the first place. In many places, FizzBuzz is used as a legitimate filter on candidates, due to spectacular bureaucratic failures on several levels.

          I believe this is the wrong signal to take from this. In fact, this signal reads: if a person’s job interest criteria are “Asks pseudo-computer science adjacent related story questions” vs. “fizz buzz” that they are also not worth hiring because they’re perpetuating a hiring myth that they themselves have adapted to successfully.

          Apologies for this comment, but I mostly feel like criticism of interview techniques these days boils down to “that’s not fair” or “that’s not measuring the right thing.” No interview technique is fair, and no interview technique will measure the right thing, because you can’t always divorce reality from evaluation. Basically, what this means is that pretty much anyone can construct an easy argument to label an interview technique as “bad” in some way, because technically, it’s true. But that’s not that interesting. What’s interesting is whether you can practically do much better.

          Conversely, I think the argument that “it is what it is… come up with a better one” is also disinteresting. In essence it’s a derivation of the pedigree argument. “This is reasonable to me there for it’s probably reasonable.” Interviewing a person is a skillset that most people and especially programmers, don’t tend to have. It requires a degree of EQ that makes many people feel uncomfortable with and ultimately has very little to do with “Can a person program or not?”.

          We have this unfortunate habit as an industry of pretending simultaneously like all knowledge should be open and free and also that few people are the keepers of the sacred knowledge. We try to signal for the sacred knowledge people, because we believe there is something ‘special’ about what they know.

          Ultimately, I obviously don’t know the answers either. Otherwise, I wouldn’t be commenting here, I would be raking in loads of cash from my “one true way” interviewing manuals, courses and training seminars. What I do believe though is that this is a real problem in our industry and we should spend more time thinking/talking and work on it, for the benefit of everyone.

          The “eh, good enough” or “it is what it is” is unacceptable in my mind.

          1. 4

            This is a terrible question, with terrible assumptions about things “people should just magically know” based on assumptions about what the interviewer themselves thought was important. First, “story problems” are strictly speaking, a poor representation of real-world problem solving. Never in the history of computing has a problem been reduced down to a story problem, until after the discovery of the solution was found. It is revisionist thinking when one decomposes a problem and solution AFTER having gone through the exercise of discovery. How long did the interviewer have to think of a particular problem? How did they have to go through the mental exercises of the problem, doing discovery, having realizations, discussing with peers and co-workers? Days? Weeks? More often than not, this creates a situation where the interviewee is more concerned about getting the answer that the interviewer is looking for than the problem itself. The author confirms this by using the even after I gave them hints trope. This is first order condescension. I know the answer; I’m going to lead you around with hints, all the while not telling you when the hint count has crossed from the “worth hiring” bucket to the “not worth hiring bucket”.

            Other than you saying it’s a terrible question, I don’t really strongly disagree with any of this. These are all downsides. That was kind of my point: it’s super easy to poke holes in all forms of interview styles because you pretty much can’t separate a scheduled evaluation from reality. The only real substitute is if you have personal experience with them in a prior setting, or if someone you know and trust did. i.e., “word of mouth.”

            What would be a better way? Perhaps, “Let’s discuss some problems together that neither of us have solved or attempted to solve before and maybe spend an hour talking about them and if things are going well, let’s work on solving a bit of one together; or at least talk about solving the problem. Let us ‘collaborate’ for an hour or two and see what we come up with?”

            I personally would never be able to pull off an interview like this. I would hate it from both the interviewer and interviewee angle. It’s too unstructured and too easy to go off course and wind up not being able to extract a useful evaluation. If we were in a more personable setting, I could walk you through in more detail why this is, but I’d rather not dive that deeply into my emotional state for this sort of thing in public. :-) To be clear, I do not deny that some folks are able to conduct an interview like you describe, but I’m not sure I could.

            I believe this is the wrong signal to take from this. In fact, this signal reads: if a person’s job interest criteria are “Asks pseudo-computer science adjacent related story questions” vs. “fizz buzz” that they are also not worth hiring because they’re perpetuating a hiring myth that they themselves have adapted to successfully.

            I’m having trouble parsing this. I can’t extract your meaning.

            Also, it seems like you’re using “pseudo” here as a pejorative, but I don’t understand why. An interview is an evaluation and has practical limitations. You can’t ask a technical questions like this without simplifying it somehow, because you just don’t have the time. As far as problems go, I think the OP’s is pretty darn good. The “story” is very short, the end user criteria are fairly easy to understand and the structure of the data is simple to explain.

            Conversely, I think the argument that “it is what it is… come up with a better one” is also disinteresting. In essence it’s a derivation of the pedigree argument. “This is reasonable to me there for it’s probably reasonable.”

            This is just going in circles. My point is that it’s very easy to poke holes (sometimes giant ones) in interview methodology. But it’s much harder to come up with an alternative that also doesn’t have holes in it. That’s why I said that what’s interesting is whether you can practically do much better. Maybe this comes in the form of an alternative that also has holes, but different holes, and depending on what your evaluation criteria are, one approach may be better than the other.

            The problem is that conversations about interviewing have all these unstated assumptions that effectively boil down to “this is reasonable to me therefore it’s probable reasonable.” It’s thus so easy to launch an assault on interview styles because it’s likely being evaluated from a single perspective.

            Interviewing a person is a skillset that most people and especially programmers, don’t tend to have. It requires a degree of EQ that makes many people feel uncomfortable with and ultimately has very little to do with “Can a person program or not?”.

            I mostly agree. But I think you’re de-emphasizing “can a person program or not” too much.

            We have this unfortunate habit as an industry of pretending simultaneously like all knowledge should be open and free and also that few people are the keepers of the sacred knowledge. We try to signal for the sacred knowledge people, because we believe there is something ‘special’ about what they know.

            I don’t think there’s anything about “sacred knowledge” in the OP. Unless all knowledge is sacred. Otherwise, I think it’s perfectly fine to set some minimum qualifications about what a candidate knows. It seems to me like you’re expressing ideals, but I don’t see how they work in practice.

            Ultimately, I obviously don’t know the answers either. Otherwise, I wouldn’t be commenting here, I would be raking in loads of cash from my “one true way” interviewing manuals, courses and training seminars. What I do believe though is that this is a real problem in our industry and we should spend more time thinking/talking and work on it, for the benefit of everyone.

            The “eh, good enough” or “it is what it is” is unacceptable in my mind.

            I agree. I never said or implied “good enough” or “it is what it is.” I’m criticizing incomplete criticism of interview styles. The notion that I’m somehow okay with not critically evaluating my own evaluation protocols is pretty uncharitable IMO.

            1. 1

              I suspect that maybe my talking points are not clear enough. I’ll try to be more succinct and brief.

              Other than you saying it’s a terrible question, I don’t really strongly disagree with any of this. These are all downsides. That was kind of my point: it’s super easy to poke holes in all forms of interview styles because you pretty much can’t separate a scheduled evaluation from reality. The only real substitute is if you have personal experience with them in a prior setting, or if someone you know and trust did. i.e., “word of mouth.”

              This is part of the issue with current interviewing. It’s not a ‘score’ system. It’s not an ‘evaluation’ in the sense that someone is taking a test, with right or wrong answers. That’s entirely the wrong way to interview, but it is usually the default because it is understandable/relatable, easily. Hiring has more in common with speed dating than with test taking.

              I personally would never be able to pull off an interview like this. I would hate it from both the interviewer and interviewee angle. It’s too unstructured and too easy to go off course and wind up not being able to extract a useful evaluation. If we were in a more personable setting, I could walk you through in more detail why this is, but I’d rather not dive that deeply into my emotional state for this sort of thing in public. :-) To be clear, I do not deny that some folks are able to conduct an interview like you describe, but I’m not sure I could.

              That is kind of my point, I think. No disrespect to you intended, but if you can’t conduct an interview like this, you shouldn’t be interviewing people, full stop. As for being the interviewee, the way you feel and react to this style of interview is exactly how others feel about the style of interview you’re comfortable with. Anecdotally, I’ve failed nearly every “test” interview I’ve ever done, in 25 years of being an engineer. I’m a relatively competent engineer. I still can’t pass a “test” in the way they’re concocted, even when I’m being ‘tested’ on stuff I wrote.

              This is just going in circles. My point is that it’s very easy to poke holes (sometimes giant ones) in interview methodology. But it’s much harder to come up with an alternative that also doesn’t have holes in it. That’s why I said that what’s interesting is whether you can practically do much better. Maybe this comes in the form of an alternative that also has holes, but different holes, and depending on what your evaluation criteria are, one approach may be better than the other.

              I agree with you, but let me be more clear: The “provide an alternative or don’t criticize” is just as invalid and “uninteresting” as what you’re protesting; in fact it is literally the same argument. It is not going in circles as much as it is a no-op.

              I mostly agree. But I think you’re de-emphasizing “can a person program or not” too much.

              I think engineers who have interviewed people like to roll out the “This one time I interviewed a person with 125 years of experience and they couldn’t program AT ALL!” as a sort of badge or signal and more often than not, it’s nonsense. Instead, start with the assumption that people actually know what they’re doing and they have to demonstrate that they don’t. I think if folks did only that, it would be a great start to changing the horrible interviewing culture we are currently in.

              I agree. I never said or implied “good enough” or “it is what it is.” I’m criticizing incomplete criticism of interview styles. The notion that I’m somehow okay with not critically evaluating my own evaluation protocols is pretty uncharitable IMO.

              I’m criticizing your criticism as being the exact same thing. We can agree to disagree here, I think. I don’t mean to sound uncharitable or offensive, so if my words have come across that way, I apologize. Regardless, the discourse is good and I appreciate the response.

              1. 2

                This is part of the issue with current interviewing. It’s not a ‘score’ system. It’s not an ‘evaluation’ in the sense that someone is taking a test, with right or wrong answers. That’s entirely the wrong way to interview, but it is usually the default because it is understandable/relatable, easily. Hiring has more in common with speed dating than with test taking.

                I’ve never done speed dating, but the formulations I know about involve very quick conversations. Like, on the order of a few minutes. I don’t know of any technical interviews that are that short. Again, I feel like you’re making a comparison to express a pejorative, but it’s not really working from my perspective.

                And I don’t understand why you’re hung up on the word “evaluation.” Evaluation is a pretty broad term. I don’t see why it has to be limited to a written test, like you have in school. Hell, even in school, I remember having oral exams occasionally. The biggest of which were my qualifying exams in grad school. I had to stand in front of committee and get grilled on various CS topics. There was no scoring system. Just “pass” or “not pass.” But it was certainly an evaluation.

                No disrespect to you intended, but if you can’t conduct an interview like this, you shouldn’t be interviewing people, full stop.

                I went out on a limb to offer some personal emotional insight, and in exchange, I got this response which I interpret as extremely adversarial. So please don’t talk to me about this topic again. It’s clearly a waste of time. (I only wrote as much as I did in this comment because I wrote it before seeing this part of your comment. You went on to make other assumptions about my own personal experience as well, which weren’t true and were beside the point.)

      1. 1

        I’m a pretty experienced developer and I prefer sublime text or howl over vim or emacs. Send me your hate messages.

        1. 3

          Why?

          1. 2
            • I like to use a mouse to select text for copy/paste.
            • I use auto formatters like clang-format, gofmt and cargo format and black when programming, so the editor is not relevant for that nitty gritty formatting of code.
            • Code completion is pretty good and uniform nowadays due to language server protocol regardless of editor.
            • I run compilation and other jobs via a terminal in a tiling window manager, so don’t use any editor functionality for that.
            • I have an opinion that if a project needs automated navigation, the code is too complicated to follow mentally anyway.
            • Sublime text multi cursor mode does most of what I would use macros for in other editors.
            • Sublime text performs well.
            • I haven’t really seen any compelling evidence of vim or emacs being more productive other than anecdotal word of mouth from people with possible biases. (On this note, I would love a really skilled developer to make a video demonstrating the benefits while working on a real project.)

            The only time I use vim is when editing over ssh.

            One day I hope to replace sublime and my minimal vim usage with an OSS GUI editor programmable with https://janet-lang.org/ , but don’t have time to write it.

            1. 4

              Generally, you don’t want to use Emacs because it’s a text editor, but rather because it’s a good work environment. My main reason for investing time into it, is that it’s just the most comfortable environment I have ever used.

              I have an opinion that if a project needs automated navigation, the code is too complicated to follow mentally anyway.

              How is this related to text editors?

              1. 1

                How is this related to text editors?

                If someone is of the opinion that vim or emacs have better code navigation capabilities.

                is that it’s just the most comfortable environment I have ever used.

                I never found either particularly comfortable, not sure what I was doing wrong. I used vim for a year or two, and never really clicked, I did the emacs tutorial at least 3 times but never resonated with memorizing multi-key stroke hotkeys.

                1. 2

                  If someone is of the opinion that vim or emacs have better code navigation capabilities.

                  No, not that I know of. That being said, the problem of “code navigation” is really more of an idea than related to a text editor. That means that anyone could come up with a good idea to elegantly or intuitively browse code, and if that already exists, implementing it for Emacs (and maybe even Vim) usually doesn’t turn out to be too much of a problem.

                  I never found either particularly comfortable, not sure what I was doing wrong.

                  First of all, Vim isn’t the environment. Vim is the text editor within the Unix-Shell environment. It is on this level that one should compare it to Emacs. And Emacs, on the other hand has a usable but not that spectacular default configuration. Setting up Emacs is (as much as I hate the analogy) a certain rite where you learn the editor, and the editor is taught to your needs. “memorizing multi-key stroke hotkeys” turns out to be nothing when it becomes muscle memory – “safe a file” just becomes a certain finger movement, with little difference to regular typing.

                  It is then, if you have chosen to invest some time, which might be a week or a year, that you get to enjoy comport (if you’re lucky ;^)).

              2. 3

                No hate messages from me but note that emacs can do all of these.

                1. 2

                  Right, I’m just not convinced it does them that much better than many other editors.

                  I don’t quite understand why programmers really like emacs or vim. I tried both multiple times and wasn’t impressed with either of them enough to change what I already knew.

                  I would like someone to convince me, but I’m not sure i’ve seen anything particularly great before.

                  1. 3

                    I’m also in the sublime text camp, but I might be able to shed some light.

                    Having learned to use vim well is a huge sunk cost with substantial benefits in terms of speedy editing (multi-cursor usually replaces fancy commands, but can’t always). I couldn’t recommend someone start learning vim today, but I can definitely see the value in having learned it.

                    As far as Emacs goes - there’s an old joke that “Emacs is a great operating system that just needs a good text editor”.

                    Quite a bit of the value of emacs is that you’re expected to customize it to fit your personal ergonomics; it’s common to see it as the only thing running on a developers computer, managing mail/calendar/chat windows/code files/server processes/etc.

                    Because all of this stuff is running in a single, scriptable process with a high level language, it’s trivial to wire different parts together (eg “file emails from my project manager into my ‘work todo’ list”).

                2. 2

                  You’re welcome to use whatever you feel most productive in. I’ll say though that I’m a big fan of Vim primarily because I can do all the text editing I want without my hands ever leaving the keyboard. The default keyboard shortcuts on all of the GUI editors I’ve used don’t really get the job done, and constantly having to take your hands off the keyboard, move to the mouse, click or select something, then back to the keyboard feels like swimming in molasses once you get used to Vim. That may be why it’s hard to see - you can’t really video what it feels like to have all of the movement keys committed to muscle memory and not have to think about grabbing the mouse.

                  IMO, an essential companion is tmux, which lets you tile things and switch between them arbitrarily, still without ever leaving the keyboard.

                  1. 1

                    I like to use a mouse to select text for copy/paste.

                    I’m pretty sure this works in Vim and Emacs, although a compilation flag may need to be enabled.

                    1. 1

                      Well, with Xorg when you select text you can use the middle mouse button (or shift-insert) to paste. Selected text is automatically added to the clipboard.

                      If you like multiple cursors, you might find vis interesting. I can see why you like whatever you’re using though, your reasons are fair enough.

                  2. 1

                    Eh. Personally, I don’t really care what tools other people use. It’s like worrying about what toilet paper brand your neighbor uses. It has no effect on me at all.

                    I think a lot has to do with how you build your mental model with the things that you’re working on. I never really gave a hoot about Emacs, until I started doing serious Erlang and Racket development. That’s not to say you can’t/shouldn’t/whatever use other tools to do that but for ME Emacs made me significantly more productive when I could twist my env to my modalities, instead of the other way around.

                    I find these ‘editor wars’ as tedious as Ford/Chevy and Chocolate/Vanilla. Who cares? Drive what you want and eat the flavor that you want. If you’re curious about what other people do and why, cool! It’s NOT on me ( or others ) to convince you… Convince yourself or don’t worry about it.

                  1. 5

                    I’ve been watching this with some interest after RacketCon… There’s a lot that can be said about it, but the one thing that keeps coming up for me is that this is a prime example of the collision of Academic/Researcher and Industry/Practitioner. It’ll be interesting to see what they come up with.

                    The Racket folks have thus far proven themselves to be capable stewards of a pretty amazing ecosystem.

                    1. 9

                      This post is bullshit and I’m sad to see it here with 82 upvotes.

                      I hate the smug pedant writing style throughout, the massive effort spent explaining that WIP features are indeed a work in progress, the pages of copy pasted console output to demonstrate that there are trivially fixable bugs, and so many errors. (using trivially replaceable libc functions fits the standard definition of “zero dependencies” for C code, try making a release build, nobody cares if a compiler leaks memory, you would fix it by deleting the malloc, nobody cares that compiling a 1.2m line function fails, your benchmark is invalid because it doesn’t actually work, macbooks are 10x slower than any modern desktop, …)

                      I especially hate the condescending suggestions at the end and loosely sprinkled flowery statements that allow you to pretend you’re being constructive and not just making fun of someone in public for upvotes.

                      Five days ago you submitted a post about how you hope you can help new programmers get into the industry, now you’re writing multiple posts and comments dumping on someone because version 0.0.12 of the one man project they’re giving away for free isn’t as good as you hoped. Don’t you find that hypocritical?

                      BTW yes I am aware his patreon raises $800/month, remarkably average programmers fresh out of school make that much in one day at Google/FB/etc, all of whom will happily take his work and give nothing back should it benefit them.

                      1. 13

                        the massive effort spent explaining that WIP features are indeed a work in progress

                        That this was not how anything was portrayed or described for months on end. The post doesn’t really give full context.

                        nobody cares if a compiler leaks memory, you would fix it by deleting the malloc

                        No, V manages memory for you apparently.

                        macbooks are 10x slower than any modern desktop,

                        I know you are exaggerating, but no, they aren’t 10X slower, especially not for a single threaded workload like the current v compiler. I agree the benchmark is synthetic and doesn’t mean much, but If anything a real program is split into many files which will slow things down further. The fact of the matter is the author likes to say V compiles 1.2 million lines of code a second, and it doesn’t. Why say things like that when they aren’t true? Just say V is fast, or V will be fast.

                        Five days ago you submitted a post about how you hope you can help new programmers get into the industry, now you’re writing multiple posts and comments dumping on someone because version 0.0.12 of the one man project they’re giving away for free isn’t as good as you hoped. Don’t you find that hypocritical?

                        I don’t think he/she said they should get into the industry by telling people they are more capable or accomplished than they actually are. Say I have some free things to give your elderly parents that don’t work as advertised and then cause harm, fine by you I guess? It was free after all.

                        BTW yes I am aware his patreon raises $800/month, remarkably average programmers fresh out of school make that much in one day at Google/FB/etc, all of whom will happily take his work and give nothing back should it benefit them.

                        Can’t argue with that.

                        Anyway, the V site is much better now - all people want is honesty. It isn’t that hard.

                        1. 8

                          I hate the smug pedant writing style throughout, the massive effort spent explaining that WIP features are indeed a work in progress,

                          Problem is that for months if not years, those features were advertised as present. The (WIP) icon only got added recently.

                          macbooks are 10x slower than any modern desktop

                          Not even close. A MBP can get as high as 5140 on geekbench, while the maximum a high end iMac has gotten is 6245. https://browser.geekbench.com/mac-benchmarks

                          BTW yes I am aware his patreon raises $800/month, remarkably average programmers fresh out of school make that much in one day at Google/FB/etc, all of whom will happily take his work and give nothing back should it benefit them.

                          $800/day is $208k/year

                          that’s notably higher than average dev salary at facebook and at google, and I’m sure that a new graduate doesn’t get the average salary.

                          But yeah, this is semantics, so whatever.

                          In any case, you should also account for that fact that he lives in Russia, and that $800/mo (used to be $1000/mo fwiw) is a notable amount by Russia standards. Yandex pays ~2k USD per month on average to their software developers. (conversion)

                          1. 2

                            Note the patreon is $800 per month, not day. $9,600 per year is not much.

                          2. 6

                            What @ac said is true. Here are the original claims he presented mostly like it was done. A few articles like that. On HN, we got him to back off admitting some claims were actually in just getting started stage. Eventually, he put WIP icons on some of that on the new site.

                            Before that, he was saying he had a language safe with no GC like Rust (but easier) that compiled fast like Go running as fast as C with no to sub-1MB dependencies with cost-free interop with C/C++. And he can transpile your C++ code to it, too.

                            Then, we got this repository as the deliverable. And it didn’t even deliver on some of the easier claims. Yeah, you bet folks are going to call him out for that.

                            Edit: Tagging ac and @cadey in case you want the archive link as evidence.

                            1. 5

                              I’m glad you said something because this entire thing is embarrassing and in my opinion, all these folks dog-piling should be ashamed of themselves. If this person CAN make stuff happen, then why not cheer him on? If he can’t then why not say, ‘good try mate’? This hyper critical negative focus is so distasteful.

                              But but he’s taking MONEY! So? He’s got a patreon and he’s trying to fund something he thinks he can do. All these hyper technical nitpicking folks thinking somehow this is a zero-sum game. Just shameful.

                              1. 6

                                I think he did a great job marketing, If he can make things happen then great. He just should stick to truth when getting attention. It isn’t that hard. It isn’t “hyper critical” to expect honesty. The site is much better now than it was before.

                                thinking somehow this is a zero-sum game

                                I didn’t see anyone make that claim.

                                If he can pull off all the WIP’s in december 2019 like the site says, it would be fantastic.

                                1. 2

                                  If he’s doing this in good faith (which I figure he probably is), then so long as he doesn’t give up, by December he’ll have learned a whole lot & be substantially more qualified to attempt everything he’s planned (even if he hasn’t managed to do so by that point). Jumping in the deep end is a great way to learn to swim.

                                  Already, he’s learned an important lesson: that misrepresenting planned features as already-implemented will be generally interpreted as dishonesty, & so it makes more sense to build trust by working in public.

                                  If he stays on this path, the donations will be justified simply because they will have supported the development of a skilled & well-rounded developer – something we desperately need more of in the world! And, cadey’s post is a vital part of making that happen.

                                  1. 2

                                    YOU my friend, made that exact reference:

                                    Lol, make sure you donate some more money.

                                    Why on earth do you care if people are giving him money or not? He’s working on something, he’s solicited for money and people have given it to him. How does this in any way affect you? This is what I meant by zero-sum. Folks giving him money doesn’t automagically reduce the available money for other people, so why begrudge him?

                                    Perhaps this stems from my personal belief that we should be trying to always encourage each other in our endeavors rather than tearing them down constantly, but I see nothing but a bunch of folks jumping like blood-thirsty savages on a cat with some good hype-game and some ideas about PL that he’s making an attempt to make real.

                                    1. 5

                                      Protecting others from perceived bad decisions is not being greedy. it is trying to help people.

                              1. 13

                                Some of the psychology you cite is very pertinent and interesting but I really disagree with some of your conclusions.

                                I think that if you as a candidate freeze up when asked to perform a basic example of what you’d be doing for your job, then that’s an interview skill you should consider building rather than advocating doing away with that class of interview question.

                                I know a LOT of talented people who have great trouble with whiteboarding, and I get it. I REALLY do because I used to be in that category.

                                But like any other fight / flight response where no actual mortal peril is involved, you can work through the anxiety and learn to process the situation differently, and once you do, it’s incredibly empowering!

                                When I’m doing an interview and I can tell that my candidate is freaking out, I typically ask them to talk me through what they think a solution would flow like, without any of the syntax involved.

                                And honestly, what job anywhere is free of this kind of pressure?

                                [Full Disclosure: I work for a Major Cloud Company and our interview process is highly data driven and also includes some whiteboarding. I think this hiring strategy has been extremely successful, but obviously YMMV and different companies are different.]

                                1. 15

                                  The problem is, its not only about anxiety. It could be, and is, any number of things, like active stressors (disease, divorce etc.), biochemical stuff (low sugar, hormones), meteorology (too hot/cold) etc. I remember, 10y ago that when I had an interview @booking.com, my head hurt so strong that I could hardly speak.

                                  And honestly, what job anywhere is free of this kind of pressure?

                                  Almost any job is without that kind of pressure. Its totally artificial.

                                  When you measure people this way, you have no option but to ask academic stuff. For example, local Microsoft tech interview I was part of were created by assistants of local faculty of Mathematics, and had questions such as what is the probability that frog will survive the road run and other crap like that. I finished the same math university 5 years before and I still couldn’t manage many questions. Not to mention, just finished students nailed it, with 0 practical experience (it was 0). So, this type of interview is biased toward fresh graduates and academy itself has entirely different goals and agenda far removed from usual everyday IT reality (since then I had number of professors working in my team and each time with disappointing results). Or, member the interview of author of brew for Google ?

                                  I used exclusively lets-speak-about-random-IT-stuff type of interview and I think it worked OK. I also ask for online profiles - Github, Gitlab, etc… there is no substitute for seeing (or not seeing!) code itself. There are few persons that were great in that while sucked on job a lot, but overall, the initial feeling after the conversation was at least 90% on the spot.

                                  1. 2
                                    And honestly, what job anywhere is free of this kind of pressure?
                                    

                                    Almost any job is without that kind of pressure. Its totally artificial.

                                    Couldn’t disagree more. I’ve worked in this industry for 30 years, admittedly only 5 or so of those years as an actual ‘software developer’ (mostly release engineer, devops, and before that highly code-centric sysadmin).

                                    I can’t think of a single job I’ve ever worked that didn’t have “OK. We need you to produce. NOW” moments.

                                    If you’ve worked jobs that don’t have that kind of pressure, I envy you, but I’m unsure whether or not your experience is one that many others share.

                                    1. 15

                                      Certainly many jobs require deploying a patch, developing a new schema, reacting to a fire in the moment on deadline, etc., but I think few require you to be able to converse about it to strangers who can fire you, in those circumstances. ;)

                                      My work is not complicated. My experience with whiteboard interviewing has been with insignificant companies that do not do hard engineering. When I froze up and couldn’t think of the name for modulo after having just used the operator, the interviewer decided I wasn’t a good fit… I think less technical or complicated jobs use whiteboard just as much as Google, and that’s frustrating.

                                      1. 11

                                        Most of them won’t then stare at you while you do your job on an unfamiliar tool you’re only using so they can decide whether to promote or fire you.

                                        Instead, they give you some requirements, you leave, you work alone on them at a computer, maybe talk to team members, maybe status reports (mostly typed), and eventually deliver the results to then.

                                        These are the skills the interview process should assess. That’s why a lot of shops do take-home assignments or just not whiteboarding. Now, whiteboarding in non-hostile environment can be great for testing presentation and collaboration skills.

                                        1. 4

                                          Exactly.

                                          When multiple people STARE AT ME while working (even in familiar environment), I can’t work productively.

                                          Also, nobody ever comes with the random problem and ask you to solve it yesterday in 1 hour. You always have some context, some continuancy.

                                          1. 2

                                            I can appreciate where you’re coming from here and I’ve done take home assignments in the past. I stand by my comments around whiteboarding as a valuable interviewing tool. I think if interviewers are getting hung up on details they’re missing the point, and I also think that as a prospective interviewee having the expectation that you won’t be asked to give a sample of your work on the spot doesn’t seem realistic to me.

                                            However, if all of you can restrict your job search to companies that never do whiteboarding, good on you!

                                            1. 2

                                              The problem with whiteboarding is that while it measures something, the something it measures is not the thing you’ll care about if you hire them. Which in turn is why there are books out there that teach whiteboard interview coding as a separate skill from actual programming, and why even prestigious universities now include a unit on interview coding as a separate skill from programming.

                                              Which raises the inevitable question: why not actually test for the skills you’ll care about on the job? If you don’t test for the job skills you’ll hire people who don’t have the job skills.

                                              1. 3

                                                why not actually test for the skills you’ll care about on the job?

                                                That is what they’re trying to do. It takes a lot of time to find out if someone can actually do a good job as part of your team, and the only way to really test it is to employ them for a few months (A few months of probation is quite common for this). Given that you can’t afford to make that sort of investment in every candidate that applies, companies use whiteboarding and other forms of technical interview to try and guess whether a candidate might have suitable skills before investing more time in them.

                                                1. 0

                                                  That is what they’re trying to do.

                                                  Well, no. What they’re trying to do is cargo-cult what they think Google is doing, because they think “Google is big and successful, so if our company does what Google does, our company will be big and successful too”.

                                                  Of course, Google openly admits their process has a high false-negative rate (it flunks qualified people), but they get enough applicants that they can afford to reject some qualified people. The average company isn’t in that position and can’t afford it.

                                                  And Peter Norvig has explained that Google found a negative correlation between doing well on competitive programming tasks and performance on the job, which throws a wrench in any argument that on-the-spot coding under pressure measures something useful.

                                                  Interviewing as typically practiced in tech is fundamentally broken. It measures the wrong things, draws the wrong conclusions from what it does measure, and is more or less random. I think it’s long past time to stop defending that.

                                                  1. 2

                                                    I never said that the processes were effective, nor am I defending them. I am merely pointing out that they are ultimately an attempt (however ineffective) to select candidates with relevant skills and reject those without.

                                                    “Why not actually test for the skills you’ll care about on the job?” is unhelpful in that the intention is blatantly obvious, but offers absolutely no suggestion of how to achieve it.

                                                    1. 6

                                                      “Why not actually test for the skills you’ll care about on the job?” is unhelpful in that the intention is blatantly obvious, but offers absolutely no suggestion of how to achieve it.

                                                      Tthere are a ton of articles and talks floating around on how to do better tech interviews – I’ve even written/presented some of them, based on my own experience helping to rebuild interview processes at various places I’ve worked – and people could quite easily find them if they wanted to.

                                                      But here goes. Again.

                                                      As I see it, there are several fundamental problems, and various ways to avoid them.

                                                      Problem #1 is playing follow-the-leader. People implement processes based on what they think bigger/more successful companies are doing, without considering the tradeoffs involved or indeed whether those processes had anything to do with the size/success of those companies. Google’s admitted high false-negative rate is the quintessential example: they really can afford to throw away qualified applicants, because tomorrow another hundred will have submitted applications. The typical tech company can’t afford this, or can’t afford other unquestioned assumptions baked into large-company interview processes.

                                                      The solution here is to question the assumptions and expose the tradeoffs. The extremes are “Never hire an unqualified person” and “Never pass on a qualified person”. Google optimizes for the former at basically all costs. Many companies, on the other hand, need to push the needle further toward the latter, which means a more forgiving process that doesn’t flunk people as quickly or for reasons as minor as large companies do. True story: I know one person who flunked Google because they had to write and then read out a bash script over the phone and the interviewer mistranscribed it. I know another person who flunked at Twitter because they provided one of two textbook algorithms for the problem posed, but the interviewer only knew the other and didn’t bother looking more deeply than just “that’s not the answer I know”.

                                                      Those should be unforgivable interviewer errors at any company, but are especially unforgivable at companies which can’t afford to just throw qualified applicants into the trash can.

                                                      Problem #2 is poor targeting. A lot of interview processes, especially at BigTech, explicitly or implicitly target fresh graduates, by quizzing on the sorts of things fresh graduates will have top-of-mind. Many of those things are not top-of-mind for working programmers who’ve been in the industry a while, since they’re rarely used in actual day-to-day programming (this includes a lot of algorithm and data-structure questions, since most working programmers don’t implement those from scratch on a routine basis). This biases away from experienced programmers, and creates a self-reinforcing cycle: you hire a bunch of recent grads, and they come in and start interviewing people which pushes even more toward preferring recent grads, so you hire even more of them, and… then one day you look around and wonder why it’s so hard to find experienced people. This is especially bad in the places that do algorithm challenges, because usually they’re posing things that want you to come up with a solution that took top people in the field decades to come up with while not under any particular pressure, and they want it from you in 20 minutes. On a whiteboard. While they watch. The only way to pass these is to “cheat” by already knowing the answers in advance, which you do either by reading a book about interview problems, or by being a recent grad who just passed a bunch of exams on the material.

                                                      The solution here is to interview based on things that are actually relevant to day-to-day programming. You can, if you want to, find out about someone’s problem-solving skill while using questions and problems that involve things real working programmers actually do.

                                                      Speaking of which, problem #3: far too many interview problems are contrived and unrealistic.

                                                      You can do interviews based on real-world practical problems. Two of the best interview processes I’ve ever gone through did exactly this: one had a work-sample test where they gave you a simplified version of an actual problem from the domain they worked in, the other did a collaborative session where you had to debug a piece of code extracted from their real system and find the real problems in it. Putting together an interview based on these kinds of problems doesn’t take a ton of time, and gives you a much more realistic idea of how someone will perform in your company than the million and first shibboleth problem that tries to test for “fundamentals” but really only checks whether someone was taught the test.

                                                      Problem #4 is measuring things that don’t matter. Whiteboard design can be useful, but whiteboard coding isn’t. Algorithm regurgitation isn’t. Trivia isn’t. Having open-source contributions on GitHub isn’t. Having lots of free time to do competitive “challenges” isn’t. And a lot of “soft” factors like confidence aren’t.

                                                      Measure the things that matter. Measure how well someone can ask questions about a problem or communicate ideas on how to solve it. Measure how well someone works with others (pair programming can make a great interview session if you do it right). Measure how well someone finds and uses resources to help them work through a problem. Measure how well someone interacts with non-engineer colleagues. We’ve all worked with people who were good and people who weren’t so good; figure out what the good ones had in common and measure for that. It’s almost never going to be things like “they were really good at writing linked-list implementations on a whiteboard”.

                                                      Here are some concrete ideas for more useful interviews.

                                                      First, always let the candidate use a real computer with real programming tools and access to references, Google, and Stack Overflow. I make a point of telling people that I’ve written significant chunks of Django’s documentation but I still have that documentation open in tabs when I’m working; it’s outright nonsense to forbid that while also claiming you measure realistic performance.

                                                      Second, use technical sessions that avoid the problems outlined above. Here are ideas:

                                                      • Code review. Bring a piece of code (as realistic as possible) and have the candidate work through it with you. Have them demonstrate that they can read and understand it, ask productive questions about it, and offer constructive and useful feedback on it.
                                                      • Pair programming. Bring something with a known bug, have them debug and fix it with you. Have them demonstrate that they understand how to approach it, search for and identify the problem, and work up a fix.
                                                      • Give them notes from a real problem, and be prepared to answer questions about it, and have them write a brief post-mortem for it. Have them demonstrate they can take in the information you’re giving them, usefully probe for anything missing, and synthesize it all into an explanation of what happened.
                                                      • Bring them a rough feature spec and ask them to refine it and break it down into assignable units of work. Have them demonstrate they can ask good questions about it, figure out the needs and the tradeoffs involved, and come up with a sensible plan for how to go after it.

                                                      Third, use non-technical sessions! And not just a “culture fit” lunch with the team. Have them do a session with a PM or designer or other non-engineer colleagues to see how they interact and watch for signs of whether they’ll have productive working relationships with those folks.

                                                      Finally, standardize your evaluations. It’s OK if there are different possible combinations of sessions (some people may prefer to do a take-home work sample, others may prefer to pair live and in person, etc.), but it’s not OK if interviewers have different rubrics for grading. Write out, explicitly, the qualities you’re looking for, in specific terms (i.e., not “confidence” or “professionalism” – those are vague weasel words that shouldn’t be allowed anywhere near an interview scorecard). Write out how interviewers are supposed to look for and evaluate those qualities. Set explicit baseline and exceeds-expectations bars for each session. Write scripts for interviewers to practice on and follow when presenting problems. Have interviewers practice running the sessions with current employees, and have some of your acting “candidates” try to pull sessions off-script or fail, to make sure interviewers know how to handle those cases gracefully.

                                                      And finally, treat candidates like people. Someone you’re interviewing should be seen as a colleague you just haven’t worked with yet. Designing a process to be adversarial and to treat everyone as a con man will yield miserable and unproductive interviews.

                                                      Now, I got voted “-2, troll” in my previous comment for citing sources that the typical coding interview doesn’t measure things that actually matter and in fact selects for things that correlate negatively to on-the-job performance. But I could cite plenty more. This video, for example, is a former Google employee who at one point recounts the story of a frustrated recruiter who revealed to a hiring committee he served on that they’d all just voted “no hire” on slightly-anonymized versions of their own interview packets and how it exposed the brokenness that was going on there. This article from a company that provides interviewing tools goes into detail on just how unreliable it is to use something that seems like it might be a proxy for real on-the-job skills (key takeaway: scores assigned to candidates by interviewers were all over the place, and inconsistent even for the candidates with the highest mean performances, fully one-third of whom outright bombed at least one interview).

                                                      Interviewing is broken. It can be fixed. Both of these should be uncontroversial facts, but the fact that multiple people here saw them as “trolling” is indicative of the real problem.

                                                      1. 2

                                                        I regret I have but one upvote to give for your comment.

                                                        1. 1

                                                          Excellent comment. I particularly like the part that goes from practices focusing on recent grads that becomes self-sustaining. That could be actionable under anti-discrimination laws. I’ll try to remember that.

                                                          If -2 was what I think it was, then that might be how intro had a tone that looked aggressive, dismissive, or something else. People here are more sensitive to that than most places both in terms of most of us wanting civility and what a large group deems as inclusive speech. Your comments will get better reception if you present your counterpoints without any rhetoric that comes off as a personal attack or dismissal.

                                                2. 0

                                                  In my CV you can see that I have created number of large services to be used by entire countries, 24/7. This can easily be checked even real time (I have admin access to all of them which I can demonstrate immediately ). You want me to whiteboard ? No!

                                                  Furthermore, I will make sure all of my senior IT friends and colleagues know how much you suck as a company (in this land, you can count seniors on fingers ATM) so good luck for you finding one.

                                                  It looks to me that many people do not get it - senior developers are celebrities today.

                                                  Me? I’ll rather collect peanuts then make somebody else rich(er) on my work without fair compensation, respect and professionalism.

                                                  1. 6

                                                    Me? I’ll rather collect peanuts then make somebody else rich(er) on my work without fair compensation, respect and professionalism.

                                                    Your response made me take a step back and think about what we’ve all been saying here, and I came to a couple of conclusions.

                                                    1. I am not a software developer per se. I work in the devops space. I do write software, but it’s nothing even remotely on the order of magnitude that the average Crustacean does. I write simple process automation scripts in Python and occasionally Ruby or Bash. This informs both my world view and the kinds of things I would ask people to whiteboard. As in, they are not at all algorithmically hard, things like “Print the duplicates in this list of numbers” and the like.

                                                    2. Reading all of you express such vehement opposition to the idea certainly has me questioning its wisdom when interviewing software devs, and also wondering if the experiences you’ve all had were at the hand of people who weren’t very mindful of candidate experience in how they were conducting their interviews in general.

                                                    In any case, it’s all very good food for thought, and I will now shut up on this topic and think on all of this.

                                                    1. 5

                                                      Based on my own experience, it is not that uncommon to find someone with “years of programming experience” on their resume, but has trouble solving basic programming tasks. This is because experience comes in a ton of different shapes and sizes. For that reason, before I can be okay with hiring someone in a technical capacity, I really need some kind of evidence that they can write code well. Whether that’s looking at code they wrote previously, giving them a new coding assignment, a white board interview, a presentation or maybe just prior experience working with them, I don’t really care. But there needs to be something. If I just took peoples’ word for it, the results would be pretty bad.

                                                      I think people in this thread generally underestimate just how many people are out there that claim coding experience but fail to meet some really minimal standards. I’m talking about things like Fizz Buzz. Some kind of evaluation process is necessary in my experience.

                                                      Personally, I think the person you’re talking too is being way too unreasonable.

                                                      Everyone gets way too hung up on this shit. There’s a saying that goes something like, “all models are wrong, but some are useful.” It applies just as well to hiring practices. You can’t get it right all of the time, and some of your techniques might indeed yield false negatives. This is basically impossible to measure, but since a false positive is generally perceived as being much more costly than a false negative, you wind up trying to bias toward rejecting folks that might be otherwise qualified in favor of avoiding false positives.

                                                      The whole thing is super hand wavy. People just seem to get obsessed with the fact that Hiring Practice X is wrong one dimension or another. And they’re probably right. But so what? All hiring practices are wrong in some dimension. And even this differs by experience. For example, a lot of people love to poo-poo whiteboard interviewing because that’s not reflective of what the job is actually like. But that’s not true for me. I use the whiteboard all the time. It’s a pretty useful skill to be able to go up to a whiteboard and communicate your ideas. Obviously, the pressure of evaluation isn’t there when you’re on the job, but I don’t see how to relieve that other than by limiting yourself to hiring people you already know.

                                                    2. 1

                                                      In my CV you can see that I have created number of large services to be used by entire countries, 24/7.

                                                      I want to remind you that this doesn’t matter at all in terms of good, software engineering. There’s both lots of crap tech out there with high usage and countries that demand even crappier tech. High uptake doesn’t mean anything except you worked on something that had high uptake due to you or more likely someone else given how businesses/governments decide what to use. If you doubt this, I hit you with my COBOL argument: why not hire someone how knows what billions of lines of mission-critical code are written in? Must be better than almost everything else if argument by uptake and net worth in critical areas is meaningful.

                                                      Or that’s just social-economic forces making that happen in a world where we need to consider other things. ;)

                                                  2. 1

                                                    I think the whole point of the article here is that there is no one best type of interview. Some candidates have anxiety attacks when mild pressure is applied, and do much better in a lower-pressure situation like a take-home assignment, and don’t mind spending the time on it. Some candidates have families or other obligations and can’t spend (unpaid) hours outside of their normal job writing up a solution to somebody’s take-home assignment, but do just fine solving problems on whiteboards. Probably some others have issues with both of those and need something else again.

                                                  3. 9

                                                    I think that’s a very different situation when you’re already comfortable with your environment.

                                                    1. 9

                                                      Couldn’t disagree more with you, either. I’ve also been in this industry for 30 years with almost all of them being an actual ‘software developer’ and I can count on one hand the number of times that I’ve had “produce now!” moments. Perhaps I’ve been lucky, but in my experience, these are rare, 1% times, when there’s a demo or something the next day and you’re trying to get something out the door. Given that, why exactly should we measure this? Even given those high pressure situations, you’re not standing alone, at a whiteboard or in front of a panel, with no resources ( google, library, other engineers ), no context ( mystery problem… you don’t get to know until you have 2 hours to solve! ) and no backup plan. Even with all of those caveats, I have NEVER had to cough up a random data structure with no reference material/resources/etc. in less than an hour or two EXCEPT in an interview.

                                                      1. 1

                                                        What I’m hearing is that a lot of people have had really bad experiences with whiteboard interviewing.

                                                        If the interviewer is hung up on syntax, they’re IMO doing it wrong.

                                                        1. 2

                                                          If someone presents a problem for you, do you immediately recall all algorithms you’ve learned and start whiteboarding that? That’s generally what happens in these whiteboarding sessions that I’ve been in. I don’t remember a ton of stuff off-hand and search for it all the time. Should that count against me? If it does, I don’t really want to work at that place anyway.

                                                          1. 1

                                                            I realized (as I wrote in another reply to someone else) that there’s a disconnect here.

                                                            I’m not a software developer. I do devops work which means I write a lot of VERY simple process oriented automation scripts in Python and occasionally Ruby or Bash.

                                                            When I do whiteboarding with candidates, the most algorithmically complex I get is “print the duplicates in this list of numbers” but mostly it’s things like “Here’s a json blob that lives on an http server. Write code that grabs the blob and connects to each host in a group given on the command line” type things.

                                                            But even so I certainly see where you’re all coming from, and can appreciate the idea that there are definitely better tools out there, especially for cases where you’re not doing hiring at scale.

                                                            Which makes me wonder, how might one apply all this anti-whiteboarding sentiment in a large corporate environment? How do you get take home exams, pairing, or whatever to be effective when you need to hire 50 people in a month?

                                                            1. 2

                                                              I used to work at Capital One and we were always trying to hire people. Each team largely handled its own hiring, though, and we had .. so many teams. Some teams do a whiteboarding session, some do a take home assignment, some do a little pair programming exercise. It really depends on the team and the people.

                                                              I’m not anti-whiteboarding for things like what you mentioned, but if someone is asking me to regurgitate a CS algorithm that I haven’t touched in decades, I don’t really get the point.

                                                      2. 3

                                                        Hmm. I’m not up to 30 years experience at this point (closer to 20), but I’ve never had this happen to me. Even when production bugs hit, it’s not a “We need you to produce. NOW” scenario, but an all-of-us circling the wagons type of deal to track it down. Even in startups where I was the only person writing code, it was never like that. That seems really unusual to me. I don’t know what country you’re in, but for context, I’m in the US.

                                                        1. 4

                                                          OK. We need you to produce. NOW

                                                          Oh, you work for those type of guys who think programming is like manufacture so you can measure it by the number of bricks in the wall, LOC, or something. I don’t accept that kind of job. I know better. I witnessed it dozens of times for other companies I consult for and that kind of job is always substandard.

                                                          I envy you

                                                          Its better idea to fight for your rights (our rights, really).

                                                          but I’m unsure whether or not your experience is one that many others share

                                                          I am sure its not. I am sure its opposite. But that is where I draw the line. I don’t mind fixing simple things here and there ASAP, but designing entire/parts of app/service without adequate time is no bueno.

                                                          1. 4

                                                            Oh, you work for those type of guys who think programming is like manufacture so you can measure it by the number of bricks in the wall, LOC, or something. I don’t accept that kind of job. I know better. I witnessed it dozens of times for other companies I consult for and that kind of job is always substandard.

                                                            This is kind of a cheap shot and also? It’s not true.

                                                            But even if it was, people work for different reasons. I live in a society that doesn’t provide much of a net if you fall, and I have some medical conditions which require some fairly expensive care.

                                                            So, yes I work for a company that pays well. I put a LOT of blood, sweat and tears into my job, and I won’t apologize for that.

                                                            Might it not be the kind of place you’d want to work? I don’t doubt that, and I’m glad you’ve been able to find work that suits your particular needs and wants, but please consider that not everyone is you before making broad statements about people and workplaces when you have zero information.

                                                            1. 4

                                                              Besides the broad generalizations, I find myself between both of you. majkinetor strikes a cord when he says one must fight for their rights. I’d add that once one finds ones self (if ever) in a position wherein one can enlighten the company masses than one should do what one can. But, feoh, isn’t incorrect either. Sometimes you just gotta play the game. I have only worked for places that tend to think of programming in terms of lines of code. It’s really why I am always looking for a new place to work. And, yes, I hate interviewing as well, which makes my conundrum annoying.

                                                              1. 1

                                                                But even if it was, people work for different reasons. I live in a society that doesn’t provide much of a net if you fall, and I have some medical conditions which require some fairly expensive care.

                                                                We do generalization here, any kind of behavior may be adequate in specific context.

                                                                So, yes I work for a company that pays well. I put a LOT of blood, sweat and tears into my job, and I won’t apologize for that.

                                                                Who asked you to do this ? When I speak, I speak about myself and what I think, I am not giving lectures or judgement.

                                                                when you have zero information

                                                                Not zero, I am in this business more then 30 years (also with medical conditions). Don’t be angry :)

                                                                1. 2

                                                                  Not zero, I am in this business more then 30 years (also with medical conditions). Don’t be angry :)

                                                                  I can see where I came off as defensive there. I’m not angry, I’m just surprised at the expectations some folks have around the interview process.

                                                                  If you can find work with those expectations, that’s fantastic.

                                                          2. 1

                                                            I think you’re combining two different things here - having a candidate write things on a whiteboard in an interview, and interviewing a candidate based on solving highly abstract problems that have little relation to the actual day-to-day work of building software, stuff like writing binary tree manipulation algorithms.

                                                            I think the second is a ridiculous thing to judge candidates based on almost all of the time, unless of course you’re doing one of the few jobs that actually involves doing stuff like that.

                                                            The first though, is a perfectly good way to determine whether candidates can actually produce code.

                                                            1. 0

                                                              The first though, is a perfectly good way to determine whether candidates can actually produce code.

                                                              Producing code on whiteboard? I had that on university on exams and many “programmers” came out of it without using a computer single time during the entire studies (I know, my sister was one of them, never turned a computer on until she finished computer studies! and got a job). Doesn’t inspire…

                                                          3. 4

                                                            Mine is kind of like the protagonist’s job in Office Space, but with more SIP trunking.

                                                            1. 3

                                                              At most places I’ve worked pressure was 99% of the simmering kind. Less than 1% I’ve had that flashpoint pressure but frequently it was artificially created to “increase productivity”. Basically the only time when you have to deliver NOW is during major production incidents.

                                                              I’d bet that even at your “Major Cloud Company” the percentage of people involved in solving a major production incident are in the low double digits.

                                                              I have frozen during whiteboard interviews and I’m far from a shy person. Day to day I’m more likely to be the kind of person that makes others freeze - and I don’t say that as some sort of self-praise, quite frequently it’s not a good trait.

                                                              In my opinion, even with your highly data driven process, if you work for a “Major Cloud Company” you can just ask for a painting competition among your candidates and you’d get the same results. Your company probably pays a very high salary compared to the market so competition would be fierce and people willing to train for 6 months on the intricate details of painting while holding a full-time job at the same time would probably make at least half-decent coders :)

                                                              TL;DR: It’s the high salaries and very competitive recruitment pipeline that produce results, not necessarily the actual interviewing details, in my opinion.

                                                              1. 1

                                                                I share your opinion - note that, in my mind, the “increase productivity” methods actually are very harmful in the long run

                                                              2. 1

                                                                But like any other fight / flight response where no actual mortal peril is involved, you can work through the anxiety and learn to process the situation differently, and once you do, it’s incredibly empowering!

                                                                I’ve been thinking about this point for several days now.

                                                                I haven’t been in the habit of thinking about interviewing in terms of a set of skills one can acquire/improve. However, perhaps if I can get myself into this mindset, it will help me to do something other than just walk into a new place and fly by the seat of my pants :)

                                                                1. 1

                                                                  I’ve been thinking about this point for several days now.

                                                                  I haven’t been in the habit of thinking about interviewing in terms of a set of skills one can acquire/improve. However, perhaps if I can get myself into this mindset, it will help me to do something other than just walk into a new place and fly by the seat of my pants :)

                                                                  I am sincerely grateful for the fact that at least one person took the advice I was giving in the spirit in which it was meant :)

                                                                  It most definitely is a skill, and here’s how I know that:

                                                                  There was a period in my career when I was much better at interviewing than actually doing the work. My work ethic has never been in question, I will work to the point of stupidity at times, but I had made some rather near sighted choices around which skills to build (learning new technologies in a very shallow way VERY quickly) over skills I should have focused on (attaining mastery in a few key tools and subject areas)>.

                                                              1. 4

                                                                It’s helpful to understand the frame of reference the Author has here. Charity was an eng/ops person at Facebook, before going to found her own startup. FB culture, as we all know, is “deploy constantly” and “move fast”. Her message isn’t a terrible one, “Make sure you can deploy anytime, all the time, without fear” but it’s clearly not applicable in many cases. Personally, it feels like she’s leaning WAY TOO hard on this, because it’s provided her some marketing movement.

                                                                1. 2

                                                                  FB only very recently achieved continuous deploys, and I never really worked much on FB systems. My frame of reference is much more Parse, Linden Lab, Honeycomb etc. Not sure where you think there’s any marketing value to Honeycomb; I feel passionately about this topic because I have seen it transform teams and their productivity, when they make even marginal improvements to their pipeline.