I now consider myself one of these people. I've written and shipped a number of business applications, but have little understanding of CS concepts and was unable to complete some leetcode problems I tried a while back. Unfortunately, I find myself mentally unable to keep focus and and attention to properly learn. I've looked at going back to school as well, but cost make it impossible.
Anecdotally, i recently became semi_obsessed with operating systems and OS development.I tried to pick up C wanting to do some kernel development on NetBSD and thought it would be easy, given the familiar syntax, u just needed to learn pointer logic/ arithmetic. I was finally defeated after trying to write a program with multidimensional arrays and working with them decayed down to pointers. At the same time, though, I need a new job asap, so I've given up on the interesting stuff and am back to learning stuff for employability reasons only
I haven't seen any seen any sort of programs in my state, but it might be and issue that I'm not exactly a "non-traditional" student. I'm actually college aged,I just skipped college to jump into the workforce
I don't know if this is helpful, but for the introductory course in programming at University we followed an earlier edition of this free book: https://greenteapress.com/wp/think-python-2e/
Please don't. Do enough interview situations at companies you don't care much about to numb you down (I did); this helps with nervousness. And sometimes you find out that you don't actually mind working there, and end up being hired (I did).
I feel like I am similar. I have been reading A Mind for Numbers- How to Excel at Maths and Science by Barbara Oakley and it goes in to how to develop focus and how to learn. I find it pretty applicable to software development. It has been pretty good and something I am trying to apply. I would recommend it. Good luck to you.
Her Coursera course Learning to Learn is super helpful as well, I bought her book after going through her course, unfortunately it has sat on my reading list for the past 6m
> I now consider myself one of these people. I've written and shipped a number of business applications, but have little understanding of CS concepts and was unable to complete some leetcode problems I tried a while back.
I don't think fizzbuzz == leetcode? I thought fizzbuzz was like super basic can you write a for loop type question.
I think it's pretty common for people to not be able to do leetcode. I learned the concepts in college and usually did very well in class. I didn't even bother preparing for interviews and could still pass.
However, after working for a while I don't think I'd be able to do them anymore, or at least not at the speed which is expected.
You shouldn't feel so bad. Leetcode problems are tough, even the easier ones, and I have 10 years experience. When I was looking for a new job last year, I could barely finish one or two of them and felt pretty discouraged. But with practice, they become a lot easier and I was knocking them out. The problems are hard because they cover an area of programming that most developers don't work with everyday. It's a separate skill set.
I highly recommend Georgia Tech's online master's program. It's ranked in the top 10 of all CS programs worldwide. The total cost of the program is under $10,000, and you can take a class part time while you're working full time. I'm halfway through the program myself, and it's definitely helped me keep my skills relevant especially since certain technologies didn't exist when I got my Bachelor's in 2008.
Do you also have trouble keeping focus through the free Udacity or open courseware classes? If so, paying for classes seems like it would be a waste of money. It would probably be better to spend some time understanding why you can’t focus (lack of interest, no motivation, condition, etc.).
I definitely feel like part of it is what you listed. Heck I can hardly read linked articles fully and usually just skim them. I have a hard time doing anything that won't immediately return value (an issue that's gotten me in trouble elsewhere) and I'm just now crawling out from a bit of burnout.
But when I was a kid / teen, it feels like I could learn anything. I could remember how to write in multiple programming languages, a bit of their std lib stuff etc. Now if I'm not working with it at the moment, it leaves my brain. For example I worked on some Node.js a few years ago. Nowadays, I probably couldn't write it to save my life.
I don't think school is an especially good or efficient way to learn to program. The only way we actually have to learn how to program, is to try to do it. There are online tutorials, which can help some, but classroom instruction is not especially well suited to teaching it (it's more of an apprenticeship-style skill), and empirically they do not succeed at teaching it. The graduates with CS degrees who are able to program, mostly taught themselves how by doing it, and the concepts they learned in college are as often an obstacle that they need to unlearn in the "real world" as they are useful.
Harvard's CS50x on edx is an introduction to programming aimed at people who've literally never programmed before and has them finishing knowing C and how to use pointers.
You'd have a huge advantage over the typical student and could probably easily get over any problems with pointers by taking the course.
> FizzBuzz [...] You wouldn’t believe how many people can’t do it.
This is so true. IME, less than 50% of applicants can even get close. Mostly due to not remembering or even knowing about the modulo operator or a suitable workaround.
If mod isn't something needed for whatever their normal work is, is it a valid test? Or are you potentially throwing away otherwise good candidates because of it?
In my experience one sees roughly similar results with:
"Write a function which counts the number of a's in the input string."
"We will give you an array of words. Print out each word which appears more than 3 times in the array."
"We will give you two arrays of words. Print out each word which is in exactly one of the arrays."
It's not just the mod operator. These are toy problems for difficulty but they're not "implement the rules to a children's game"; with a few seconds of effort you can describe a boringly plausible business reason for having to implement them during a fairly pedestrian career.
Bear with my potentially dumb solution, but i'm trying to understand what an interviewer would look for in answering questions like these. For the third, in python, could you make both sets and print the symmetric difference? Does this (a) demonstrate practical knowledge of python or (b) necessitate a follow up from the interview to provide a solution that does more of the "work"?
If they take that shortcut in Python, it tells you that they probably know Python, which also likely suggests they could think it out if they had to. If they think it out the harder way, that shows they can do that, which suggests they can get some things done. It isn't rare to find applicants who have more than 10 years of experience who somehow can't do either.
Since these are riffs on fizzbuzz, the goal is just to evaluate whether a candidate can use programming to solve these at all, i.e. whether they can 1) think through how to accomplish a basic task with some data and code, and 2) implement it in a language they know.
The goal of fizzbuzz in a phone screen should not be to see if someone can solve it in an optimal memory-efficient framework-idiomatic way. Clever syntax and data structure use is lovely, but these are really about finding whether someone can use a 'for' loop and an 'if' condition.
I think this is becoming less true, but I think it was (rightfully) seen as a test of basic competence. Would you hire a chef that didn't know what a fork was even though you never use one to cook?
I had to learn C at some point though, and that used to be common. I suppose it's becoming a less useful test.
I would argue that every single programmer with at least the tiniest bit of tenure in the field (or a kid straight out of college who took at least some math classes) will have run into this at some point in their life.
Even if you (somehow) don't know about it, figure something out? Do something "stupid that works" like this:
You probably are rejecting potentially good candidates, but I would personally suggest that of the developers that I want to hire, most of them are members of the set of developers who know what the modulo operator is for. And since hiring is a numbers game, it seems like a reasonable filter. Besides, you are allowed to ask other questions in the interview.
The thing is, you don't need mod. You can, in more steps, arrive at the same output just using arithmetic. But everyone... non-programmers too... should understand the concept of "remainder after division" (of whole numbers).
If the test is interactive, the candidate can express, "I need to find out if this number is evenly divisible by that number; if so, then blah blah". Interviewer can remind them that x % 2 is "remainder of x when it is divided by 2". The point should not be whether someone can remember %, but whether they have any idea what minor goal they are trying to achieve.
I've had the same experience. I can forgive an interviewee for not remembering what symbol the modulo operator is, but not for not knowing what it is in the first place.
I've had the same experience asking applicants to reverse a string in a language of their choice. sometimes they'll give me a simple answer like "''.join(reversed(my_str))" (python), which i'll accept and move on to the next (harder) question, but even if you don't remember that syntax, you should be easily able to build a function using a for loop. I find that 50% of applicants can't and it saves me a lot of time finding this out early in the interview process.
I've written tens of thousands of lines of code, solved a plethora of complex problems, worked on a number of projects from requirements to production in an assortment of different languages and technologies and I can count on one hand how many times I've had to use the modulo operator.
This is first year-out-o-school, junior gate-keeping bullshit. We need better methods to evaluate intermediate and senior devs, and FizzBuzz ain't it
I regularly do technical phone screens at my company and it is amazing the number of people with masters degrees or very pedigreed backgrounds who are unable to solve a relatively simple problem. I think part of it is performance anxiety being put on the spot, but I have noticed that asking anyone to write java or c++ without an IDE is very akin to taking a fish out of the water.
I chuckled thinking about how much coding I've learned in interviews. Early on in my career I messed up on SQL joins and the interviewer walked me through my mistake before excusing me.
Maybe I'm in the minority for the HN community, but even I would struggle to write Java without an IDE. I've done it before and compiled manually using javac, but if someone asked me to do that in an interview I might struggle. The IDE just does too much in java, from generating boilerplate code, to managing packages and imports, and autocompletion.
Maybe that's the reason I've almost never done interview questions in java. I always use python/javascript, because I write those with VIM, even though, until recently I did only a small percentage of my professional programming with those languages.
This sort of finding always makes me wonder if the issue is that there are somehow loads of programmers who have apparently had long careers who can’t program or if there is something wrong with the method of determining it?
With quotes like:
> So, as someone who spends maybe 20% of their time hiring, it’s still a very effective screen. You wouldn’t believe how many people can’t do it. People at big companies, respected places. It’s surprising.
Shouldn’t people start questioning the validity of their method?
As a software developer, I spend much, much more time reading code, trying to understand code, looking for bugs in code, and tweaking existing code, than I do writing totally new software applications. Although I agree it is surprising that many people can't reason through fizzbuzz, it is very possible to make valuable contribution to a code base in a language that you don't have the syntax for the "main" function memorized.
It’s definitely possible to make some other contribution, but not as a “programmer”. I can’t imagine giving a task to someone who can’t construct a basic for loop and a conditional statement.
At this point, coding is the easy part for many applications[1]. Developers end up spending much more time trying to understand what it is they are being tasked to build by either understanding the business or clarifying requirements.
[1] I know us developers like to spend an enormous amount of time making things super complicated with fad tech, but we know a lot of it is not required.
This would be a fascinating, probably more reliable way to test someone: ask them to explain in as much detail as possible what a code sample did - what problem it appeared to be solving, and what edge cases it attempted to handle as well as perhaps some it would have failed to handle.
If you provide them a good sample, the function names and behaviors should give a really good sense of direction to the candidate, and the harder questions would be answered by the details of the code.
When I was running hiring at a previous startup, we ran into this issue often. When I proposed adding FizzBuzz to our screening process, I got a fair amount of pushback from the team that it was a waste of the candidates' time.
Once we'd actually started using it, though, we found it filtered between 20-30% of our applicant pool, even when we let them use literally any language they desired, presumably their strongest.
However, it usually only filtered fresh grads (CS students from top-10 schools). Those with previous work experience almost never had a problem.
The interesting thing to consider is that before implementing the screen, did you hire some people that would have failed fizzbuzz? It makes me wonder how valuable the fizzbuzz screen actually is if people can just do it after a little bit of work experience.
I suspect that candidates who are otherwise fine (and not misrepresenting themselves on their CV's), fail fizzbuzz because they overthink the problem, stumble on the not-so-frequently-used modulo operator and then paint themselves into a corner where they can't just loosen up, take a breath and figure out the solution.
Exactly. If a company hires a programmer who cannot solve fizzbuzz, then the company utterly failed at interviewing. And in my opinion, this may indicate that the company will fail in other important communication areas.
You should be able to have a 10 minute conversation with someone and know if they can solve fizzbuzz (without even posing the problem).
That 10 minute conversation is potentially far more nuanced than a go/no-go fizzbuzz quiz. It's a different thing altogether.
The fact is companies hire people all the time, without using fizzbuzz, probably hiring some number of people that would not have passed fizzbuzz if it were given to them. Were all those people definitely bad hires? I think not. The parent commenter's company had "survived" without it, and many do now.
It's understandable to want to have the ultimate "gotcha" interview question, the response to which screens out a candidate. It's not totally wrong, but there's a lot more to an interview. I think the onus should be on the hiring managers to develop their behavioral interviewing skills so that they're able to evaluate a candidate more fully than by using toy problem quizzes.
Speaking at least for myself in an interview role, I consider the modulo operator a bit of trivia that many programmers have no reason to encounter, and if you build a "divisible_by_5" function that works in some semi-sensible manner, I'd probably be happy.
When I proposed adding FizzBuzz to our screening process, I got a fair amount of pushback from the team that it was a waste of the candidates' time.
I've had the same, I was a contractor and not usually involved in the hiring process but I'd been asked for a question they could take to a candidate.
One of the team at the time was a young Maths grad, super bright but prone to being over confident. So I wrote a clear FizzBuzz question, passed him the pen and paper and asked him if he was sure when he was done. There was some minor issue, a boundary issue one think and he was livid with himself. So they took it to the candidate and apparently it was a bit of a disaster.
Personally, the first time I came across it was in an interview and I quite enjoyed it - simple enough to not be threatening but I guess sufficiently able to show I could write code as they offered me the role. They asked some extra questions too with some extensions and about how you could unit test it.
Beats having to implement red-black trees by remembering the crib sheet you read the day before.
That's the thing... you feel fizzbuzz is effective but the fact that it filtered out CS students from top 10 schools says more about the test then it does the student.
Think about it, it takes way more work, way more intelligence to get into and graduate from a top 10 school then it does to learn how to pass a fizzbuzz test.
I can 100% tell you that ALL CS grads from top 10 schools can pass fizz buzz given a day to do it. That being said I can also say literally most of your coworkers who are administering the fizz buzz test will not be able to ever attend a top 10 school given a lifetime to prepare.
It is incredulous to me that people can literally dismiss an MIT candidate because he didn't pass a fizzbuzz test. Do you not realize that it is 100x easier to learn programming then it is to get into MIT?
People need to get it through their heads. Programming is actually really, really easy. That's why there's so many people who can learn how to do it without going to college. But instead I see most people thinking that they are so intelligent they didn't need to go to college because they can just learn programming.... That may be partially true, but most of what I see is actually just people learning programming because they COULDN'T get into university.
But it still begs the question... what is making an MIT student fail a fizzbuzz test? It's like failing to recite a paragraph out loud with zero stuttering to an audience who is judging your future career. How could one possibly be so stupid and not stutter? If you stutter it must mean you can't speak english, just like how if you fail a fizzbuzz test is must mean you can't program.
To be honest I don't know why so many programmers fail. But I'm honestly pretty sure fizzbuzz is so dreadfully easy that there is some other factor that is influencing this high failure rate.
> To be honest I don't know why so many programmers fail.
Because many people are not capable of programming.
More importantly, the school you go to has nothing to do with your capability of a programmer. I worked with quite a few people in my CS department who couldn't program their way out of a paper bag. Most were still very bright people who I assume figured out successful careers.
I suspect a lot of the recent CS grads who can't do fizzbuzz end up following careers that don't require programming.
It's also important to understand that Computer Science is not Software Engineering. Computer Science is fundamentally a mathematical field. Don't conflate the two.
>Because many people are not capable of programming.
You think too highly of the field. Programming is easy. Everyone, and I mean everyone can do it and eventually become good at it, especially fizz buzz.
>I suspect a lot of the recent CS grads who can't do fizzbuzz end up following careers that don't require programming.
Nah, more than likely they learn the fizzbuzz question and still become programmers because programming is easy. It takes time to learn programming like it takes time to become good at basic algebra or calculus, but literally anyone can do it.
>It's also important to understand that Computer Science is not Software Engineering. Computer Science is fundamentally a mathematical field. Don't conflate the two.
The two fields are intricately related. Most junior devs who lack the academic rigor like to separate the fields into a dichotomy and use this dichotomy as an excuse to justify the lack of expertise on the academic side.
After a certain amount of time you'll realize that all of programming is rehashing the same concepts over and over again just in a new framework/language. To gain deeper insight into the nature of computer programming and engineering and to actually become better, the dichotomy must be eliminated. In the upper echelons of Software engineering, people will realize that computer science and software engineering merge to become the same thing. Juniors have yet to realize this.
Take this for example. Did you know that a unit test does not guarantee correctness of a function? To guarantee correctness of a function you'd have to write a unit test for every possible input of a function. Did you know that computer science offers a way to do prove your program 100% correct without writing a single unit test? This is an example of a merger of engineering and theory. A computer is a deterministic machine amenable to proof yet we choose to treat it like a black box and test it as it was a chaotic system that needs to be tamed. There are advantages and disadvantages to both methodologies but I illustrate this here to show you that SE and CS are in fact different aspects of the same thing.
Computer Science has very little to do with unit testing.
Look at things like theoretical computer science and category theory. The word "class" comes right out of basic category theory. (You don't need any category theory to program a computer, but it directly influenced object oriented programming.)
And, if you think programming is easy, consider yourself lucky. Take the time to learn some soft skills. Maybe you'll understand your downvotes.
> Take the time to learn some soft skills. Maybe you'll understand your downvotes.
lol, I'm not here to win votes. This is the internet. This comment alone shows a lack of soft skills on your side. Except for when the person I'm communicating with chooses to get personal I never get personal when I talk about things on the internet and I never hold back either, that's part of the appeal of being here. I can tell what I believe to be the truth without concern for your feelings. Despite the lack of concern for your feelings I do make deliberate effort to not attack YOU directly. I am aware that the things I say may piss people off but in all I'm just here to talk about the topic at hand without worrying about real world stuff like your feelings.
>Look at things like theoretical computer science and category theory. The word "class" comes right out of basic category theory. (You don't need any category theory to program a computer, but it directly influenced object oriented programming.)
OOP was invented before anyone knew that category theory had anything to do with computer science. Class most likely comes from set theory. Also if you work with category theory or languages that implement the theory you'd know that the morphism is central to the theory not the object. In other words it has much more to do with Functional programming then it does with OOP. OOP has virtually no theoretical basis and it fits into category theory in a very awkward way.
>Computer Science has very little to do with unit testing.
It does. I'm literally talking about how it does have to do with theory.
In computer science there are two ways to verify 100% correctness of a function. You either prove it correct given an initial condition and a final condition. Or you unit test every possible input with the associated output. Software Engineering chooses to go with neither approach. Software engineering chooses to go with a tiny subset of all possible unit tests and hopes that the correctness of that subset of tests correlates with the correctness of the entire domain. This is a more applied math (aka statistical) approach to verification that increases confidence but does not verify the program to be correct. (This is also debatable how much statistical rigor unit tests have as its a usually done with a very ad-hoc approach... unit tests are usually too few in number and highly biased).
All of this is part of Computer Science. You will note that the paragraph above uses the word "unit testing" Software Engineering is simply application of said theory or application of no theory but they can be one in the same.
>And, if you think programming is easy, consider yourself lucky.
I hear parents talking all the time about trying to teach their kids programming. Internet tutorials are all over the place. It's easy in the sense that mostly everyone can learn it. It's not easy in the sense that it does require a lot of effort.
What's hard is quantum physics. You ever hear of an internet tutorial that will teach you all of quantum physics? An udemy course that will cover all you need to know? Ever hear parents trying to teach their kid about quantum physics? Quantum physics is hard, programming is not.
Perhaps. Software engineering is hard, though, and it is not the same as CS. We turn out these CS degrees, and then we expect that they can do software engineering.
That said, fizz buzz may not be the best way to tell if people can do software engineering, either...
Software engineering is easy. Most people are familiar with it as an aspect of canned design principles to ensure safety and scalability. You can read about it all in books or internet articles and come up with it on your own.
Have unit testing, have integration testing... make it modular... SOLID, write layers, yada yada yada also very easy.
I always hear people say that Computer science != software engineering but really it's the same thing at the upper echelons. Rather than using your gut and all these anecdotal "principles" spewed out by people like Martin Fowler, design pattern books, or books on testing and agile you can actually use theory and science to guide your software engineering decisions.
Let's put it this way. Software engineering is the only engineering discipline where people can get away with not knowing science and mathematics and still build systems that can run. The effective and elite software engineer lets theory and science guide his decisions as well to make systems that are better.
I do agree with you that fizzbuzz is missing something.
This is so over-the-top that I can't tell if it's parody, trolling, or just horribly mistaken.
In case you're serious, though, you clearly have no clue what software engineering is. Yes, it includes some of the things you mention. No, it's not the same thing as CS at the upper echelons. Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.
BTW, because I don't know how to contact you to tell you this: Your HN profile says "Actively searching for opportunities. email me if interested", but doesn't actually provide an email address.
Just go to the "Subdisciplines" section in the wiki
Literally every example I mentioned is covered by a "subdiscipline" of software engineering. I'll quote the part that covers my examples:
"Software design:[1][23] The process of defining the architecture, components, interfaces, and other characteristics of a system or component. It is also defined as the result of that process.
Software construction:[1][23] The detailed creation of working, meaningful software through a combination of programming (aka coding), verification, unit testing, integration testing, and debugging.
Software testing:[1][23] An empirical, technical investigation conducted to provide stakeholders with information about the quality of the product or service under test.
Software maintenance:[1][23] The totality of activities required to provide cost-effective support to software."
What happened here is that I never had a strict definition of software engineering in my head. I do know that a big aspect of it usually has little to do with the theoretical side of things, so in my example I just mentioned all the "technical" terminology people throw around that has little basis in rigor or theory. Then when you said I have no idea what it is, I looked it up, and the definition literally covers almost everything that has to do with software including my examples.
There is literally zero chance you could have known that I have "have no clue what software engineering is" because my examples are covered by the definition stated in the wiki. That is zero chance unless you have no clue yourself.
A more accurate explanation is this: "software engineering" is a vague hand-wavy term. Sort of like how "Science" doesn't always involve the "Scientific method." You have some super clear definition of the term in your head, but clearly from this wiki not everybody thinks about it that way.
>Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.
When did I say only CS theory is enough? Many aspects of software and the real world don't have any science or theory to describe it. Usually when you encounter such an aspect of the real world the vernacular changes from "deriving" a solution to "designing" one. My emphasis is that many engineers are "designing" things that are ultimately covered by theory and ultimately can be "derived," they simply turn to "design" either because they are unaware of theory or the theory is too hard.
We are in agreement on the point you mentioned, but I never said all you need is theory. Humanities theories about the universe are prove-ably incomplete and unprovable in general, therefore we have no choice but to exit the theoretical world for many engineering problems.
>No, it's not the same thing as CS at the upper echelons.
By upper echelons I mean you've basically learned most of it, the only thing left is the theoretical part. The theoretical part is harder and usually something a software engineer gets into once he's figured out how the rest of the non-theoretical parts work. You'll note that "mathematics" encompasses "software engineering" as defined in the wiki. I'm also not sure why you disagree with me nor am I clear about your own definition of software engineering, so please explain if you can.
>BTW, because I don't know how to contact you to tell y...
I feel like you and everyone else are missing the obvious explanation: people who claim to be from a top 10 CS program who can't solve FizzBuzz in a few minutes lied about their background.
I find it hard to believe that anyone who has spent more than a week programming couldn't solve FizzBuzz. Even if they somehow weren't familiar with the modulo operator, you could just explain how it worked.
FizzBuzz is a way of easily filtering con artists.
You could be right. At the same time as unrealistic as it may be, I feel during interviews smart qualified people just screw up and have brain farts all the time.
An interview is almost like public speaking combined with an intense time based coding competition without allowing you to use an IDE.
I think a good number of these guys are lying. I agree with you. But I also think a good number are honest and actually failing.
It's so well known that everyone uses it to study for their interview. You'll end up hiring someone who just memorized the solution.
Instead, come up with your own unique programming challenge that the candidate hasn't seen before. It should be about as easy / hard as Fizzbuzz.
Related: I once interviewed a candidate who came across as knowing my questions ahead of time, and delivering a well-reheased answer. I made up a question on the spot, and got a "this wasn't supposed to be on the test" tone of voice in the answer. I rejected the candidate.
Technical interviews aren't things that the candidate should memorize and rehearse. That's why I'd never ask Fizzbuzz.
I don’t think anyone need to “memorize and rehearse” Fizzbuzz, the whole idea is it is so trivial that one can solve it on the spot without prior knowledge.
If one is concerned about people memorizing answer, it is pretty simple to change the question a bit to make it non-recognizeable,
Not everybody is good at performing under pressure on problems that come with ambiguous artificially imposed rules that you have to guess. I remember solving a problem that involved manipulating a list. There was an improvement to my algorithm that involved calling list.sort() before performing a slightly more efficient version of what I was doing. I didn't think calling built-in sorting algorithms was allowed. That's typically one of the implicit rules, until it's not, and you just have to figure out when it is and when it's not a rule.
This is why talking is critical during an interview. Typically my answer to any interview question starts with "I'd Google to find code that already solved the problem, but I'm assuming you want to see my implemention? Cool, and, can I use lodash/jQuery? No? Ok, so you're interested in my ability to transform data, let me just ..."
I was just thinking about programming and how to get better at it today.
I think a huge crutch for a lot of people is the immediate feedback loop execution gives you. Rather than truly understand the api we’re using, I think there’s sometimes a tendency for programmers to just skim, try a function call, and see what the repl/executable or w/e does, and to roll with that. While this works for getting things done it doesn’t really improve your understanding. I think practicing programming without the feedback loops the computer provides, e.g. based on documentation and reasoning alone, is a great way to become better and more disciplined. You can do this with pseudocode, whiteboards, or even with actual languages, forcing yourself to write complete programs/features before turning to the repl instead of a piecemeal write then verify approach.
If so many well paid people at big companies can't do it, maybe that's an indicator that it's absolutely not a good screen at all, that there are far better screens that can be used to weigh developer worth, and you're just so far down the rabbit hole that you can't see what's clearly obvious: once you get past the arbitrary tech hoops most developers only need about 30% of their entire skillset to be programming skill to be of great value to a business.
No one screens for understanding complex business domains, breaking risky big scope tasks down into iterative low risk steps, leading meetings / conversations where you have to rethink complex tech requirements into non-technical speak.
> No one screens for understanding complex business domains, breaking risky big scope tasks down into iterative low risk steps, leading meetings / conversations where you have to rethink complex tech requirements into non-technical speak.
Some of these are or can be included in the system design interview.
For the rest, is there an objective way to ask the same question of each candidate that won't eventually be gamed with pre-canned answers on leetcode?
Agreed, but you can still find fairly simple questions related to the domain they should know to weed out a lot of people. For applications that will use a lot of SQL back end, I will ask the person to describe what a Left Outer Join does (what will it produce). That question lets me know if you have done any SQL beyond a basic query or basic inner join.
If so many well paid people at big companies can't do it, maybe that's an indicator that it's absolutely not a good screen at al
The history of FizzBuzz was that it was a screening question for webdevs to work on a bugtracking tool. Maybe it is relevant for that, I don’t know. But like most of the rest of its inventor’s advice, it is not as generally applicable as he claims.
I agree, but the test is also dreadfully easy. Literally it's hard to see why anyone would fail.
The more interesting question is why did they fail? Why is this a bad barometer or what is making this a bad barometer despite it being so easy?
If you took a career software engineer that would otherwise fail a fizzbuzz interview and put him alone in a room with a computer for an unlimited amount of available time and made it known that he's just solving a fizzbuzz question for fun and not being judged for a future career... I'm willing to bet that he will could walk out of that room in reasonable time with a working fizzbuzz.
If you did this for 100 individuals with the exact same credentials as the person above I'm pretty sure you could get 99 people who walk out of that room with a working fizz buzz in reasonable time.
Not knowing about a rarely used operator isn't that big of a deal, but the "hard" part of fizzBuzz is trivial in the couple of languages I am proficient in.
"I’ve been working since the 90s and I never attempted to do FizzBuzz. Is it really relevant?"
So, when stating "can't do FizzBuzz in interview" I think there are two meanings: (1) Candidate attempts to do it, writes some code in language X with some (many) syntax errors and some logic errors and (2) Cannot do anything at all, i.e. candidate there's no response and the onscreen cursor does not move (usually this is a phone interview). My experience with candidates I've seen is that the ratio of (1) to (2) is about equal!
Depending on the number and the of errors, (1) could be worrisome but the issue that people generally bring up in discussions on FizzBuzz is the utter incredulity of (2).
I'm mechanically challenged and have never changed a tire, yet , if asked to do so, will make some movements that are roughly aligned with the goal, albeit may be laughable to more knowledgeable people. Ditto for cooking a simple dish, e.g. spaghetti. I think this residual knowledge is acquired by osmosis through being around people (or watching TV) doing the task.
So, the most unnerving aspect of (2) to me is that it shows that the candidate does not even has this residual knowledge about programming.
I think "roughly aligned with the goals" is ok - from having worked with some people trying to start out in software development the biggest hurdles are in trying to apply the knowledge to the problem at hand.
That some people really struggle with properly defining the problem and what needs done in such a way that it's tractable.
As a counterpoint, your real-world equivalent example is kind of bad. A normal person who had never changed a tire and got a flat would, as step #1, Google or YouTube "how to change a tire" and follow the steps. Or perhaps look in the owner's manual. Randomly rummaging around in your trunk and trying to puzzle out how to use a bottle jack and get the lug nuts off/on correctly is a poor way to go about it. Similarly, in real-world programming if you get to a requirement to do something you've never seen before, the first step most programmers I've worked with would take is looking up potential solutions that already exist.
The problem, of course, is that if you're in the middle of an interview and someone throws a programming problem at you, your first instinct to go look up potential solutions would generally lose you the job opportunity. A better test of real-world skill needed would be to give them some variant of fizzbuzz code then ask them what it does, or put a bug in it and ask them to find the bug and fix it based on the expected output of the function.
>> if asked to do so, will make some movements that are roughly aligned with the goal, albeit may be laughable to more knowledgeable people
Yeah, and the sad thing is that you will probably end up trying to raise your car against one of the non-structural frames which will subsequently tear off a panel or two.
What you are measuring here is the skill of speculating.
I think fizzbuzz-level logic is so simple it's not really abstracted away when programming. No matter how many nice libraries you have you can't avoid writing loops and if checks.
Perhaps, but it seems like a lot of modern programming consists of plugging together frameworks, filling out configs, and so on. Even the traditional for loops and conditionals are abstracted away with streams and filters, hiding the simple counting math involved.
I would want to filter out candidates who can only plug frameworks together: all frameworks have their limitations and I would want someone who can work around these.
A lot of devs are surprised you are asking then questions. I've had architects shake and not even write a for loop on an amature level whiteboard question. It's not a computer I think is the issue. It's also sloppy and they didn't get a job.
This also fails to point out the surprising number of developers who know their algorithms, know every "coding question" for whiteboard interviews, can copy and paste a ton of code off of StackOverflow to create a quick mockup but also still don't know how to code.
I've known some very talented developers who could never pass a standard software engineering interview but if you give them a week to create a project they'll have something to you that works.
I've also known some very talented interviewers who have never completed a project from start to finish.
I think we just need to all agree that interviewing is hard for Software Engineering and no one has a good solution for it yet. I am constantly on the lookout for someone who finds something that is both effective and doesn't waste a ton of time for both the interviewer and interviewee.
Finishing something is somewhat of a separate skill, I think. Like it’s some sort of mental skill to build and hone over time. Perhaps not too deep of a skill compared to others, but being able to create or identify and then execute an end point isn’t the same as coding or any other creative skill.
> I've known some very talented developers who could never pass a standard software engineering interview but if you give them a week to create a project they'll have something to you that works.
> I've also known some very talented interviewers who have never completed a project from start to finish.
Yea, I'm definitely in the first group. From a career progression and remuneration standpoint, it would be much better to be in the latter. I sometimes wish I could trade in my "gets stuff done, right" skill set for "can invert a binary tree on a whiteboard in 2.5 seconds." Sometimes.
1. I ask about prior experience, following up on any interesting resume items or comments. I try to act like a "biographer" (per the book "Who") and just learn their story.
2. I ask them to describe data flow in a basic web app. If I push this UI submit button, explain the progression of data from the client to the database.
3. I ask for an explanation of core concepts of the framework I'm interviewing for or any one they've used.
4. I ask about version control concepts and some specific git commands.
5. I ask about prior team practices, e.g. what types of meetings they have and what the interviewee thinks of their effectiveness.
6. I ask about their knowledge of ops/DevOps, e.g. explain how a pipeline works.
7. I ask about basic CS/object orientation/language concepts, e.g. static vs. dynamic typing.
8. I ask what their most interesting project or story was and why it resonated with them.
9. I ask what their toughest debug was and how they solved it.
10. I ask about their experience with testing and opinions on how best to do it.
Between all that you get a pretty decent picture of what level they're at and what is their capacity to learn.
This is a very good list. I especially like asking number 8. If they can't talk about something they were passionate about, then that's a red flag.
I also ask people to implement the Blum Mental Hash, which I heard about on NPR in 2014. It's easy enough to explain in five minutes or so, but difficult enough to write out in a half hour or so.
This is good, no doubt, but judging programming ability based on how they answer these questions is severely prone to fail because 1) this relies heavily on the interviewer's skills and 2) its so easy to game this system.
I've had so many co-workers talk, passionately, about stuff they don't have the faintest scent about. It's shocking.
Unless you actually oversee a candidate work and reason through a representative problem, implement it and articulate it, there's no good way to gauge competence.
I actually agree with that and think that's something I need to mix in. But I will say it's hard to bullshit your way through every one of those questions. I've had people BS through 3-4 but pretty much inevitably they fell apart on the others.
My problem with this style of interview, is that someone like me, who is a mediocre programmer, but stellar communicator will fare MUCH better than someone who is a brilliant programmer but poor communicator.
I spend lots of time reading about smart people's opinions on programming, and will be able to recite that knowledge and play it off as my own hard-earned experience. I could talk for an hour about tradeoffs between Vagrant and Docker, without ever having spent more than a few hours actually working with Docker.
If the interviewer is really sharp they could maybe dig deep enough until they see that there's nothing beneath the surface, but I suspect most wouldn't do so even if they were capable.
It depends on what you need. If I need a Docker expert, you can be sure I'll tailor my interview to a Docker deep dive with very precise and detailed questions about commands, concepts, etc. The first step in any interview process should be to think very clearly about what you need and to then adjust any template you have to those needs.
Yeah, I was mostly thinking in the context of a junior role. Generally bullshitting of any kind will be caught out. My point is not that someone could bullshit their way through an interview of this style. It's rather that I think it unfairly favours people with a lot of general and high-level knowledge, over someone with strong fundamentals.
But the author is talking about FizzBuzz. It's just a loop with an if/elseif/else statement. Both types of developers you reference should pass it handily.
Here's a good solution - review the Github (or similar) of the people you are thinking to hire.
They may have the simplest of projects or contributions out there but you may infer how they think, how they behave, and what drives them.
If I don't have things to show for it, then I'm not really interested into programming. The immediate knowledge is secondary, the self-motivation is primary, because motivation makes you gain knowledge quickly, or, at all, in fact.
I don't maintain a GitHub at all, yet I spend plenty of time digging through FOSS code at all levels. I generally don't contribute because any type of fix I'm doing is typically just a one-off for my own purposes, which may clash with the intent of the overall project.
I despise signalling for signalling sake. I just enjoy debugging, learning how things work, and doing the smallest tweak possible to fulfill my needs.
I minimize my digital footprint intentionally; people have a habit of trying to get to know you without engaging with you directly when you're too open, and I hate that.
I throw away and redo things in different ways on a regular basis. I change my working OS, workspace structure, buildtools, programming languages, etc. Keeps beginner's mind firmly in place, and helps keep me humble.
Point being, your vetting process completely fails to take into account someone that simply doesn't put themself out for everyone else's perusal, and who actually values their privacy.
Your method ironically would turn me off of most candidates. The Art of Software Engineering for me is to take what you have, look at the hole that needs to be filled, then coding a piece that looks like it belonged there the entire time. It's about building what you want with what you have.
I can admire idiosyncratic code that works in clever ways. Just as I can run screaming when it comes time to refactor it.
Point being, sometimes people's value add isn't conducive to being posted on GitHub, or isn't for personal reasons.
Yeah, that’s a terrible idea. I’m good at programming and like doing it, but not enough that I’ll put in appreciable time outside of work because I have _other hobbies_, as incomprehensible as that sounds. I put a lot of time into them, and between them and having a social life, there’s no time for programming.. but that certainly doesn’t make me a worse programmer or less motivated when it comes to my work.
I just interviewed a bunch of folks for a Haskell position at my startup. We started with a video call, then I sent them a real world take home assignment. It was a list of requirements to solve a problem in our actual domain, slightly vague, with a simplified set of functions they’d need as a library to get it done. It wasn’t technical, just a general problem.
It was surprisingly easy to see who had both practical problem solving skills and technical ability. I could see how they modeled the data and the functions.
The best candidates emailed me to ask for clarification about the requirements. I was able to see how effective they were at communicating.
Some of the candidates said they loved the assignment. I think we need things that are closer to real work to gauge how good people will be at real work
Did you make it clear that they were encourage to email / communicate if they had any questions? Because I could definitely see myself not emailing back unless that was specified
In the medical profession, doctors go through a formal, multi-day certification process. Interviewing a doctor is mostly about mutual interest in the workplace; because no one in the interview needs to prove competence.
In contrast, in our profession, certifications tend to be useless. (Certifications tend to be technology-focused, instead of broader skillsets needed to be a software engineer.)
It's like we, as an industry, need to come up with a robust certification process that determines competence.
Man this so hard. I would pay $1000+ per x years to go to a 3 day certification event where I have to create software and have that software be judged and certified competent. With the assumption that companies would pay the same very board $5000 for my results and I could skip the lame, poor signal programming portion of interviews.
Since we all spend more time writing code than reading, my current tech screen is a small program in the tech for the role we're interviewing for that has a mix of obvious and subtle bugs, some poor data modeling, etc. First step is to get it working to spec, then refactor. I find it very engaging for interviewer and interviewee, is hard to game and gives me a sense of what the person will be like to work with.
In my personal experience, this came down to hanging up there with all the algorithm and data structure knowledge but no idea of what implementation in real life look like. The majority of people that suffer from this is identified by the OS they use --- just like leetcode isn't 100% accurate, which OS you use should have no impact on the ability of people to program. But the gaps are significant and I've found that people who use Windows to (usually) be very behind on actual implementation of software (of course there are good programmer who use windows, but they're the exception in my anecdotal experience).
Reading this article and these comments made my imposter syndrome just fade away! I can't imagine how a student could make it through a CS program and not be able to fizzbuzz.
While I agree there are some people who just can't program, I think it's worth pointing out that in many cases, the candidate who simply cannot FizzBuzz in one interview, will do so (or other similar tests) perfectly well after a few interviews. Have you even blanked out on something you knew the day before the test? Most people have. Some (not all) of these interview bombs, are by people who know perfectly well how to program, but can't do it in an interview (until they've done a few interviews and get over that).
I honestly don’t understand the backlash for the Software Engineering interview process. I hardly program in my current role but I still make an effort to stay fresh. Spend some time on Leetcode weekly doing practice problems and you’ll be fine, it’s not hard.
Really? So monkey see monkey do? Leetcode doesn't represent much of anything to do with 99.9% of software development jobs. Mostly we're not solving puzzles, we're talking with stakeholders, designing systems, working with co-workers, architecting solution and building systems with code. Leetcode is an absolutely terrible way to evaluate any of that.
Leetcode covers data structures and patterns for efficiently using data structures. Most of the ‘puzzles’ could easily be isomorphisms for real life problems programmers encounter. I don’t think it’s a waste of time and it will make you a better programmer.
The responsibilities you bring up are valid but meaningless if core concepts are neglected or misunderstood.
I feel like I'm the exact opposite. I'm much better at deriving algorithms and CS concepts on the spot than memorizing the latest flavor of the month webtool or language. Why am I working as a software QA if there are so many developers that can't do this type of critical thinking? Perhaps I will just start applying for stuff.
Those people who couldn't program their way out of a paper bag in the first interview probably went on to solve whatever issue it is they were having that day (nerves, not ever having heard of modulo etc) and subsequently get more practiced by at least the 3rd interview. All of a sudden they can magically program.
I just don't buy the premise that these people can't program, get rejected from every interview, give up and drop out of industry.
I'd say the vast majority of them get jobs. And you're hiring filter can't calibrate for how the previous interviews have set the current candidate up for your interview.
If you could be a fly on the wall for every interview the candidate you just hired had done, there would likely be some in which you would have assessed "this person isn't capable of doing the job".
Since interviewing is a skill and interview skill is used as a proxy for job skill and interview skill is a function of recent interview experience, job experience, and your mix of personality traits, and only two of those are roughly stable. Job experience is a slowly changing dimension, but recent interview experience changes very rapidly and it has a huge effect on interview skill, and the interviewer has no way to calibrate for it. Instead they always try to calibrate for job experience. Interviewers also don't have any hope of calibrating for your mix of personality traits.
The whole thing is basically a crapshoot. But I take comfort in that. I don't ever feel bad if I get rejected. I just see the process as essentially random.
This is why I don’t bother with fizzbuzz. The people who can’t solve fizzbuzz are the same people who learned about fizzbuzz and took their time to memorize a solution.
I ask questions that are original (not hard, they don’t need to be hard, just something that they won’t find when they google “how to pass a programming interview”)
I've seen the tech tests we receive from potential candidates and they are for the most part appaling. Our technical test is incredibly simple as well and they can do it at home in their own time.
Imagine something as simple as write a console app where you have a class that represents an Account. Write a function to debit and credit an amount that value and have a property to return the balance and a property to show if the value is negative.
The amount of code we see that looks something like:
public class Account
{
public decimal Balance { get; set; }
public bool IsNegative { get; set; }
public void Debit(decimal amount)
{
Balance = Balance - amount;
if(Balance < 0)
IsNegative = true;
}
public void Credit(decimal amount)
{
Balance = Balance + amount;
if(Balance >= 0)
IsNegative = false;
}
}
In fact we've seen that almost line for line more than once and they get an hour to do it. Worse, we've seen stuff that can't even compile!
I've wanted something harder for a while as a filter and we changed the test to write a very basic WEB API. The tests you get back are equally hopeless.
When you finally get a test that looks somewhat acceptable and they get an interview, they invariably are awful in the interview if you ask them anything other than the most basic of questions.
We are still looking. Getting someone you can give a problem to and they can't be left alone for a reasonable period of time, with minimum of hand holding, and they will come back with a working, implemented solution is so hard.
If these programmers that can't program drop out of the industry, then great. Maybe we will eventually raise the bar for what it means to be a programmer that we will get some decent software.
OK... so you're complaining that the coder could use the api to violate an invariant.
I've worked with millions of lines of code and this is certainly not a criterion I'd use to evaluate a serious programmer. Many codes I work with permit this sort of behavior (I guarantee you can mess up using the C library this way).
I'd like you to articulate why you don't like the code fragment you provided. Does it have a bug (didn't see one on simple inspection)? Is it because the isNegative could be computed at runtime rather than using a boolean flag set when the balance at runtime?
I’m not quite sure I followed your post, but if I did, you’re still looking because you’re being obnoxious. If you asked somebody to write a class that represents an account with a balance/negative getter _in a job interview setting_, the code you posted looks fairly reasonable (assuming it’s written in a programming language that that compiles in - it’s obviously not Java, C# maybe?). I wouldn’t make “isNegative” a property; I’d replace it with “public bool isNegative { return balance < 0; }”, but otherwise, without any further instruction, again in an artificial job interview setting, without you clarifying what you’re looking for, there’s nothing wrong with this. Or are you pushing back on the “write a command line app” part when there’s no CLI attached? Because if you actually wanted one, you need to provide a lot more context than “write a command line app” (should I be tracking multiple accounts? Should there be a command to create a new one, or is there just one with a starting balance for demo purposes?).
If you're weeding out candidates, then the test is working, no matter how simple you think it is.
The correct question is how many applicants are remaining that did this problem successfully? How many from that pool are companies hiring? I wonder what the actual numbers and percentages is.
I ask this because, while the program is straightforward, different languages have different division functions, and you want to make sure you have the one with a remainder.
You also want to get the OR and AND operator right. (Is it "or", "|", "||"?)
Now, I've used all these many times, but in an interview, you may just forget for whatever reason. I don't think I would, but I imagine someone competent could.
I think articles like this are harmful to new developers. Hearing people make proclamations like these, saying everyone sucks while also not mentioning what it means to be good, is only going to make people anxious and second guess themselves. As someone who became a developer after studying a non-cs topic in college, I always worry about what skills I might be lacking compared to my peers, and this shit just isn't helpful.
I always thought “fizzbuzz” was sort of an obnoxious “gotcha” sort of test - it’s actually a test of whether or not you're familiar with the “%” operator. I wouldn’t have a problem with it myself, but I can easily imagine spending an awfully long time coding without ever coming across a modulus operation, especially if you didn’t have a CS/math type background. OTOH, I posted on here a few weeks back that I had a co-worker who expected candidates to come up with the binary search algorithm in an interview setting, which I thought was unreasonable, and most of the commenters thought I wasn’t being harsh enough… maybe I have low standards?
However, we can talk about overuse of the “singleton pattern” abomination…
182 comments
[ 2.9 ms ] story [ 204 ms ] threadAnecdotally, i recently became semi_obsessed with operating systems and OS development.I tried to pick up C wanting to do some kernel development on NetBSD and thought it would be easy, given the familiar syntax, u just needed to learn pointer logic/ arithmetic. I was finally defeated after trying to write a program with multidimensional arrays and working with them decayed down to pointers. At the same time, though, I need a new job asap, so I've given up on the interesting stuff and am back to learning stuff for employability reasons only
Then you are a programmer.
Please don't. Do enough interview situations at companies you don't care much about to numb you down (I did); this helps with nervousness. And sometimes you find out that you don't actually mind working there, and end up being hired (I did).
I don't think fizzbuzz == leetcode? I thought fizzbuzz was like super basic can you write a for loop type question.
https://blog.codinghorror.com/why-cant-programmers-program/
I think it's pretty common for people to not be able to do leetcode. I learned the concepts in college and usually did very well in class. I didn't even bother preparing for interviews and could still pass.
However, after working for a while I don't think I'd be able to do them anymore, or at least not at the speed which is expected.
I highly recommend Georgia Tech's online master's program. It's ranked in the top 10 of all CS programs worldwide. The total cost of the program is under $10,000, and you can take a class part time while you're working full time. I'm halfway through the program myself, and it's definitely helped me keep my skills relevant especially since certain technologies didn't exist when I got my Bachelor's in 2008.
But when I was a kid / teen, it feels like I could learn anything. I could remember how to write in multiple programming languages, a bit of their std lib stuff etc. Now if I'm not working with it at the moment, it leaves my brain. For example I worked on some Node.js a few years ago. Nowadays, I probably couldn't write it to save my life.
https://sivers.org/srs
You'd have a huge advantage over the typical student and could probably easily get over any problems with pointers by taking the course.
This is so true. IME, less than 50% of applicants can even get close. Mostly due to not remembering or even knowing about the modulo operator or a suitable workaround.
"Write a function which counts the number of a's in the input string."
"We will give you an array of words. Print out each word which appears more than 3 times in the array."
"We will give you two arrays of words. Print out each word which is in exactly one of the arrays."
It's not just the mod operator. These are toy problems for difficulty but they're not "implement the rules to a children's game"; with a few seconds of effort you can describe a boringly plausible business reason for having to implement them during a fairly pedestrian career.
The goal of fizzbuzz in a phone screen should not be to see if someone can solve it in an optimal memory-efficient framework-idiomatic way. Clever syntax and data structure use is lovely, but these are really about finding whether someone can use a 'for' loop and an 'if' condition.
You are being tested on finding a solution that works, not on what function you use.
I had to learn C at some point though, and that used to be common. I suppose it's becoming a less useful test.
Even if you (somehow) don't know about it, figure something out? Do something "stupid that works" like this:
(I'm guessing this works, or maybe I fall into that category as well ;))If the test is interactive, the candidate can express, "I need to find out if this number is evenly divisible by that number; if so, then blah blah". Interviewer can remind them that x % 2 is "remainder of x when it is divided by 2". The point should not be whether someone can remember %, but whether they have any idea what minor goal they are trying to achieve.
I've had the same experience asking applicants to reverse a string in a language of their choice. sometimes they'll give me a simple answer like "''.join(reversed(my_str))" (python), which i'll accept and move on to the next (harder) question, but even if you don't remember that syntax, you should be easily able to build a function using a for loop. I find that 50% of applicants can't and it saves me a lot of time finding this out early in the interview process.
Explicit is better than implicit.
Readability counts.
This is first year-out-o-school, junior gate-keeping bullshit. We need better methods to evaluate intermediate and senior devs, and FizzBuzz ain't it
Think solutions.
Maybe that's the reason I've almost never done interview questions in java. I always use python/javascript, because I write those with VIM, even though, until recently I did only a small percentage of my professional programming with those languages.
With quotes like:
> So, as someone who spends maybe 20% of their time hiring, it’s still a very effective screen. You wouldn’t believe how many people can’t do it. People at big companies, respected places. It’s surprising.
Shouldn’t people start questioning the validity of their method?
[1] I know us developers like to spend an enormous amount of time making things super complicated with fad tech, but we know a lot of it is not required.
If you provide them a good sample, the function names and behaviors should give a really good sense of direction to the candidate, and the harder questions would be answered by the details of the code.
Once we'd actually started using it, though, we found it filtered between 20-30% of our applicant pool, even when we let them use literally any language they desired, presumably their strongest.
However, it usually only filtered fresh grads (CS students from top-10 schools). Those with previous work experience almost never had a problem.
I suspect that candidates who are otherwise fine (and not misrepresenting themselves on their CV's), fail fizzbuzz because they overthink the problem, stumble on the not-so-frequently-used modulo operator and then paint themselves into a corner where they can't just loosen up, take a breath and figure out the solution.
You should be able to have a 10 minute conversation with someone and know if they can solve fizzbuzz (without even posing the problem).
The fact is companies hire people all the time, without using fizzbuzz, probably hiring some number of people that would not have passed fizzbuzz if it were given to them. Were all those people definitely bad hires? I think not. The parent commenter's company had "survived" without it, and many do now.
It's understandable to want to have the ultimate "gotcha" interview question, the response to which screens out a candidate. It's not totally wrong, but there's a lot more to an interview. I think the onus should be on the hiring managers to develop their behavioral interviewing skills so that they're able to evaluate a candidate more fully than by using toy problem quizzes.
I've had the same, I was a contractor and not usually involved in the hiring process but I'd been asked for a question they could take to a candidate.
One of the team at the time was a young Maths grad, super bright but prone to being over confident. So I wrote a clear FizzBuzz question, passed him the pen and paper and asked him if he was sure when he was done. There was some minor issue, a boundary issue one think and he was livid with himself. So they took it to the candidate and apparently it was a bit of a disaster.
Personally, the first time I came across it was in an interview and I quite enjoyed it - simple enough to not be threatening but I guess sufficiently able to show I could write code as they offered me the role. They asked some extra questions too with some extensions and about how you could unit test it.
Beats having to implement red-black trees by remembering the crib sheet you read the day before.
Think about it, it takes way more work, way more intelligence to get into and graduate from a top 10 school then it does to learn how to pass a fizzbuzz test.
I can 100% tell you that ALL CS grads from top 10 schools can pass fizz buzz given a day to do it. That being said I can also say literally most of your coworkers who are administering the fizz buzz test will not be able to ever attend a top 10 school given a lifetime to prepare.
It is incredulous to me that people can literally dismiss an MIT candidate because he didn't pass a fizzbuzz test. Do you not realize that it is 100x easier to learn programming then it is to get into MIT?
People need to get it through their heads. Programming is actually really, really easy. That's why there's so many people who can learn how to do it without going to college. But instead I see most people thinking that they are so intelligent they didn't need to go to college because they can just learn programming.... That may be partially true, but most of what I see is actually just people learning programming because they COULDN'T get into university.
But it still begs the question... what is making an MIT student fail a fizzbuzz test? It's like failing to recite a paragraph out loud with zero stuttering to an audience who is judging your future career. How could one possibly be so stupid and not stutter? If you stutter it must mean you can't speak english, just like how if you fail a fizzbuzz test is must mean you can't program.
To be honest I don't know why so many programmers fail. But I'm honestly pretty sure fizzbuzz is so dreadfully easy that there is some other factor that is influencing this high failure rate.
Because many people are not capable of programming.
More importantly, the school you go to has nothing to do with your capability of a programmer. I worked with quite a few people in my CS department who couldn't program their way out of a paper bag. Most were still very bright people who I assume figured out successful careers.
I suspect a lot of the recent CS grads who can't do fizzbuzz end up following careers that don't require programming.
It's also important to understand that Computer Science is not Software Engineering. Computer Science is fundamentally a mathematical field. Don't conflate the two.
You think too highly of the field. Programming is easy. Everyone, and I mean everyone can do it and eventually become good at it, especially fizz buzz.
>I suspect a lot of the recent CS grads who can't do fizzbuzz end up following careers that don't require programming.
Nah, more than likely they learn the fizzbuzz question and still become programmers because programming is easy. It takes time to learn programming like it takes time to become good at basic algebra or calculus, but literally anyone can do it.
>It's also important to understand that Computer Science is not Software Engineering. Computer Science is fundamentally a mathematical field. Don't conflate the two.
The two fields are intricately related. Most junior devs who lack the academic rigor like to separate the fields into a dichotomy and use this dichotomy as an excuse to justify the lack of expertise on the academic side.
After a certain amount of time you'll realize that all of programming is rehashing the same concepts over and over again just in a new framework/language. To gain deeper insight into the nature of computer programming and engineering and to actually become better, the dichotomy must be eliminated. In the upper echelons of Software engineering, people will realize that computer science and software engineering merge to become the same thing. Juniors have yet to realize this.
Take this for example. Did you know that a unit test does not guarantee correctness of a function? To guarantee correctness of a function you'd have to write a unit test for every possible input of a function. Did you know that computer science offers a way to do prove your program 100% correct without writing a single unit test? This is an example of a merger of engineering and theory. A computer is a deterministic machine amenable to proof yet we choose to treat it like a black box and test it as it was a chaotic system that needs to be tamed. There are advantages and disadvantages to both methodologies but I illustrate this here to show you that SE and CS are in fact different aspects of the same thing.
Look at things like theoretical computer science and category theory. The word "class" comes right out of basic category theory. (You don't need any category theory to program a computer, but it directly influenced object oriented programming.)
And, if you think programming is easy, consider yourself lucky. Take the time to learn some soft skills. Maybe you'll understand your downvotes.
lol, I'm not here to win votes. This is the internet. This comment alone shows a lack of soft skills on your side. Except for when the person I'm communicating with chooses to get personal I never get personal when I talk about things on the internet and I never hold back either, that's part of the appeal of being here. I can tell what I believe to be the truth without concern for your feelings. Despite the lack of concern for your feelings I do make deliberate effort to not attack YOU directly. I am aware that the things I say may piss people off but in all I'm just here to talk about the topic at hand without worrying about real world stuff like your feelings.
>Look at things like theoretical computer science and category theory. The word "class" comes right out of basic category theory. (You don't need any category theory to program a computer, but it directly influenced object oriented programming.)
OOP was invented before anyone knew that category theory had anything to do with computer science. Class most likely comes from set theory. Also if you work with category theory or languages that implement the theory you'd know that the morphism is central to the theory not the object. In other words it has much more to do with Functional programming then it does with OOP. OOP has virtually no theoretical basis and it fits into category theory in a very awkward way.
>Computer Science has very little to do with unit testing.
It does. I'm literally talking about how it does have to do with theory.
In computer science there are two ways to verify 100% correctness of a function. You either prove it correct given an initial condition and a final condition. Or you unit test every possible input with the associated output. Software Engineering chooses to go with neither approach. Software engineering chooses to go with a tiny subset of all possible unit tests and hopes that the correctness of that subset of tests correlates with the correctness of the entire domain. This is a more applied math (aka statistical) approach to verification that increases confidence but does not verify the program to be correct. (This is also debatable how much statistical rigor unit tests have as its a usually done with a very ad-hoc approach... unit tests are usually too few in number and highly biased).
All of this is part of Computer Science. You will note that the paragraph above uses the word "unit testing" Software Engineering is simply application of said theory or application of no theory but they can be one in the same.
>And, if you think programming is easy, consider yourself lucky.
I hear parents talking all the time about trying to teach their kids programming. Internet tutorials are all over the place. It's easy in the sense that mostly everyone can learn it. It's not easy in the sense that it does require a lot of effort.
What's hard is quantum physics. You ever hear of an internet tutorial that will teach you all of quantum physics? An udemy course that will cover all you need to know? Ever hear parents trying to teach their kid about quantum physics? Quantum physics is hard, programming is not.
> Programming is actually really, really easy.
Perhaps. Software engineering is hard, though, and it is not the same as CS. We turn out these CS degrees, and then we expect that they can do software engineering.
That said, fizz buzz may not be the best way to tell if people can do software engineering, either...
Have unit testing, have integration testing... make it modular... SOLID, write layers, yada yada yada also very easy.
I always hear people say that Computer science != software engineering but really it's the same thing at the upper echelons. Rather than using your gut and all these anecdotal "principles" spewed out by people like Martin Fowler, design pattern books, or books on testing and agile you can actually use theory and science to guide your software engineering decisions.
Let's put it this way. Software engineering is the only engineering discipline where people can get away with not knowing science and mathematics and still build systems that can run. The effective and elite software engineer lets theory and science guide his decisions as well to make systems that are better.
I do agree with you that fizzbuzz is missing something.
In case you're serious, though, you clearly have no clue what software engineering is. Yes, it includes some of the things you mention. No, it's not the same thing as CS at the upper echelons. Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.
BTW, because I don't know how to contact you to tell you this: Your HN profile says "Actively searching for opportunities. email me if interested", but doesn't actually provide an email address.
I'm totally serious. Not trolling at all.
>In case you're serious, though, you clearly have no clue what software engineering is.
The term is so hand wavy. You can read this: https://www.wikiwand.com/en/Software_engineering
Just go to the "Subdisciplines" section in the wiki
Literally every example I mentioned is covered by a "subdiscipline" of software engineering. I'll quote the part that covers my examples:
"Software design:[1][23] The process of defining the architecture, components, interfaces, and other characteristics of a system or component. It is also defined as the result of that process. Software construction:[1][23] The detailed creation of working, meaningful software through a combination of programming (aka coding), verification, unit testing, integration testing, and debugging. Software testing:[1][23] An empirical, technical investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software maintenance:[1][23] The totality of activities required to provide cost-effective support to software."
What happened here is that I never had a strict definition of software engineering in my head. I do know that a big aspect of it usually has little to do with the theoretical side of things, so in my example I just mentioned all the "technical" terminology people throw around that has little basis in rigor or theory. Then when you said I have no idea what it is, I looked it up, and the definition literally covers almost everything that has to do with software including my examples.
There is literally zero chance you could have known that I have "have no clue what software engineering is" because my examples are covered by the definition stated in the wiki. That is zero chance unless you have no clue yourself.
A more accurate explanation is this: "software engineering" is a vague hand-wavy term. Sort of like how "Science" doesn't always involve the "Scientific method." You have some super clear definition of the term in your head, but clearly from this wiki not everybody thinks about it that way.
>Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.
When did I say only CS theory is enough? Many aspects of software and the real world don't have any science or theory to describe it. Usually when you encounter such an aspect of the real world the vernacular changes from "deriving" a solution to "designing" one. My emphasis is that many engineers are "designing" things that are ultimately covered by theory and ultimately can be "derived," they simply turn to "design" either because they are unaware of theory or the theory is too hard.
We are in agreement on the point you mentioned, but I never said all you need is theory. Humanities theories about the universe are prove-ably incomplete and unprovable in general, therefore we have no choice but to exit the theoretical world for many engineering problems.
>No, it's not the same thing as CS at the upper echelons.
By upper echelons I mean you've basically learned most of it, the only thing left is the theoretical part. The theoretical part is harder and usually something a software engineer gets into once he's figured out how the rest of the non-theoretical parts work. You'll note that "mathematics" encompasses "software engineering" as defined in the wiki. I'm also not sure why you disagree with me nor am I clear about your own definition of software engineering, so please explain if you can.
>BTW, because I don't know how to contact you to tell y...
I find it hard to believe that anyone who has spent more than a week programming couldn't solve FizzBuzz. Even if they somehow weren't familiar with the modulo operator, you could just explain how it worked.
FizzBuzz is a way of easily filtering con artists.
An interview is almost like public speaking combined with an intense time based coding competition without allowing you to use an IDE.
I think a good number of these guys are lying. I agree with you. But I also think a good number are honest and actually failing.
It's so well known that everyone uses it to study for their interview. You'll end up hiring someone who just memorized the solution.
Instead, come up with your own unique programming challenge that the candidate hasn't seen before. It should be about as easy / hard as Fizzbuzz.
Related: I once interviewed a candidate who came across as knowing my questions ahead of time, and delivering a well-reheased answer. I made up a question on the spot, and got a "this wasn't supposed to be on the test" tone of voice in the answer. I rejected the candidate.
Technical interviews aren't things that the candidate should memorize and rehearse. That's why I'd never ask Fizzbuzz.
If one is concerned about people memorizing answer, it is pretty simple to change the question a bit to make it non-recognizeable,
I had to program for eng 101, engineering 280 mechatronics, and our senior design.
I'm not a programmer by degree, but I was often the only one in group projects that understood what needed to get done.
I don't know what I missed out on. I've wrote AI since college and created embedded systems.
Programming feels unlimited.
But what don't I know? Security? Faster algorithms? I don't know what I don't know.
1.upto(100) do |i|
endI feel ashamed.
I think a huge crutch for a lot of people is the immediate feedback loop execution gives you. Rather than truly understand the api we’re using, I think there’s sometimes a tendency for programmers to just skim, try a function call, and see what the repl/executable or w/e does, and to roll with that. While this works for getting things done it doesn’t really improve your understanding. I think practicing programming without the feedback loops the computer provides, e.g. based on documentation and reasoning alone, is a great way to become better and more disciplined. You can do this with pseudocode, whiteboards, or even with actual languages, forcing yourself to write complete programs/features before turning to the repl instead of a piecemeal write then verify approach.
No one screens for understanding complex business domains, breaking risky big scope tasks down into iterative low risk steps, leading meetings / conversations where you have to rethink complex tech requirements into non-technical speak.
Some of these are or can be included in the system design interview.
For the rest, is there an objective way to ask the same question of each candidate that won't eventually be gamed with pre-canned answers on leetcode?
The history of FizzBuzz was that it was a screening question for webdevs to work on a bugtracking tool. Maybe it is relevant for that, I don’t know. But like most of the rest of its inventor’s advice, it is not as generally applicable as he claims.
The more interesting question is why did they fail? Why is this a bad barometer or what is making this a bad barometer despite it being so easy?
If you took a career software engineer that would otherwise fail a fizzbuzz interview and put him alone in a room with a computer for an unlimited amount of available time and made it known that he's just solving a fizzbuzz question for fun and not being judged for a future career... I'm willing to bet that he will could walk out of that room in reasonable time with a working fizzbuzz.
If you did this for 100 individuals with the exact same credentials as the person above I'm pretty sure you could get 99 people who walk out of that room with a working fizz buzz in reasonable time.
In JS:
const isEvenlyDivisible = (num, denominator) => Math.floor(num / denominator) === (num / denominator)
So, when stating "can't do FizzBuzz in interview" I think there are two meanings: (1) Candidate attempts to do it, writes some code in language X with some (many) syntax errors and some logic errors and (2) Cannot do anything at all, i.e. candidate there's no response and the onscreen cursor does not move (usually this is a phone interview). My experience with candidates I've seen is that the ratio of (1) to (2) is about equal!
Depending on the number and the of errors, (1) could be worrisome but the issue that people generally bring up in discussions on FizzBuzz is the utter incredulity of (2).
I'm mechanically challenged and have never changed a tire, yet , if asked to do so, will make some movements that are roughly aligned with the goal, albeit may be laughable to more knowledgeable people. Ditto for cooking a simple dish, e.g. spaghetti. I think this residual knowledge is acquired by osmosis through being around people (or watching TV) doing the task.
So, the most unnerving aspect of (2) to me is that it shows that the candidate does not even has this residual knowledge about programming.
That some people really struggle with properly defining the problem and what needs done in such a way that it's tractable.
Highly recommend this video on "The Expert" which illustrates this beautifully - https://www.youtube.com/watch?v=BKorP55Aqvg
The problem, of course, is that if you're in the middle of an interview and someone throws a programming problem at you, your first instinct to go look up potential solutions would generally lose you the job opportunity. A better test of real-world skill needed would be to give them some variant of fizzbuzz code then ask them what it does, or put a bug in it and ask them to find the bug and fix it based on the expected output of the function.
Yeah, and the sad thing is that you will probably end up trying to raise your car against one of the non-structural frames which will subsequently tear off a panel or two.
What you are measuring here is the skill of speculating.
“I’m a mathematician but I never do long division” -> totes believable.
“I’m a programmer but I never use for loops or conditional statements” -> uhhhhh
I've known some very talented developers who could never pass a standard software engineering interview but if you give them a week to create a project they'll have something to you that works.
I've also known some very talented interviewers who have never completed a project from start to finish.
I think we just need to all agree that interviewing is hard for Software Engineering and no one has a good solution for it yet. I am constantly on the lookout for someone who finds something that is both effective and doesn't waste a ton of time for both the interviewer and interviewee.
> I've also known some very talented interviewers who have never completed a project from start to finish.
Yea, I'm definitely in the first group. From a career progression and remuneration standpoint, it would be much better to be in the latter. I sometimes wish I could trade in my "gets stuff done, right" skill set for "can invert a binary tree on a whiteboard in 2.5 seconds." Sometimes.
1. I ask about prior experience, following up on any interesting resume items or comments. I try to act like a "biographer" (per the book "Who") and just learn their story.
2. I ask them to describe data flow in a basic web app. If I push this UI submit button, explain the progression of data from the client to the database.
3. I ask for an explanation of core concepts of the framework I'm interviewing for or any one they've used.
4. I ask about version control concepts and some specific git commands.
5. I ask about prior team practices, e.g. what types of meetings they have and what the interviewee thinks of their effectiveness.
6. I ask about their knowledge of ops/DevOps, e.g. explain how a pipeline works.
7. I ask about basic CS/object orientation/language concepts, e.g. static vs. dynamic typing.
8. I ask what their most interesting project or story was and why it resonated with them.
9. I ask what their toughest debug was and how they solved it.
10. I ask about their experience with testing and opinions on how best to do it.
Between all that you get a pretty decent picture of what level they're at and what is their capacity to learn.
I also ask people to implement the Blum Mental Hash, which I heard about on NPR in 2014. It's easy enough to explain in five minutes or so, but difficult enough to write out in a half hour or so.
https://scilogs.spektrum.de/hlf/mental-cryptography-and-good...
I've had so many co-workers talk, passionately, about stuff they don't have the faintest scent about. It's shocking.
Unless you actually oversee a candidate work and reason through a representative problem, implement it and articulate it, there's no good way to gauge competence.
I spend lots of time reading about smart people's opinions on programming, and will be able to recite that knowledge and play it off as my own hard-earned experience. I could talk for an hour about tradeoffs between Vagrant and Docker, without ever having spent more than a few hours actually working with Docker.
If the interviewer is really sharp they could maybe dig deep enough until they see that there's nothing beneath the surface, but I suspect most wouldn't do so even if they were capable.
They may have the simplest of projects or contributions out there but you may infer how they think, how they behave, and what drives them.
If I don't have things to show for it, then I'm not really interested into programming. The immediate knowledge is secondary, the self-motivation is primary, because motivation makes you gain knowledge quickly, or, at all, in fact.
I despise signalling for signalling sake. I just enjoy debugging, learning how things work, and doing the smallest tweak possible to fulfill my needs.
I minimize my digital footprint intentionally; people have a habit of trying to get to know you without engaging with you directly when you're too open, and I hate that.
I throw away and redo things in different ways on a regular basis. I change my working OS, workspace structure, buildtools, programming languages, etc. Keeps beginner's mind firmly in place, and helps keep me humble.
Point being, your vetting process completely fails to take into account someone that simply doesn't put themself out for everyone else's perusal, and who actually values their privacy.
Your method ironically would turn me off of most candidates. The Art of Software Engineering for me is to take what you have, look at the hole that needs to be filled, then coding a piece that looks like it belonged there the entire time. It's about building what you want with what you have.
I can admire idiosyncratic code that works in clever ways. Just as I can run screaming when it comes time to refactor it.
Point being, sometimes people's value add isn't conducive to being posted on GitHub, or isn't for personal reasons.
It was surprisingly easy to see who had both practical problem solving skills and technical ability. I could see how they modeled the data and the functions.
The best candidates emailed me to ask for clarification about the requirements. I was able to see how effective they were at communicating.
Some of the candidates said they loved the assignment. I think we need things that are closer to real work to gauge how good people will be at real work
In contrast, in our profession, certifications tend to be useless. (Certifications tend to be technology-focused, instead of broader skillsets needed to be a software engineer.)
It's like we, as an industry, need to come up with a robust certification process that determines competence.
I spend quite a bit more time reading code than writing it...
I’ve been a programmer for years! Why can’t you just believe me!?
The responsibilities you bring up are valid but meaningless if core concepts are neglected or misunderstood.
Those people who couldn't program their way out of a paper bag in the first interview probably went on to solve whatever issue it is they were having that day (nerves, not ever having heard of modulo etc) and subsequently get more practiced by at least the 3rd interview. All of a sudden they can magically program.
I just don't buy the premise that these people can't program, get rejected from every interview, give up and drop out of industry.
I'd say the vast majority of them get jobs. And you're hiring filter can't calibrate for how the previous interviews have set the current candidate up for your interview.
If you could be a fly on the wall for every interview the candidate you just hired had done, there would likely be some in which you would have assessed "this person isn't capable of doing the job".
The signal/noise ratio in hiring is abysmal.
Every time I start a new job hunt, I have to fail a few interviews before I get practiced up again.
Since interviewing is a skill and interview skill is used as a proxy for job skill and interview skill is a function of recent interview experience, job experience, and your mix of personality traits, and only two of those are roughly stable. Job experience is a slowly changing dimension, but recent interview experience changes very rapidly and it has a huge effect on interview skill, and the interviewer has no way to calibrate for it. Instead they always try to calibrate for job experience. Interviewers also don't have any hope of calibrating for your mix of personality traits.
The whole thing is basically a crapshoot. But I take comfort in that. I don't ever feel bad if I get rejected. I just see the process as essentially random.
I ask questions that are original (not hard, they don’t need to be hard, just something that they won’t find when they google “how to pass a programming interview”)
I've seen the tech tests we receive from potential candidates and they are for the most part appaling. Our technical test is incredibly simple as well and they can do it at home in their own time.
Imagine something as simple as write a console app where you have a class that represents an Account. Write a function to debit and credit an amount that value and have a property to return the balance and a property to show if the value is negative.
The amount of code we see that looks something like:
In fact we've seen that almost line for line more than once and they get an hour to do it. Worse, we've seen stuff that can't even compile!I've wanted something harder for a while as a filter and we changed the test to write a very basic WEB API. The tests you get back are equally hopeless.
When you finally get a test that looks somewhat acceptable and they get an interview, they invariably are awful in the interview if you ask them anything other than the most basic of questions.
We are still looking. Getting someone you can give a problem to and they can't be left alone for a reasonable period of time, with minimum of hand holding, and they will come back with a working, implemented solution is so hard.
If these programmers that can't program drop out of the industry, then great. Maybe we will eventually raise the bar for what it means to be a programmer that we will get some decent software.
Well first off.
IsNegative and Balance are idependantly mutable.
I could do this:
Or Now Balance is - 100 and IsNegative is false.Or vice versa for both.
I would expect anyone applying for a job that is asking for 5+ years of experience to pick up on something as basic as this.
OK... so you're complaining that the coder could use the api to violate an invariant. I've worked with millions of lines of code and this is certainly not a criterion I'd use to evaluate a serious programmer. Many codes I work with permit this sort of behavior (I guarantee you can mess up using the C library this way).
I’m not quite sure I followed your post, but if I did, you’re still looking because you’re being obnoxious. If you asked somebody to write a class that represents an account with a balance/negative getter _in a job interview setting_, the code you posted looks fairly reasonable (assuming it’s written in a programming language that that compiles in - it’s obviously not Java, C# maybe?). I wouldn’t make “isNegative” a property; I’d replace it with “public bool isNegative { return balance < 0; }”, but otherwise, without any further instruction, again in an artificial job interview setting, without you clarifying what you’re looking for, there’s nothing wrong with this. Or are you pushing back on the “write a command line app” part when there’s no CLI attached? Because if you actually wanted one, you need to provide a lot more context than “write a command line app” (should I be tracking multiple accounts? Should there be a command to create a new one, or is there just one with a starting balance for demo purposes?).
Can I pm you on this?
The correct question is how many applicants are remaining that did this problem successfully? How many from that pool are companies hiring? I wonder what the actual numbers and percentages is.
Is FizzBuzz done with the benefit of Google?
I ask this because, while the program is straightforward, different languages have different division functions, and you want to make sure you have the one with a remainder.
You also want to get the OR and AND operator right. (Is it "or", "|", "||"?)
Now, I've used all these many times, but in an interview, you may just forget for whatever reason. I don't think I would, but I imagine someone competent could.
Like DHH, for instance:
https://twitter.com/dhh/status/834146806594433025
Or curated here:
https://theoutline.com/post/1166/programmers-are-confessing-...
However, we can talk about overuse of the “singleton pattern” abomination…