1. 18

    I have the impression that under many companies standards, Dan wouldn’t be hired. I’ve made a couple of interviews and probably I wouldn’t recommend him either (that is if I wouldn’t know he was Redux’s creator). I know that Jack of all trades and master of none is something that in general few companies (if any) would be hiring for. But, this has made me re-evaluate how the process and criteria should be handled. Awesome post!!!

    1. 14

      I know that Jack of all trades and master of none is something that in general few companies (if any) would be hiring for.

      As a jack of all trades, I find/found work just fine ;)

      1. 5

        Same here, I change jobs every one or two years to some kind of software developer I haven’t tried before. Every company seems to want one or more tech generalists.

      2. 3

        Some of the best interview advice I ever read (can’t recall where) was along the lines of - “Your job as an interviewer is not to just find out what the candidate doesn’t know, but to find out what they’re really good at”

      1. 9

        Also, time of year may be having an effect? I was applying/interviewing around this time last year, and didn’t start getting callbacks until January. I’m sure lots of companies are hiring throughout the holidays in the US, but many just leave the positions open and start sifting through resumes after (from what I’ve gathered).

        1. 13

          Just to add to the list of phrases - I’ve often found “work hard, play hard” to be a warning sign. After doing a phone interview or a couple interviews into the process at companies that had something like this in their job postings or about us/“culture” page, I’ve usually been able to suss out that that basically means “work a lot more hours than normal, and in the little free time you do have, play hard”

          1. 14

            Not only that, the “playing hard” will be done with your work colleagues. It’s a huge red flag that says to me “we will consume all of your waking hours”.

          1. 2

            Preparing for a whiteboard interview after 12 years in the field by slowly solving LeetCode problems. I know now how much I suck at writing software. The light at the end of the tunnel, at least for me, is that I will be slightly better after a few weeks of this practice. This thought is very freeing. Good luck to me.

            1. 2

              I might be reading into what you wrote, but I would absolutely not confuse leetcode problem-solving with software-writing ability. Those silly brain-teaser type problems I liken to the SAT/ACT (US college admissions tests). They test your ability to take them, not your intelligence.

              1. 3

                Right, but leetcode style problem solving does map pretty well onto the sorts of nonsense problems one encounters in white-board interviews.

                1. 2

                  I would agree that solving LeetCode problems for an interview isn’t the same skill as actual software development, but there’s good evidence that SAT test does in fact measure intelligence in an abstract sense rather than simply the ability to take a SAT test divorced from other desirable uses of brainpower.

              1. 3

                Taking a couple days off from work… realized I hadn’t taken any time off in 5-6 months :(

                Then working on some JS unit testing blog posts :)

                1. 5

                  Just to add my 2c - I worked remotely for a company for about 15 months (had been on-site for 2 years before that) and took at job at a new company (on-site) about 8 months ago.

                  It’s small (<15 ppl) so I went into it figuring everyone would be pretty close, hanging out, getting lunch together, etc. This was a major assumption on my part, and one that ended up not being correct, as no one at this new company actually talks to each other at all. I actually get less human interaction now than I did when I was working remotely.

                  So I would try to figure out best you can if the company you’re looking at would actually give you the human connection you seem to be missing with remote. best of luck

                  1. 4

                    So I would try to figure out best you can if the company you’re looking at would actually give you the human connection you seem to be missing with remote. best of luck

                    spot on - this is a huge assumption, and I plan to work it out in my research of the other company. Thanks for sharing. FWIW I actually don’t really want to hang out with people outside of work - I actually seek the in-person collaboration, desk chatter, and water cooler stuff more than anything.

                  1. 8

                    If someone pulls something like that and you are experienced, please do this:

                    • Inform them how useless it is
                    • Don’t do it
                    • Tell them you are going to look elsewhere

                    If you don’t like the game, don’t play it. There are so many IT jobs, both remote and on-site, that most people with some previous experience doesn’t have to go through this stuff to get hired.

                    1. 3

                      Yeah I’m glad you mentioned this.

                      At the beginning of this year I was interviewing with companies. First time I was interviewing since I wasn’t relatively junior. But going into it I still had the mindset of the last time I had interviewed (3+ years ago), which was basically “I don’t have that many options, I need to pick the first job that picks me, I should jump through all the hoops they ask me too, etc.”

                      Boy did that burn me bad, but hey lesson learned. Next time I will refuse to waste my time on ridiculous 40hr take-home projects, multiple rounds of take-homes, etc.

                    1. 3

                      (for context: I’m a solid TDD believer and practitioner)

                      My worry with TDD marketing is that people really get stuck on the “test” word and misunderstand it as “write the kinds of tests you currently write…except before the application code” and that just confuses everyone because the TDD tests are very different from the kinds of unit tests one would typically write. Tests are just a vehicle for the practice and I think they’re used to drive TDD because we typically have infrastructure in place that runs the test code quickly and easily.

                      Either way, I like the framing that this post gives the practice as a versatile tool with many uses!

                      1. 2

                        That’s an excellent way of describing it! I think you hit the nail on the head - people get tripped up on the “test” part of it.

                        When I’m “in the zone” with TDD it doesn’t even feel like writing tests at all really, it just becomes an extension of my design or coding process, and the “ceremony” or “separateness” of the tests kind of starts to fall away.

                        BDD (behavior driven development) kind of moves away from thinking of this as purely a testing practice, at least by using the word “behavior” rather than “test”, but I don’t think many people think of BDD as writing tests first.

                        I’ve often thought of TDD (and unit testing in general) as kind of like a visual design aid in which instead of a whiteboard or design doc, you visualize the problem by defining your inputs and your expected outputs. I might write another post similar to this one using the “visual learning” concept as a basis for another way of thinking about TDD.

                      1. 5

                        I’m trying to convince my workplace to get rid of whiteboarding interviews, does anyone know if there are resources for ideas of alternatives? Anyone have a creative non-whiteboarding interview they’d like to share?

                        1. 7

                          The best that I’ve found is to just ask them to explain some tech that’s listed on their resume. You’ll really quickly be able to tell if its something they understand or not.

                          My team does basic networking related stuff and my first question for anyone that lists experience with network protocols is to ask them to explain the difference between TCP and UDP. A surprising number of people really flounder on that despite listing 5+ years of implementing network protocols.

                          1. 6

                            This is what I’ve done too. Every developer I’ve ever interviewed, we kept the conversation to 30min-1hr and very conversational. A few questions about, say, Angular if it was listed on their resume, but not questions without any context. It would usually be like- “so what projects are you working on right now? Oh, interesting, how are you solving state management?” etc. Then I could relate that to a project we currently had at work so they could get a sense of what the work would be like. The rapid-fire technical questions I’ve find are quite off-putting to candidates (and off-putting to me when I’ve been asked them like that).

                            As a side note, any company that interviews me in this conversational style (a conversation like a real human being) automatically gets pushed to the top of my list.

                            1. 4

                              Seconded. Soft interviewing can go a long way. “You put Ada and Assembler on your CV? Oh, you just read about Ada once and you can’t remember which architecture you wrote your assembly for?”

                              1. 3

                                I often flunk questions like that on things I know. This is because a question like that comes without context. If such a problem comes up when I’m building something, I have the context and then I remember.

                                1. 6

                                  I don’t think any networking specialist would not know the difference between TCP and UDP, though. That sounds like a pretty clear case of someone embellishing their CV.

                                  1. 4

                                    So if you can’t whiteboard and you can’t talk about your experience, what options are left? Crystal ball?

                                    1. 3

                                      I like work examples, open ended coding challenges: Here’s a problem, work on it when you like, how you like, come back in a week and lets discuss the solution. We’ve crafted the problem to match our domain of work.

                                      In an interview I also look out for signs of hostility on the part of the interviewer, suggesting that may not be a good place for me to work.

                                2. 5

                                  A sample of actual work expected of the prospective employee is fair. There are pros and cons to whether it should be given ahead of time or only shown there, but I lean towards giving it out in advance of the interview and having the candidate talk it through.

                                  Note that this can be a hard sell, as it requires humility on the part of the individual and the institution. If your organization supports an e-commerce platform, you probably don’t get to quiz people on quicksort’s worst-case algorithmic complexity.

                                  1. 7

                                    I certainly don’t have code just sitting around I could call a sample of actual work. The software I write for myself isn’t written in the way I’d write software for someone else. I write software for myself in Haskell using twenty type system extensions or in Python using a single generator comprehension. It’s for fun. The code I’ve written for work is the intellectual and physical copy of my previous employers, and I couldn’t present a sample even if I had access to it, which I don’t.

                                    1. 5

                                      Yup, the code I write for myself is either 1) something quick and ugly just to solve a problem 2) me learning a new language or API. The latter is usually a bunch of basic exercises. Neither really show my skills in a meaningful way. Maybe I shouldn’t just throw things on GitHub for the hell of it.

                                      1. 4

                                        Oh, I think you misinterpreted me. I want the employer to give the employee some sample work to do ahead of time, and then talk to it in person.

                                        As you said, unfortunately, the portfolio approach is more difficult for many people.

                                        1. 1

                                          I write software for myself in Haskell using twenty type system extensions or in Python using a single generator comprehension. It’s for fun.

                                          Perhaps in the future we will see people taking on side projects specifically in order to get the attention of prospective employers.

                                      2. 3

                                        I recently went through a week of interviewing as the conclusion of the Triplebyte process, and I ended up enjoying 3 of the 4 interviews. There were going to be 5, but there was a scheduling issue on the company’s part. The one I didn’t enjoy involved white board coding. I’ll tell you about the other three.

                                        To put all of this into perspective, I’m a junior engineer with no experience outside of internships, which I imagine puts me into the “relatively easy to interview” bucket, but maybe that’s just my perception.

                                        The first one actually involved no coding whatsoever, which surprised me going in. Of the three technical interviews, two were systems design questions. Structured well, I enjoy these types of questions. Start with the high level description of what’s to be accomplished, come up with the initial design as if there was no load or tricky features to worry about, then add stresses to the problem. Higher volume. New features. New requirements. Dive into the parts that you understand well, talk about how you’d find the right answer for areas you don’t understand as deeply. The other question was a coding design question, centered around data structures and algorithms you’d use to implement a complex, non-distributed application.

                                        The other two companies each had a design question as well, but each also included two coding questions. One company had a laptop prepared for me to use to code up a solution to the problem, and the other had me bring my own computer to solve the questions. In each case, the problem was solvable in an hour, including tests, but getting it to the point of being fully production ready wasn’t feasible, so there was room to stretch.

                                        By the time I got to the fourth company and actually had to write code with a marker on a whiteboard I was shocked at how uncomfortable it felt in comparison. One of my interviews was pretty hostile, which didn’t help at all, but still, there are many, far better alternatives.

                                        1. 1

                                          I’m a little surprised that they asked you systems design questions, since I’ve been generally advised not to do that to people with little experience. But it sounds like you enjoyed those?

                                        2. 1

                                          There are extensive resources to help with the evangelism side of things.

                                        1. 3

                                          As someone who just went through the interviewing process in Chicago, this pretty much mirrors my experience exactly. I will say though that I did not mind recruiters having me meet with their whole team as I felt like they were able to get a better sense of what I was looking for in my next position. I too am baffled at the IP clause/non-competes in Chicago too… it’s quite unfortunate

                                          1. 3

                                            Businesses tend to derail software development practices because they tend to view it as “hip brand name for how we exert power over employees”.

                                            They will hang on to small pieces of a methodology as a cover for something else.

                                            For example they may weaponise “daily agile standup meeting” for micro-management.

                                            1. 1

                                              Exactly - this is the most dangerous thing about “Agile”. It makes software developers the least important and least powerful people in software development, when really we should be the ones controlling our own field.

                                            1. 7

                                              I think it’s important to ask why Agile is so easy to screw up. We don’t want fragile software applications and certainly shouldn’t want fragile software methodologies either.

                                              1. 2

                                                imho if agile fails, it usually is because people applied some Agile workflow (like Scrum) while losing orientation of the goals these methods want to achieve. For example:

                                                • User stories are unclear / badly written. This is probably a very overlooked problem, but I have seen it many times. Sometimes the wording is not understandable at all, or no acceptance criteria are defined, or they spell out the technical realization instead of the functional requirement, leaving no room tfor engineers to find a better solution / architecture for the change. The solution is to have good refinement meetings were devs read and challenge stories, ask questions, get the PO to remove implementation advice but add intent of functionality and demand proper acceptance criteria.
                                                • Backlog is prioritized sloppily by the PO, this is especially harmful if it is done in a way that delays an initial break through of getting a prototype up and running.
                                                • Confusing “Agile” for only planning the next two weeks. Doing scrum does not mean that you shouldn’t think about a roadmap or plan for the next year. However, it is important to plan on a much coarser level for long -term planning, and not stick to plans that are obsoleted by reality.
                                                • Lousy estimation. Many people think estimation is about planning, and that is partially right. However, estimation is also an indicator for whether a story is well-written. If 2 devs estimate a different workload for a story, chances are good that the story is not clear on what should be done.
                                                1. 2

                                                  Is Agile more or less easy to screw up than any other methodology? It could be that all methodologies are hard to follow; I remember reading that the most development popular process in practice (at 60% of those surveyed) was “no process”.

                                                  IME Agile mostly gets screwed up by not actually doing it - or by falling back to non-Agile as soon as anything goes slightly wrong. I suspect this is simply a case of people responding to their incentives; management is rewarded for claiming to adopt Agile, but has very little incentive to actually follow it.

                                                  1. 1

                                                    Probably more interestingly is what would be the alternative to Agile?

                                                    1. 3

                                                      Spiral, Chaos, Unified Method, OOSE, Rational Unified Process… there are few, and while some of them (looking at you RUP) are widely known to be terribad I don’t think all of the others can be dismissed out of hand. One of the challenges is that research into it kinda stopped (TtBoMK) after Agile went big.

                                                      1. 1

                                                        When I read comments criticising Agile, I often feel that the commenters would rather like to work on their own plans, i.e. with a goal in mind, start implementing and provide a solution. So it would probably be unfair to dismiss all of these attempts as chaos, but from what I have seen it requires above-average people to work. If it works, the work shows all signs of Agility (prioritization, delivering increments, working software over documentation, people over processes, etc.).

                                                        I have also seen truly chaotic development that was a pure waste. Also not pretty, and every time I read a critic of Agile, I worry that people would rather work this way.

                                                        1. 2

                                                          Chaos is a method inspired mathematical chaotic systems, not social chaos.

                                                          1. 1

                                                            ah, thanks for that hint.

                                                            To summarize it seems that Spiral and chaos could be applied in any agile workflow as a method to prioritize backlogs, they seem to operate a bit on other levels than RUP/Scrum/Kanban.

                                                  1. 3

                                                    Not only do companies doing the interviewing need to change the process, I think developers looking for jobs should start refusing to go through the whole whiteboard trivia nonsense. If that reached critical mass, companies would change their interview process real quick.

                                                    1. 2

                                                      How many job seekers really want to reject an opportunity over something annoying? When the bills are due and you need health insurance, that’s a rather bold move.

                                                      I could only see people with big amounts of savings doing this, and it’d only matter if they were obviously qualified. Otherwise, the recruiting team would shrug and move on, and the job seeker is left wondering if they made a huge mistake. There’s an obvious power dynamic here that can’t be ignored.

                                                      1. 3

                                                        That might be true if you’re unemployed and short on options, but often I find people interviewing are already employed and looking to make a change. So for them, saying no just means staying at $CURRENT_JOB a bit longer.

                                                        1. 2

                                                          Correct. The solution is to not let yourself get into a situation in which you are unemployed and looking for a job. That is shifting the power dynamic in your favor.

                                                      2. 1

                                                        I know of one startup in NYC that has an interview process pretty similar to this.

                                                      1. 3

                                                        This was an interesting puzzle, but I don’t really know why people continue to entertain these kinds of questions in interviews. To be fair, it’s possible the job required heavy use of algorithms, but as such a high percentage do not, at least not for day-to-day work, it seems kind of ridiculous.

                                                        I think developers collectively shoot themselves in the foot when we take part in such ceremonies and reduce the business value we bring to companies.

                                                        This quote from the article is truly disgusting to me - “This specific interview significantly hurt the offer I received. Unfortunately, there’s a lot of luck to the interview process as there is a lot of luck in life.” WTF?? The only thing more preposterous than the fact that messing up this problem hurt the offer is that this guy accepted that as his lot in life.

                                                        1. 3
                                                          1. 1

                                                            I’m considering making a hobby out of doing these interviews, heh.

                                                          1. 0

                                                            cool - thanks!

                                                            1. 3

                                                              I think it’s great that you posted this. More people should speak up about it. I also liked that you called out the potential for ableism. It’s ironic that an industry that professes to value diversity goes and shoots itself in the foot with exclusionary tactics like this.

                                                              I just found out the company I’m working for is setting up a 4month engagement to build an app with Pivotal, which is all XP. Im excited about the project but dreading having to do pairing 8 hours a day… funny thing is I’ve actually introduced a lot of pair programming into the company and am certainly a proponent of it but only for 1-2hrs a day and in certain situations (onboarding, difficult problems, etc).

                                                              1. 3

                                                                I’m super curious to hear your thoughts after you do it for several months.

                                                              1. 6

                                                                Aside from this, the Mac keyboards just aren’t great on your wrists/hands/fingers to begin with. I switched to an ergo keyboard and mouse about a year ago and have been pretty happy with the change.