41–50 of 55 posts
False.
The fizzbuzz test asks, "Can you algorithmically about a problem? Can you understand variables? Can you program?" And it's the quickest, simplest way to find out.
How do you separate the people who "can do this job" from those who "can talk about doing this job"? There are many more of the latter than you may think.
Wouldn't it be better if flip the whole thing and ask the candidates under what situation would they feel most comfortable and then conduct the interview that way? Surely, we want to get the best out of people while making them comfortable?
Yes, even this approach is not suitable for those interviewees who don't know what is the best for them but atleast the interviewer will show they they genuinely care.
" The famous fizzbuzz test simply asks 'are you aware of the modulo operator?' " False. The fizzbuzz test asks, "Can you algorithmically about a problem? Can you understand variables? Can you program? " And it's the quickest, simplest way to find out. How do you separate the people who "can do this job" from those who "can talk about doing this job"? There are many more of the latter than you may think.
In the best interview I had, the interviewer started by saying, "Just talk" with a friendly smile. I was taken aback, and it eased the tension I was feeling. I started talking about my experience, and he took an active interest and branched off his questions based on the things I had done. He asked intelligent questions that made his compentency clear. I was able to volly back and forth with him until my competency b…
While this is my favourite way to both give and get a technical interview, it does have a major flaw - measurability. In that there is none. The approach works when you're trying to hire one person every couple of months.
But I am fairly certain it breaks down when you have to decide between hundreds of applicants every week and you need to have a measurable and predictable process that goes beyond your engineers saying "I have a good feeling about them".
Interview questions often have less to do with the candidate than they have to do with the interviewer. Meaning: It's either a superiority thing, a desire to impress, or just plainly covering up for lack of real interview skills. Gauge a candidate's skill set by asking open ended general overview questions like "Tell me about SCM branching and what advantages they provide" or "Tell me about a time you might have enco…
I've interviewed candidates who can talk an amazing game but can't seem to code. Starting a couple of years ago at our organization, it has been required that candidates produce _something_ that can run (or come real close to it).
Hiring the right people is a hard problem. The standard approaches, hiring software developers on the basis of code scribbled on white-boards or a series of narrow technical questions, are bad. Instead, I favor three different approaches, depending on the level of the position: We should hire new grads based on internship performance. We should hire senior developers based of their records of design, implementation,…
While I agree with sentiment this is not always possible. Company I work for, strongly "discourages" to sharing any code outside organization and also open source contributions.
Its not hard and fast requirement but recommendation to avoid code leak and sort of saying we might re-consider your job in passive language.
I know tons of companies right in SF who have "ultimate secrecy" for coding and also what they can contribute to open source.
There is no possible one solution for this problem.
Earlier quoted context omitted.
Why, what's the problem?
I'm not the OP, but I'd guess that they might need some starting point, a seed crystal, before they can crystallize them into a conversation. To the OP, I would suggest using the context of the interview to start (e.g. I am here because....).
Fizzbizz? Naah. What you want to do is something more like Minesweep. You go, "Mr. or Mrs. Candidate-Person, we're designing a Minesweep game. You've probably played it before. Here are the rules if you need clarifications. I'm handling the front-end, you write something for the backend." It doesn't matter the programming language they go for or the precise implementation they choose to any one of a number of issues.…
The idea of the FizzBuzz is that a lot of candidates are so bad at programming that can't even program FizzBuzz. So you can filter them early and don't lose you time. It's not designed to distinguish between the good and very good candidates.
In the best interview I had, the interviewer started by saying, "Just talk" with a friendly smile. I was taken aback, and it eased the tension I was feeling. I started talking about my experience, and he took an active interest and branched off his questions based on the things I had done. He asked intelligent questions that made his compentency clear. I was able to volly back and forth with him until my competency b…
It's shitty and lacks courtesy in standard conversation to do stuff like that, so it's even worse during an interview when the candidate took the time to prepare, dress up in nice clothes, and show up on site for the interview.
What bothers me about a lot of technical interviewers is they don't set out to measure a candidate's qualifications so much as to reinforce their own feelings of self-importance. It's because they have little incentive to surrender their own statuses within the organization because then they won't be the ones giving interviews and deciding who they get to work with.