What not to do when giving technical interviews (2014)
seldo.com
seldo.com
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
Nope. The famous fizzbuzz test simply asks "can you actually write code at all?", because it turns out that some people applying for software development jobs basically can't. Even people with relevant-looking experience on their CV/resume. Even people who talk convincingly about what they've done.
(If you don't know about your preferred language's modulo operator but can do truncating integer division, you can do FizzBuzz that way instead. If you don't know how to do division, you can do it by having counters that count up mod 3 and mod 5, or one counter that counts up mod 15, and you don't need "mod" in your vocabulary to do any of that.)
Now, whether a candidate can write code -- like whether they know their language's modulo operator -- is also just one bit of information, but it's a really important bit of information that turns out to be tricky to get. This is also one reason for the "code on a whiteboard" tasks that many interviews use, which the author also doesn't like.
It may be that those are bad ways to get that one bit of information. But the author doesn't seem to appreciate what problem those things he criticizes are trying to solve.
If you're writing Spring Boot applications, tell me about which jars you include in your build to do that. Oh you only use Spring initializr? Okay, well, then tell me about which jars you added to your project after that initial setup. You say you use Kafka in your current role, tell me what jars allow you to set up Spring Boot Data for that. Oh, you don't use that approach? Interesting. We looked at doing that, too. And then, hopefully, you get to understand what they are doing and what they know.
Interviewing for Angular: What is your least favorite thing about working with Angular? What packages are you using in your application? Have you had trouble with your CI builds in Jenkins (or whatever they say they use?) I listen to them and I ask questions that ought to be relevant to them.
I typically start "hard" and then if I don't get anywhere, I ease back. You stated that you write REST services? Tell me, what Java library do you use for making a REST call from inside your application? Oh, okay, another team did that, I see...
And so on. It becomes very obvious whether the person is bullshitting you. I recently interviewed someone for a tech lead role who says he had been a tech lead at another company but I was astounded by not only how bad his answers were but also by how little he appeared to know about the business of coding. Either the guy was lying to use completely or he was in a real creampuff kind of lead role where you don't need to know anything about coding, anything about the architecture of the system you are responsible for, or anything useful at all, really. How do I get that job?
If you're doing this frequently enough, you probably have a template of which "jars" (dependencies) you generally use, so you probably don't remember.
If you're doing this infrequently, you probably googled what you need to include for what you want to achieve and forgot about it.
So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
You're being ridiculous. Being able to converse with other developers is part of being able to do the job. A very common topic of conversation is "what libraries are you using on your project? Why are you using X instead of Y?"
I expect every engineer I work with to be able to talk about the tradeoffs of using (or not using) any library in any project they've ever worked on. Knowing what's in your application is important with regards to size, speed, understandability, modifiability, etc. I consider this information far more important than if you can reverse a binary tree.
> So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
People who remember the dependencies they're using to implement things and can explain why they are using them are both efficient and competent. Most likely, anyway. It's not the only signal I use when hiring, but it's an important one.
edit: for clarity.
The first time I was given this problem on an interview it took me two attempts to get it right. That is, I wrote the code, ran it and it failed to do multiples of 15 properly
I went back and fixed it.
Would you count that as a failure?
I think it’s because many developers just call one API and send the result to another API - they never have to write any actual logic themselves, so they don’t know how.
One example: Declared themselves to be an experienced Pythonista of N+ years. Couldn't write a `for i in range(100)` loop in Python without hints. They probably could've done it in a different language, but I didn't want to have anything to someone who misrepresents experience in their CV. It's fine to say you don't know it and instead show me that you can learn it.
I'd love to see more openings saying "we use these tools, but we're open to work with anyone who can show they can learn them and be a solid team member".
I am curious as to how they would do with fizzbuzz.
Just like leadership and managerial tasks are not related to actual coding, talking about and evangelizing some library or technology does not mean you're a competent software engineer. They are very different skills.
Sounds like you've found yourself in an interviewing rut.
It’s just a widespread, deep culture problem in tech interviewing. The questions and evaluation procedures are set up to be pedantic oneupsmanship trivia, and are not rooted in psychologically healthy realities of the way people work or demonstrate skill or communication patterns.
Yet, he would have far higher chance to land in your company than me, because he would be super happy to pass FizzBuzz, whereas I would just walk away the moment you give it to me and make myself off for a month on Bora Bora to wash away the disgust I felt over your arrogance and pride you demonstrated on the interview.
Also, to address one more point in your reply - the inability to understand was a result of their incompetence, not the difficulty of the program (some standard C code).
"Whenever you find yourself on the side of the majority, it is time to pause and reflect." - Mark Twain
But if it was code that didn’t follow a process - especially C code - it could have had all sorts of security vulnerabilities. What if their process was never to use the “unsafe” variants of the C string and memory standard library functions?
At $JOB I feel bad that a lot of the talent on our team is squandered because they lack the self-confidence to speak up and question the status-quo.
I want to work with other people who have a deep-seated desire to do the right things, rather than only ever doing what they were explicitly asked to do.
So, kudos to you. Keep on fighting the good fight.
This person has actually thought about the effectiveness of FizzBuzz as test for overall programming skill. S/He will likely be an asset to the company due to having demonstrated a capacity for correctly assessing practices that are broken and having shown a willingness to refuse to continue following said broken practices.
There are three levers of power in an organization - relationship, expert, and role - in that order. If you don’t know how to build relationships and prove expertise and come into an organization like a bull in a china shop, you aren’t going to be effective - you are going to be disruptive.
I want someone who questions the effectiveness of broken practices, but you do that after you get the job, you have shown that you have a better way and you have built the relationships to push your ideas through.
I self demoted (responsibilities not pay) from a dev lead at one company to an IC at my current company. I have to bite my tongue repeatedly about things that could be done better but aren’t worth the effort to fight for. But on the other hand, I have to use “soft power” to change things and convince people about the things that are important to the organization.
Secondly, if all interviewees, say 5+ refuse to do the test on the basis of irrelevance, that would presumably change your opinion, would it not? It would certainly make me question the validity of my interviewing tests. Some people would probably blame a bad batch of interviewees.
Thirdly, some organisations need people to be disruptive as otherwise practices will never change.
Having said that, it really all comes down to how it's articulated. If candidate is polite and explains the reasons then that's fine. If candidate throws toys out of the pram then yes, I agree with you, not going to work.
People have widely varying approaches to relationships. I think it's beyond doubt that almost everyone who fails an interview at your (or any) company goes on to be employable somewhere else. So, it is valid to say they didn't know how to build a relationship with you, but then, you didn't know how to build a relationship with them. There is no correct answer to "which person is to blame for that", because each of them had the option to decide they don't want a relationship and therefore neither one controlled the outcome.
"I want someone who questions the effectiveness of broken practices, but you do that after you get the job"
If the broken practice is part of the interview, and a person has enough experience with interviewing at different places to know it's not the way everybody else does things, then they may have no reason to put up with it.
A danger in general of a single universal ("one true") standard, no matter how much sense it makes, is that you risk the people who have experienced different ways of doing things rejecting you for your chauvinism, without informing you that's what they are doing.
What ends up happening is that you offend the people you were hired to manage and they may follow the process changes grudgingly but they will “work to rule”, they won’t go the extra mile for you and they will not have your back when things hit the fan.
If I wouldn’t come in as a lead and immediately tell people the equivalent of “this is why you suck”, I’m definitely not going to do it during the interview.
I can see being scrupulously polite and tactful as having the potential pitfall that you lose sight of whether you really want the job. Psychological inertia in individuals and organizations can have a devastating impact.
If I came in to manage such a team. I would absolutely say so in no uncertain terms.
I have actually been in a similar situation but I did have the backing of senior management, in fact that was the main reason they hired me. They wanted somebody with experience in the industry to drive best practices so that they could show investors in order to attract investment (they had had two investors pull out after some due diligence showed that from a technical POV the company was in dire straits)
- it tells me whether I need to waste my time on doing harder questions.
- it tells me about your attitude when it comes to doing the grunt work that it sometimes take to push things over the finish line of whether you think you are too good to be assigned minor defects.
Both types of problems require a person be comfortable with arrays and iteration. It wouldn't be fair to give either of them to someone who can't get a simple for-loop right.
- those who are too bad for it
- those who are too good for it
our fizzbuz variant asks to print numbers from 1-100, and basically everyone among the few that did the fizzbuz part right got that part wrong, mostly printing 0-99 but also had one 0-100 printed.
this doesn't immediately disqualify a candidate of course, because the are a lot of reasons behind the mistake including the interview stress, but on requisite driven project attention to details is a major benefit.
Now that I think of it, why are you interviewing if you're such a hotshot? Shouldn't they be chasing you? Or was this purely hypothetical and you're already set for life?
I don't leak personal info about me on HN; let's say I have my own clients and too little time to do more things, and from time to time I interview as a sport to keep me up-to-date in case I need it in the future. In the past year and something I turned down Mark Z's company a few times as well as I work on more interesting things for more $ and with more flexibility (travel around the world yay! studying part-time at top schools etc.) than I would have achieved there.
I think that sort of worldview puts you below the hiring bar, regardless of your technical ability.
Next time you need a lawyer (I am sure you will), ask them which new laws were enacted in the UK in the year 1648 and if they couldn't answer, don't hire them!
I’ve also had to implement processes for some type of compliance reasons - most of the time HIPAA. The last thing I need is to be sitting in front of lawyer as Directly Responsible Individual, explaining why we weren’t in compliance.
As you mentioned above, you treat it as a double Bozo filter, I treat the use of it as a Bozo indicator and as "passing the Bozo event horizon in this company right now"; and my decision to walk away is like getting out of a dangerous situation with a black hole next to me.
For instance, if you said you were a skateboarding pro on your resume, the first thing I would ask you to do is an ollie.
- if when you looked at the job req and it said we were looking for C#/Java/Python/JavaScript developers and you wrote it in Haskell, that’s one signal that you probably won’t produce solutions that meet the customer’s need.
- if we are hiring Haskell developers and I can’t understand the code that means you write unmaintainable, over architected code and that you would still be a net negative for the company.
This would concern me that you don't validate your input. Just because the contract says something doesn't mean that's what you are getting. Trust, but verify. I trust that your CV is accurate, so I'm giving you a test that won't take up too much of either of our time to verify that you can code. Why? Because I've seen enough CVs better than yours where people can't do FizzBuzz.
Not wanting to FizzBuzz is also concerning because if it's a proven method of validation, why spend extra time and resources on something more that will only tell you the same thing?
So, to me at least, your antagonism here is really you wanting to waste resources and/or not validate input. Neither are good signs.
> Did you get 5th grader questions on your university exams as well?
If a 5th grader question is good enough to answer something, why bother with a 3-hour exam?
No, I want you to give me properly challenging questions to prove you deserve to be my employer (as I will be doing the hard work to make you a gazillionaire). FizzBuzz tells me you read one article a few years ago, didn't think about it at all (why could that be a problem?), and now give it left and right to anyone that has the bad luck of interviewing with you. You are telling me you are arrogant, prideful and lazy.
The interviewer has multiple responsibilities, one of them is candidate experience. If I start with the "challenging" question and the candidate isn't ready, then I learn nothing other than they can't do it and the candidate suffers, completely lost.
But, if I start with a middle-to-low bar question, then I can always get data and easily extend or follow-up the question with something more challenging appropriate to your skill & experience.
Except for the autoscaling group, all of this is basically networking 101. Their “resume” said they were “certified” and had experience. If you can’t get through the easy questions, no need to waste time on the hard questions.
If they didn't lie, then they wouldn't have gotten as far as they did. Everybody wants self-starters and people who can learn new things, but the person who already has experience in a laundry list of X, Y, and Z is always going to be preferred before you find out if they are a fraud.
What I did, in order to start doing something new that I didn't have experience in, was (although I didn't exactly plan it this way) to get a job that was explicitly administrative and did not involve programming and start automating it.
I don't think it's right or wrong that some people find IT culture (including interviews) intolerable, but the flow of people out of it shapes it. The more you rely (even unwittingly) on getting and keeping people who are ignorant there's something better out there, the more the ignorant (and/or incurious) shape your organization.
Putting my developer hat on. I interview a “senior developer”
They say on their resume that they have “used AWS”. Come to find out that all they have done was remoted into some EC2 instances.
They say they have used a certain CI/CD platform. I ask them have they set a pipeline up from scratch. They say no - someone else did it, we are expected to “own the whole stack” including setting up our own pipeline for our microservice. Not a deal breaker. That can be learned in a day. We have plenty of samples they can copy from existing pipelines for almost every scenario.
They put down databases they are experienced with. I give them a scenario and I ask them to model a table schema with it. They can’t do it. They are usually handed a table schema by the “database developers” [sic].
So finally I start working my way up to the actual development and I realize that because they were just a cog in the wheel at BigCorp, they never got a chance to design or write anything from scratch. They never had the joy of creating a brand new repo and doing a git commit with the message “initial commit”. Not horrible, but at a small company, you don’t get any handholding. You’re expected to work directly with the semi-technical product owner or even the end user if you’re senior enough. You are the Directly Responsible Individual.
So now, it’s demo day. The “senior developer” is demoing his code to management who is asking him questions and he melts under pressure or he gets defensible about “his code” and interrupts the CxO.
I want to know his temperament before I hire him.
I know people are going to say it’s not “fair” to expect that from a developer. I’ve had to learn every level of the stack. At some point you can’t call yourself a “senior developer” if you don’t know anything about the underlying infrastructure for your code or how to deploy it.
The next pushback I get is that J don’t remember what’s its like being a junior developer. Six months into my first job I was told to write a distributed data entry system that was going to be used to create a new department in the company. I had to sink or swim by myself - this was over two decades ago.
This seems to not jibe with the rest of your comment. You were defending not giving someone a chance to dive in, and then you say you had to learn to swim on your own.
Now, perhaps your point is that such a person should have the humility to classify themselves as something less than a senior developer, and then get that experience similar to you.
However, I wonder if the issue is that anybody with more than a couple years of experience is considered to be a pariah if they aren't a senior developer, which goes hand in hand with everybody inflating their experience in a vicious cycle.
I was the only one that knew how to program on staff.
So yeah, taking a job as a computer operator took a lot of humility. But, it was either that or be stuck in a small city doing COBOL programming.
Even today, it took a little humility to go from being the dev lead at one company, turning down a dev lead position at another company to become an IC who is officially under less experience team leads. But, I needed to fill in some gaps in my resume.
Off Topic: I think you are one of the few people on the internet that knows the word is “jibe” not “jive”.
There's going to be stuff that isn't done the way you want, in the company policies, in the code base, in the architecture, in the way the team works. If you're going to respond in an I'm-above-this, salt-the-earth kind of way when that happens, then no, I don't want to hire you. Go destroy some other workplace.
As I said, this is orthogonal to whether your criticism of the use of fizzbuzz is valid. Your response may make you feel better, but it's showing me a lot about who you are, and it's not improving your hireability.
If I were asked fizzbuzz in an interview, I think I'd say something like "I'll answer that. But I expect the rest of the interview to be at a considerably deeper level."
As somebody who was often interviewing other people fighting for jobs at top companies I worked for, I would never ever offend them by throwing FizzBuzz in their faces; I don't have such arrogance in me. I would rather try to figure out what clicks with them and throw them something tasty where they can show off, then increase pressure to see what needs more work, then explain/discuss what could have been improved. I would respect their time and help them to learn something on that single interview they had with me. Never throw into their faces that they are frauds which is implied by employing FizzBuzz. One doesn't have to be a super psychologist, just simple empathy is sufficient to understand that people perform best when they are respected and treated as adults.
> > > You'll moreover piss me off and get a placement on my blacklist of companies to never work for and me actively spreading the news about your interview to anyone capable I know, hoping nobody is going to waste time interviewing for your jobs.
Now you say:
> A dislike of a certain test must mean "to destroy some workplace".
That was a bit more than "a dislike of a certain test". If we hired you and you reacted that way to something you didn't like, that would be in "destroy the workplace" territory.
Reading this thread only solidifies my desire to ask for FizzBuzz, so that I weed out 2 types of candidates :
- those who are too bad for it
- those who are too good for it
Anyway: If it somehow happens that I'm interviewing you and you write a fizzbuzz program in super-fancy Haskell designed to be incomprehensible (if it's not designed to be incomprehensible then no, I'm not going to be unable to understand it for 30 years), then from my perspective I've learned: (1) you can indeed write code, (2) you're very smart, (3) you're a bit of an asshole. That's actually quite a lot of information for five minutes of interview time. (If you're super-smart but it takes you more than five minutes to write that fizzbuzz program, then you're prioritizing being an asshole over doing the job, because for sure you could have done it way quicker if you'd wanted; might not be a good sign.)
And if it somehow happens that I'm interviewing you and you misinterpret something entirely different that I say as advocacy for fizzbuzz in interviews, and go off on a rant about how no one any good should ever work for my company: no hire, have a nice day.
But it's not indicating you are a fraud, it's indicating that some people in your situation are frauds, which lamentably appears to be the case.
And your response to this situation where someone who at this point knows only what's on your CV and therefore hasn't yet ruled out the possibility that you might be a fraud gives you the chance to show you aren't one is ... to "show[] you my dominance"? Yeah, that's definitely a good idea in an interview situation.
No one "attempted to offend" you. (Well, I dare say people have from time to time. But if you interview for a job and someone asks you to write a fizzbuzz program, they are not doing it because they want to offend you.) They were in the unfortunate situation of having to hire someone in an environment where some candidates turn out to be much worse at the job than the readily available evidence suggests. They gave you a chance to show that you aren't one of those candidates. You took offence at that because somehow the interviewer was supposed to just know that you're one of the good ones, and reacted by trying to demonstrate your "dominance". I suppose the good news here is that everyone's glad you didn't get that job.
(As for "the level of my abstract thinking you won't reach", once again you are making assumptions that go beyond what you actually know. Like it or not, some people who are plenty capable of abstract thinking use fizzbuzz-like interview questions.)
Worse it would push for people that _excel_ at writing trivial interview code, which in my experience is inversely proportional to how much they are going to contribute to the success of the company. Though this is admittedly anecdotal.
Worse still you're going to be sending a signal to the interviewee that you are a kind of company that values trivial code. It's an interview both ways, the company gets evaluated too. The better the dev, the more offers they have so they might just not pick you based on stuff like this. They'll just get a _gut feeling_ that it's not a place they're going to like - that kind of thing.
As an interviewer, I personally don't think it's worth that bit of information, both in a game theory best outcome sense and just as a basic human decency.
No one is looking for people who can write fizzbuzz the fastest, or optimal in any way. They are looking for you to clear a low bar filter.
And this skill gets pushed down, forgotten.
It’s perfectly possible to write excellent battle tested and performant production code for years without encountering any of the stuff you see in the interviews.
And then they go to an interview and someone demands they wiggle out that piece of info from their long _long_ memory, in an unfamiliar env / os / periphery. With a huge time pressure...
Some people are good at that sort of thing, some people are good developers. Doesn’t mean they’re the same people.
I am not against it at all. It opens the conversation to some technical aspects that can be very intersesting to talk about.
As a candidate I love getting technical in interviews because It allows me to see how my prospective manager thinks. If we have radically different ways of taking care of a technical problem it's a red flag for me.
In the same area, I like the "let's talk about your last project" question too.
So, I've had my share of technical interviews and here what I observed :
I am usually unable to produce good software when the specs I'm supposed to use are not precise enough. I don't mean not complete enough. I mean not precise enough.
Be it on the job or in interviews I seriously question the ability of some interviewers to produce good technical interview questions.
By good I mean precise, using the right vocabulary.
I do not mean complete. You can knowingly give an incomplete spec to the candidate to see what kind of questions he/she would ask to try and get the whole picture. (or if he/she goes head first into an unsolvable problem)
But the details that are given need to be explained in precise terms. Not in a shadowy weird dialect based on a model that only the interviewer understand.
I've had my share of technical interviews and most of my fail attempts at live coding were due to (my lack of skill but also) questions not precise enough or misusing technical terms (sometimes even not grammatically correct questions).
The latter usually make me feel awkward because I wonder if those interviewers simply lack the minimum intelligence to explain a simple feature with precise words.
Good engineers I have worked with always use precise words to describe precise concepts. Using wrong or imprecise vocabulary is proof of a lack of understanding of the job and/or a will to try and sound "smart" or "tech-savvy" to compensate for some kind of inferiority complex.
So maybe a good advice to interviewers would be : technical questions on interviews yes. But good technical questions.
Have you ever considered that part of this is hoping that interviewees will ask questions seeking more precision? A lot of times on the job, you don't get such precision. There are unknowns you have to answer for yourself, and sometimes the right questions are more important than the technical approach.
That's why I insisted on the difference beetween imprecise and incomplete.
> I do not mean complete. You can knowingly give an incomplete spec to the candidate to see what kind of questions he/she would ask to try and get the whole picture. (or if he/she goes head first into an unsolvable problem)
I feel that using wrong technical vocabulary in a question is not a sign of a interviewer trying to make the candidate ask questions. Maybe it's just me.
1. Interviewing interns or new engineers while telegraphing the fact that your interviewers are absolutely uncreative.
2. Showing mid-senior interviewees that are a good fit that there is either a glaring hole in the recruitment team’s ability to filter out unfit candidates or that the interviewer thinks everyone is a dumbass but themselves.
Do you know your language's modulo operator? I went down a rabbit hole the other day porting some Python code to another language and discovered that modulo acts differently in different languages for rather subtle reasons.[1]
It took me, frankly, more time and iteration to implement Python style modulo correctly than I would have in an interview, or be able to muster while conversing with someone.
[1] https://en.wikipedia.org/wiki/Modulo_operation (see the table on the right)
(I deal with the other cases by making sure only to use % or similar on nonnegative numbers. If I ever encounter a case where I need to take remainders and performance is so important that I can't afford to do that, I'll double-check with the language documentation and leave a comment saying what the actual behaviour is. That's never happened yet.)
I don't have concrete reasons for thinking so, but my general impression is that this attitude is significantly more common in IT than other environments.
People make mistakes on everything,[1] no matter how trivial. Therefore, it can be threatening to even a genuinely competent person to be judged on a really elementary task, because even though it is simple to do, the margin for error is correspondingly small. The easier it is, the less excuse for any hiccup.
Of course, you just said you are not judging on minor issues, but it's hard to believe even assuming your best intentions. The simpler a task, the more judgmental human nature compels one to be, and the more confirmation bias will work to magnify any later errors.
[1] https://en.wikipedia.org/wiki/Muphry%27s_law aka Skitt's law
Now, I’ve probably taken 100+ math exams in my life and I’d be happy to provide data from any one of them. Why trump all that data with 15 questions? Viewing the application process as a pure machine learning problem, their decision seems crazy.
I've written two articles along these same lines:
When they arrive on site, we give them a 90% completed program that needs 2-3 lines of code to finish. We tell them they can use the web to look up anything they need to. We're mainly looking to see how the candidate thinks, and we discuss what they're doing and why. We're more concerned about the why than the what.
Once this is done (about 15-20 minutes in), we have a reasonable understanding if someone would be able to do the work. Next we try to figure out how much they would need to learn to be productive, and try to see if the candidate would be a good fit culturally.
We had one candidate who a minute or two into the live coding exercise said "Geez, I really don't think I can do this." I reminded him we weren't looking for a correct answer and to just give it a try, and he wouldn't. I thanked him for his time and ended the interview.
It's coming up with what you took in your data structures/algorithms class a decade ago on the spot and write full functions about them, especially on a whiteboard, that gets really annoying, and makes programmers feel like they have to refresh their knowledge of an entire class (plus a bunch of other trivia from across CS) every time they want to find a new job.
One nit, though:
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
FizzBuzz also tests basic programming skill, and it's surprising how often people fail that part. FizzBuzz isn't necessarily the best test of that; I know one interviewer who instead uses "write a function to swap two numbers". But some test of basic programming skill does help, albeit it should happen long before the in-person interview.
Also: have you, as part of your day job, ever written code to solve a specific word puzzle? (Based on an actual interview question I've answered.) An interview question is supposed to be representative; that doesn't mean every interview question must come directly from a specific problem encountered in production code. You ask questions to prompt people and see how they think and how they communicate.
“$x * (5/25) + 10 * $y”
In fact, we were writing custom document creation software and outputting to industrial printers at the first job where we were doing a lot of text processing.
1. it's a very simple thing to do, so why bother with a function? It's like asking someone to write a function that takes an integer value and returns an array of that length. 2. if you really do need a function that swaps numbers, then you probably also have some special edge cases that you will have to deal with that the candidate likely won't know about 3. each solution is language dependent
Maybe those aspects are why you consider it a good question, but when I have been asked those types of questions in the past I felt that the interviewer was missing an opportunity.
a = a ^ b
b = a ^ b
a = a ^ b
The above syntax works well in Python, but of course Python also had the much simpler tuple unpacking:
a, b = b, a
tmp = a, a = b, b = tmp?
tmp = a; a = b; b = tmp
When a compiler generates code, it maintains a mapping from variables to registers. So when the source code refers to the variable 'a', the compiler might map this to register %eax, and 'b' to %ebx, and it will use this to generate assembly code (or IR or bytecode or whatever).
A good compiler will recognize the three-line variable swap above, and optimize it so that the mapping simply changes at that point. So any references to the variable 'a' before the swap will refer to %eax, and after will refer to %ebx.
This requires zero instructions, and zero is less than three :)
I've rarely encountered a "swap" operation on local variables in straight-line code, as opposed to a loop, or a swap of global/in-memory values.
The XOR trick is cute but you shouldn't use it on anything larger or more modern than a Cortex-M0. Just put it through a temporary variable and let register renaming deal with it.
(Perhaps a more interesting question would be a multi-threaded examination of swapping two numbers...)
Finally it implies it could have asked a better interview question ;)
For some reason, I find it impossible to figure things out when I am looking over someone else's shoulder, or in a meeting, but when I am seated at my desk, it is vastly easier.
There seems to be an attitude of "I had to go through this, so I don't see why new hires shouldn't" hidden under a thin layer of justifications but in fact we're playing a game with very limited information. We probably don't even have the tools to know if we're doing good or bad hires except in extreme cases. We almost certainly don't know if we're rejecting the wrong people. Still we pretend like it's working.
To me, it seems overly rigid, pattern-matching against a too-narrow idea of what a good developer/employee/team member is. So much could be improved by just adding some flexibility, but maybe we're afraid of losing the illusion of having a Process and Objective Criteria.
Maybe I'm naive, but aren't we looking for what people are good at and what they might bring to the table? Maybe someone likes programming puzzles and whiteboards, let them do it, but don't insist if it freaks another person out. Maybe someone else would rather do a take-home assignment, but don't insist on it if someone else don't have the will to do several hours of unpaid work. Others might prefer pair-programming in person, technical quizzes, Codility-style problem solving online, actual paid work on a project basis.
Sometimes (well, maybe even typically) the beginning and ending of an application process are with different groups, and types, of people.
Depending on where you put your job postings you can get really swamped by them.
I think one ought to consider the possibility that if the vast majority of interviewees can't code at all, there is something wrong with the company/process. I mean, I'm not saying it necessarily follows, but the question is worth considering.
I have never been asked to implement FizzBuzz, so I can't buy the claim that "everybody does it".
Rightly or wrongly, if I was asked tomorrow, I wouldn't have the preconception that it was appropriate or necessary, and thus wouldn't necessarily choose to continue if I thought it was indicative of culture. If other people react similarly, it doesn't necessarily matter if it is a reasonable standard of competence; you're still skewing the pool in other ways than you intend.
When I was doing interviews I was always mostly discussing motivation. Most of the time the hires turned out very good, but I did happen to have one bad one and it cost us quite some time.
In some organizations, they start by recruiting people they think have talent in general, and then the interview is about finding where you fit in.
In others, they have a very specific need and they focus on winnowing down the pool to get the (hopefully) best person for it.
The place I'm talking about seemed to have a split personality.
Also, I've had enough interviews, both successful and unsuccessful, to be clear that there is no "normal". Every place is unique, as was this.
The golden question being "who gets to decide who is an asshole"
Ironically a paragraph down they say:
"You are NOT hiring for "team fit""
On the other hand, "hiring for future potential" sounds great but is really vulnerable to personal bias since it's inherently about the unknown future. If you want to run a deterministic interview process you need to have a standard set of questions and a rubric for assessing answers, written up in advance.
The syllogism you're proposing overlooks some human variables.
Interpersonal interaction tends to completely occupy my cognitive capacity, the moreso if the other person is a stranger, or if they are challenging me in some way (such as, for example, posing puzzles and evaluating the quality of my answers). I can't think about logical operations under those conditions. I require peace and detachment from human concerns in order to think that way.
This is, of course, a personal quirk, or, if you prefer, disability, and nobody should have to bear the burden of it but me. But I've been an actual 10X programmer on a shipping product, as verified by DVCS statistics. I submit that as evidence that I can, in fact, code. I just can't do it in interview conditions.
I also can't navigate while interacting with someone. I can drive just fine; I can operate a vehicle safely. I just can't navigate. Everyone in my close family is aware of this limitation. When my daughter was a teenager, she exploited this quirk for laughs. I have to admit, I thought it was pretty funny, too. In particular, I remember a pause in a conversation where I looked around and realized that I was parked at a Safeway in Capitola, California, and had no idea how I got there. My daughter and I both laughed when I realized what had happened.
But if you want me to drive, and you want to reach a specific, predictable destination, you have to leave me alone to navigate.
Similarly, if you want me to be a 10X programmer, or indeed any kind of working programmer, you have to leave me alone to do it.
Maybe I'm not the only one.
I won't argue that you should accommodate me, or people like me. Maybe you don't need us. That's okay. I've found other ways to get by--being hired by people already familiar with my other work, for example, or making my own products. It's maybe a less predictable career path than the usual, but it's worked so far.
But for obvious reasons, I can't agree with your claim.
I'd take someone who says "I can't live-code while talking about it, but here's an example of my code and I can explain how it works" over someone who tries to BS me.
Don't get me wrong; you as an interviewer are not under any obligation to adapt your hiring process to my quirks.
On the other hand, I'm not under any obligation to participate in a hiring process I don't like, either. I stopped participating in hiring processes I don't like around two decades ago, and I've survived anyway.
It doesn’t have to be perfect, I don’t have to be completely right, and after going and doing a proof of concept, I might be completely off base or realize there is something so didn’t think about. But I am expected to “pseudo-architect” on the fly.
- if they are confident and fail, I'll pass on them
- if they are nervous and we'll fail, we'll talk about it, and move on with the interview
- if they succeed, I'll move on w/the interview
- if they refuse, I'll hire them immediately and recommend them for promotion
Hosting a tech Q&A site doesn't make you the canonical source of how to structure interviews.
The live coding interview style was a toxic and negative contribution to the tech industry as a whole, IMO.
Really, you should read it (unless you were only trolling). It is a very fast read and full of insight.
Also, "tech Q&A site " is a huge mischaracterization of Joel's blog. He has really insightful articles like "Evidence based Scheduling", or the ones about (not) rewriting-code.