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.
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.
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.
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.
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.
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
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.
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).
> 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.
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.
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.
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.
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.
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.
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.
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,
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 you this: Your HN profile says "Actively searching for opportunities. email me if interested", but doesn't actually provide an email address.
Thanks. I think at one point I had it up there. I forgot why it was removed. I never got a contact from here anyway.
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.
I've seen this first-hand both in interviewing and on the job. I expect it in interviews, but I never thought I'd see it from a colleague.
I once worked with someone who refused to use loops. He would write everything out... Thousands of copy-pasted lines with incrementing values... He'd often insist that things only deal with certain numbers of inputs for this reason. E.g. he had a bulk data transfer tool that would only transfer 10 items. If you had less than ten, you had to make dummy files. If you had more than 10, you were supposed to use it multiple times. He was also considered "a key technical leader", and constantly lauded by management. He was in his late 20's and had a CS degree from a relatively well-known school. I'm a geologist, so I was constantly told I "just didn't know anything about programming" when I'd ask why. (I suspect he thought it was an optimization, but he never explained.)
This was at a company that's a household name (though not a tech company). I suppose the moral of the story is to be careful about assuming that experience implies a certain level of competence.
> who refused to use loops. He would write everything out... Thousands of copy-pasted lines with incrementing values
You're fucking joking us right? I've seen bad stuff but this is far, far beyond what I consider credible incompetence. You aren't serious?
(Edit: you mention being a geologist. Happens something similar occurred - I was being uber'd by a geologist (he described himself thus) who could talk at length and very knowledgeably about the geopolitics of oil price and reservoir modelling, all fascinating stuff to me. But he mentioned a fossil that he could barely describe beyond being 'like a snail with bits coming off'. I offered that it was an ammonite and he seemed unfamiliar with the word. Also seemed to struggle to know what bauxite was when I raised it. I found those lacunae rather strange).
It's not quite as crazy as it sounds. It was a case of laziness and a belief that he was smarter than the compiler, rather than a lack of knowledge of basic flow control.
For context, the "ten-item-only data transfer tool" was a plugin to a much larger piece of software with a Qt-based gui. He copy-pasted an example from the vendor that used a QLineEdit input widget ten times because he couldn't be bothered to look up how to use a QListWidget or something similar.
The "avoidance of loops" I was referring to was mostly in the inner loops of volumetric image processing routines. A lot of things we worked on were domain-specific operations that are vaguely analogous to a convolution -- there's usually a moving window operation. He'd happily loop over the volume, but insist on writing the inner loop (the actual moving window) as repeated copy-pasted lines.
He was basically doing manual loop unrolling, which could actually make sense in this context. (The codebase was C masquerading as C++.)
However, the compiler was perfectly capable of optimizing a loop for the exact use cases he was working with. There was zero benefit manually unrolling a nested loop for a 5x5x11 or 3x3x7 window (in once case he did it for a 25x25x51 window -- 31k lines of C++... Generated with Perl... Yeah...)
On the geology note, palentology is actually a fairly niche field. I wouldn't assume that every geologist has taken a paleo class. It's usually on the "take 3 of these 5" requirement list in undergrad, and it's not something you take at a graduate level unless that's your specialty. I certainly took a couple paleo/evolutionary biology classes, but it's useful for what I used to do. It wouldn't shock me if someone primarily doing reservoir modeling didn't know what an ammonite was.
Actually any loop unrolling to that extent is counterproductive as it will simply burst the instruction cache, which causes expensive reloads from further down the cache hierarchy, whereas loops can be minimal or even zero overhead. I'd be really curious to know how much performance that cost.
> E.g. he had a bulk data transfer tool that would only transfer 10 items.
I would have pointed out that if you happen edit this tool to transfer 15 items, or any number more, the programming language still obligingly executes all of the larger program, which is because that language implementation contains loops for processing the tokens and statements.
Whats more surprising is the number of programmers who defend this, i.e. claiming that questions like Fizzbuzz filter out good programmers due to interview pressure or whatever. It's a simple loop, folks. Writing code and talking about it is the job, and if you can't do that you can't do the job.
EDIT: Contrary to what some believe, there is no programmer who you simply hand requirements to and then they take those requirements to a dark room, produce programs that fulfill those requirements, and then reappear and hand you the programs, all in silence without looking you in the eye. Programmers need to be able to communicate about the code they're writing to collect requirements, explain problems, etc., and if social anxiety keeps them from doing that, social anxiety keeps them from doing their job.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
>> 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.
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".
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”)
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.
Was a fairly new engineer, when an engineer with a few years of experiencein the office, who was taking classes on the employer's dime towards a masters degree, asked me for assistance.
She was trying to run a C program she'd created, but it wouldn't run. I asked if she'd compiled it. She asked what a compiler was.
How can a person could survive in an office where C was the main language, and be taking courses that assumed familiarity with C, and still not know what a compiler is?
Turned out she was very skilled at taking credit for other people's work.
To be honest such scenario is not so hard to imagine. When I think of my studies, it was probably some introduction to Java, we learned how to use javac during first lesson, but never used it since, because we just clicked button in IDE. Someone who missed the lesson, might never noticed he misses basics.
With advanced build systems in some companies, someone who arrives from scripting language, is shown build system and told to look up the syntax might not ever realize the gap in his knowledge and at the same time might even be productive part of the team.
> 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.
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.
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"?
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.
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.
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 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.
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'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
------------------
def alpha(n):
if(n <= 1):
return n
else:
return(alpha(n-1) + alpha(n-2))
what is alpha(5)?
-----------------
Instead of fizz. They don't have to recognize that it is fib or do it in their head, on paper is fine. No perfect syntax under pressure to worry about. I feel okay with an easy smile, handshake and thank you for your time when I get that confused/embarrassed/angry look like I've just asked them to translate hieroglyphics. Works out nicely.
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 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.
I failed at FizzBuzz in a coding interview, my first coding interview in fact. It wasn’t because I don’t know what modulo is or couldn’t forgive out the core logic... I just completely choked and my mind went blank. I made a function using a switch operator, but I couldn’t figure out how to do a for loop or apply. Hot Shame!
I work well under pressure. I generally have no issues with speaking in public or performing; I majored in music in college. My programming skills have lots of room for improvement, but that hasn’t stopped me from writing lots of useful, maintainable, performant code.
It sucked to fail at FizzBuzz. I’ve been working at my algorithms and syntax, but also trying to code in front of others as much as possible.
Exactly. Even when I am typing something with a friendly coworker causally looking over my shoulder, I tend to make way more mistakes then I would if I was by myself.
I've been interviewing a lot of people, and it is very, very important to make them feel as comfortable and as much at ease as possible in couple of first minutes etc. Otherwise you're going to be testing their stress resistance, and not creative thinking. And it is just impossible to completely remove the stress.
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?
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.
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.
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.
In the workplace we don't write katas, thats all there is to it... We have tools that we are able to offload most of the specificity required for real programming => Code examples, Documentation, Stack Overflow, IDEs, etc. ... This is both efficient and lazy.
There's also nuance to the "fizzBuzz" thing that people always leave out when they say that developers can't do "a simple fizzBuzz". Things like => It needs to be done on a whiteboard w/o syntax errors, they give FizzBuzz a significant variation, a requirement is slipped in to have fizzBuzz print on the same line when 15s come up, tons of things that make "a simple fizzBuzz" not so simple to pass if people aren't paying attention.
Gun to their head, IDE in hand, and stack overflow at their beckon, the vast majority of those programmers wouldn't have a problem stringing together fizzBuzz... but thats not really the question being asked in an interview now is it?
I am one of the people who was involved in the original discussion twelve years ago.
It is incorrect to say that there are a surprising number of programmers who can't program something as simple as FizzBuzz. The vast, vast, vast majority of working programmers have no trouble with such ridiculously simple toy problems.
However, although the overall proportion of self-identified programmers who can't program FizzBuzz is very, very small, the proportion of job applicants who can't program FizzBuzz is surprisingly large.
The entirety of the "surprise" as originally described was that the percentage is so out-of-whack. But once you think about it, it is not so difficult to understand why this may be so.
Competent programmers spend most of their careers working, not interviewing. If they are looking for a job, they tend to only go to a few interviews. Whereas, incompetent programmers spend more time looking for jobs, and when they are looking, they tend to apply over and over and over again to job after job after job.
So every company that has an opening gets "spammed" with the same couple of hundred applications from the same people the are applying for job after job after job. And many of them can't program FizzBuzz.
Whereas, the few competent people looking for a job tend to get an interview or two through referrals, then get an offer, accept it, and they are back in the workforce. But the couple of hundred applicants who can't program FizzBuzz shoulder grimly on, applying for the next job opening they find.
The net result is that if you have a job opening, you might have to filter out 90 or 95% of the applicants as "no-hopers," but that does not mean that 90% or even 9% or even 0.9% of programmers cannot program FizzBuzz.
TL;DR: The sample of programmers applying for a job is not representative of the set of all programmers, not even close.
I am someone who has changed development jobs quite a lot, far more than the average for my seniority.
Skill in software engineering can't just be measured by skill at writing the language, and this is trending forward faster and faster. The really accomplished engineer is one who has experienced many teams, many managers, many processes, and many deployments.
The accomplished engineer is opinionated about testing methods and about code readability, because he has suffered under many misconceptions about these things and taken the time to consider the alternatives.
Even if you change jobs frequently, and take long sabbaticals (I took a year off for the birth of my first child, and another to write one of my books), you probably still spend much, much, much more time working than actively seeking jobs from strangers.
Joel Spolsky explains the phenomenon quite well when explaining that just because you hire the top 0.5% of job applicants, does not mean you are hiring the top 0.5% of programming talent:
Re: FizzBuzz, one factor could be that it's deeply procedural/imperative in nature. Whereas HTML, CSS, and functional programming styles (which rule the JS world and quite a few others right now), have you thinking declaratively. If, like me, that's most of what you've been doing for the past couple years, FizzBuzz may take you a second because you have to dust off a different way of thinking. If you learned on declarative/functional stuff - in a web dev bootcamp for example - and never had exposure to anything outside of those practical skills, you may be totally lost.
Is that a bad thing? Probably. Computers are, at their base, imperative. So it's important to have a grasp on that way of thinking. But does it mean these people who've held "programming" jobs are frauds who don't know how to program at all? Not necessarily, I don't think.
If that's the case, you can solve FizzBuzz using a declarative style in JavaScript, surely? It's pretty trivial in Haskell, which is declarative all over.
It's a little more natural in languages like Haskell and Python that have range generators; JS doesn't. You can do a hack where you initialize a sized array and then map over its indices, but that's unusual.
Part of it may have been that the problem description I read used very imperative language. It didn't say "return a list of Fizz, Buzz, and FizzBuzz", it said "for each number that's ___, print X". Very side-effect-y.
Another thing is modulus. I know off the top of my head that mod == 0 means a number is divisible by another number because we used it all the time in my college programming assignments. People without a formal background may not even know what modulus is; there are lots of programming domains where it's not really useful.
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.
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?).
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).
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'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 managed software developers for many years at a fairly well known software company, where the first gateway for a hire was an advanced Math or CS degree with an undergraduate gpa of 3.5 or higher from a tough school (undergrade gpa because we felt that was more indicative of raw talent or work ethic than graduate gpa). This was followed by rigorous testing in logic and programming. Even after all that I found there were still between 10-20% of hires who could not code. Many with Masters or PhDs in Computer Science.
My theory is that coding is kind of like carrying a tune in music - either you have it or you don't. It's not an intelligence issue or a matter of education. These were bright folks. There is a mysterious innate ability that you must have to begin with, and some just don't.
The biggest thing that has jumped out at me is there seems to be a whole generation of programmers that can't troubleshoot or debug. Some of the requests for help from devs that I get is troubling to say the least. Talking with people at my user group meetings it's becoming worse and worse.
My theory is that I'm the last of a generation of developers who learned to program without the Internet. I started learning QBasic when I was 8 and progressed through C++, Perl and .NET. Back then you HAD to learn to break problems down and use logic to troubleshoot. You couldn't just Google the problem.
Google and StackOverflow are great resources but you have to understand how to approach and break down problems if you ever want to be a good developer.
Some basic level of programming and problem solving test is reasonable. What I find unreasonable - and which I am currently experiencing - are tests where the description is so convoluted or poor that the challenge becomes understanding the problem... not solving it.
All that said, I think you better measure a programmer/developer by asking some questions. Knowing syntax is the last step. But knowing how to break a problem up and which approaches to take in solving it, especially if there are constraints stated, is far more interesting. It's basically like asking the programmer to describe the program they would write.
Let's say the problem is, "Find the first 1000 prime numbers." The solution is less than 10 lines of code in most languages, but there's plenty to talk about.
I(nterviewer): How would you approach this problem?
C(andidate): Can I use the "prime" Ruby gem?
I: Well, it's good that you know it exists, but let's assume you can't.
C: I first need to define a function that, given a number, will return if the number
is a prime.
C: Then I need to loop 1000 times, checking each successive integer (starting from
1) with the is_prime?() function. If it's prime, I print it.
C: Then I increment to the next integer and return to the top of the loop.
I: How did you determine if the number was prime?
C: The simple approach is just to loop from 2 to n-1 (the number we are checking), testing to find out if the number is evenly divisible by the loop index. If it is evenly divisible, then it is not prime. Otherwise, it is prime.
I: Great. What if I asked for the first million primes? Is there anything you would do differently?
C: I would improve the is_prime? algorithm. Blah blah blah, go from 2 to n/2 (or is it square root of n?) Etc. And if that was still too slow, I would research efficient prime algorithms and implement one.
This will tell you if someone can program - even if they have never typed on a keyboard. Programming isn't about typing, it's about being able to define the steps needed to solve a problem.
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 won't comment on whether it is a good or bad thing that one can consider oneself a computer programmer† without being cognizant of modular arithmetic.
†to the degree that one is applying to be paid for it.
That's why I think practicing "leetcoding" is totally worth it. A significant amount of senior applicants fail easy codingbat level questions. Being proficient at easy level algorithm questions will usually push you to the front of candidates at non FAANGs. I've had interview panels tell me I was the first person who could solve basic palindrome and "best time to buy/sell stock" type questions.
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…
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.
My biggest problem with challenges like this in interviews is that sometimes they give you a problem to solve through, say, pure OoP when the challenge itself can be better approached using other paradigms (i.e. functional, or if the problem is very data centric, plain old SQL!)
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.
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 still recall the first time an interviewer wanted me to write FizzBuzz. I thought he was joking. I mean he had to convince me he was serious. It's a weird old world.
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 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 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.
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 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/
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.
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
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.
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
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.
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.
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.
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.