4 ms·
EDIT > just to be clear, I am completely aware of the different reasons you ask for fizzbuzz, but I know that the question can be completely rehearsed and revis
by ionwake 6y ago
EDIT > just to be clear, I am completely aware of the different reasons you ask for fizzbuzz, but I know that the question can be completely rehearsed and revised with a few minutes of work. If you are using it as a metric I feel you are a poor judge.
In my experience, I have been unable to comply with the fizzbuzz questions in interviews - which has generally ended with me or the interviewer slowly closing the interview.
At the same time I was one of 2 people who built a major airlines checkin system within a couple of months.
The interview for this role? A phone call, after looking through my CV.
The roles which asked me fizz buzz? generic roles in companies that since went nowhere, I even got a callback telling me the technical hiring manager had since been fired ( or left ) and if I would re consider interviewing, which I then had to turn down.
I am not saying you are wrong, I am probably wrong to judge a person if they are assessing my years of experience with a test aimed at an 18 year old.
But be aware of how fizzbuzz makes some developers react.
- josephg 6y agoI don't want to screen out good candidates, and I'm genuinely curious about your experience. If you have no problem building a major airline checkin system, you must have some practical skills. Can you explain why you couldn't implement fizzbuzz in an interview? What went wrong? If you designed an interview question which would show off your skills instead of undermine them, what kind of technical questions would you like to be asked instead?
- ionwake 6y agoIve been thinking about this over coffee. If my friend said to me in a bar "tell me why computers are good" , I would have a deep conversation with him that would cover different domains from philosophy to the sciences. If an interviewer for a job, requiring a specialist in 4 frameworks, 2 languages, a nosql db, cognito authentication, a complex portfolio which matches the job spec and real world examples of viable commercial products, sat me down in a room, and asked me to answer the same question, as an opener, and it was timed to a minute - I would flounder. The experienced dev vs the fresh graduate Sure I could have done some research into the several domains, written down a good short concise answer, which covered a general aspect of each domain and recited it. However I did not. I would have no reason to prep for such a question due to the amount of time Ive spent in the commercial sector developing solutions rather than rehearsing interviews like a fresh graduate who has never programmed before would do. Can I solve the problem? Ofcourse, but not as quickly as someone who has revised for it, even if I take a couple of minutes longer, it would be taken badly - regardless of whether it was rote or freshly devised. You arent selecting for a good developer - you are selecting for someone who has had the time to prepare for interview questions ( a massive red flag in my book ) The answer? Atleast for me. Is he experienced? Does the conversation flow naturally? Do you feel he is a loyal, dependable person who can clearly communicate? Well I would say that covers 90% of the issue. Hire the guy, see how he performs.
- josephg 6y agoThis makes sense. But I'm still confused about your struggle to implement fizzbuzz in an interview. Fizzbuzz doesn't need you to understand 4 web frameworks and a nosql database. Its like, 5 lines of code. What happened? > Is he experienced? Does the conversation flow naturally? Do you feel he is a loyal, dependable person who can clearly communicate? Well I would say that covers 90% of the issue. Hire the guy, see how he performs. Interesting idea but unfortunately this isn't a viable strategy. There's a mountain of people who are perfectly charming but can't program, and we need to screen them out. And there's plenty of great programmers with awkward social skills who we would love to hire. A few years ago I interviewed an Indian developer with broken english, who'd spent the last 10 years working on Oracle internals. She wasn't charming or a good conversationalist and her resume had obvious typos. I had very low expectations - but when I interviewed her I realised her technical knowledge was top notch. It took both me and my boss to bat for her for the client to give her a chance. But she ended up outlasting everyone else on her team. The company we placed her at absolutely adore her now. If I didn't go deep on technical content, I wouldn't have known that and we would have passed her up.
- ionwake 6y agoIm going to move off fizzbuzz because I feel that I have explained my position well enough. Regarding the developer with the broken english, how long a developer stays in a team is not necessarily a good sign, the others could have left because she was hard to work with. However you said the new company liked her, so thats good, maybe she was great. When you made your last point about "going deep on technical content being good" I don't think you've understood my point of view very well. I'm not saying not to ask technical questions, Im saying ask complex ones, where possibly relating to the developers experience.
- lifeisstillgood 6y ago>>> Its like, 5 lines of code. What happened? I have no knowledge of the specific, but I think most people have experienced a freeze up in an interview - I certainly have. (I tried to reimplement basic math functions on a coding test - I still have no idea what happened) That's why there is no silver bullet - fizzbuzz is an indicator. But we rely on expertise to spot itself - or spot potential. Which is why we need to be careful of just cloning ourselves and our cultural biases. For example, you could put your Indian dev in front of me and I would not have the Oracle depth to recognise her as skilled enough to go to bat for. But Python internals? Yeah maybe. PostgreSQL once upon a time. Its frankly still a hard problem.
- arethuza 6y agoI had one experience in an interview where I couldn't context switch fast enough to answer a simple technical question. It was for a CTO job and I was asked to prepare and present a presentation on "how to launch a product" - I think I had 30 minutes to prepare and 30 minutes to give the presentation to their management team. This went really well. Then the CEO wanted a quick chat and asked me a simple technical question - and I could not do it. My brain simply froze and he clearly thought I was an idiot or some marketeer pretending to be technical. The reverse being far closer to the truth! Edit: I've interviewed a lot of people over the years and would never had believed this could happen until it happened to me.
- ionwake 6y agoSame happened to me. I remember thinking " these 2 interiewers are thinking Im thinking about the solution, but Im not, my mind is blank because of the stress of having to answer a seemingly simple question, but I know if I say the slightest thing in the wrong way Ill be judged harshly for it" I realise this is a problem with me and stress during long interviews, but it was still a little funny at the time.
- arethuza 6y agoI was upset about it at the time but eventually realised, based some of their longer term plans, that I had dodged a bullet.
- josephg 6y agoIts not just you. When I interviewed regularly I felt like that was probably the biggest difference between a great interviewer and a terrible one. Any decent programmer can ask technical questions, but great interviewers will do everything in their power to help you stay relaxed and calm while you answer them. When you get too stressed, your creativity then your memory stop working properly. So its simply impossible to fairly assess the technical skills of a candidate while they're on their way to a panic attack. Knowing how to keep people calm is rarely on the job description, but its an essential skill of any good interviewer.
- WkndTriathlete 6y agoThe big problem with implementations in interviews (or coding challenges in general) is that they don't test what the interviewer is thinking they are testing, and it is usually a clear indicator that the business looking to hire has some major shortcomings in their developers. For what it's worth I've been on both sides of the table. I don't bother with code when I interview because it's a waste of time. I may show a (non-critical, not-worth-NDAing) section of code to a prospective employee and have a discussion about it, but in general I can suss out whether someone knows what they are doing in less than 30 minutes just by having a conversation with them. Why make the applicant or me wade through 2-3 hours of code and not get a sense of what they are truly capable of when I can talk to them for 30 minutes and assess their technical ability, communications patterns, and fit for work culture simultaneously? The smartest people I've ever worked or interviewed with don't bother with code as interview.
- scatters 6y ago> one of 2 people who built a major airlines checkin system within a couple of months That doesn't tell me whether you can code; it's entirely possible the other person did all the coding and you did architecture, requirements, user stories, testing, integration, office politics, SnapChat. You might still be a great asset to the company; my job as a technical interviewer though is to assess whether you can code.