4 ms·

You'd be surprised at how many people haven't learned to solve basic coding problems in college. I have no problem doing a whiteboard problem if I were intervi

You'd be surprised at how many people haven't learned to solve basic coding problems in college. I have no problem doing a whiteboard problem if I were interviewing. It's entirely possible that the person who has gotten that far in the process literally cannot code Fizzbuzz. It's not an insult to be asked to do these things. It's a reality caused by the fact that some people can BS their way into anything, the hiring process at most companies is deeply flawed, and usually not the fault of the people you are talking to in the interview. Obviously anyone who is that offended by this has never seen the other side of the equation where you've hired someone who turns out to be completely incompetent despite appearing to be very knowledgeable and smart in the interview, and now you've invested a whole lot of time and effort and money even if you are able to cut the person loose quickly. It happens. A lot. And it's often not because the hiring managers and other interviewers are idiots or otherwise failed to interview the candidate well.

AndreyErmakov 10y ago
I hear you and understand the situation. What I'm saying is that some preliminary digging would improve your chances of encountering a truly skilled guy. Academic institutions generally don't teach people to code. It's always a personal quest. You can tell a lot about somebody who's graduated but never gone any extra mile. That should be the basic filtering criteria. I too have seen people studying at CS departments who were useless at coding. I even helped some mates with their assignments so that they wouldn't get thrown out having invested several years already, though our field of study was not purely CS but more the hardware side of things so graduating as a bad programmer wouldn't be a terribly bad thing. Yet I know for certain none of them ever planned to be looking for a job as a programmer. And if you investigated their programming accomplishments you would quickly find out they should be passed on. I also noticed that people who are smart and even brilliant do graduate with real programming skills but without personal projects of any sort. The thing is, they may join in as an ordinary programmer but do not plan to stay there long, meaning to quickly move into management or a business branch. You probably don't want them either. Some preliminary research is always the right thing to do. You won't believe how many times I arrived at an interview and watched the HR turn over my resume to the interviewer for the first time ever, so he had to quickly scan it to get an idea what to discuss. With that approach not much can be accomplished on the hiring track.
- AndreyErmakov 10y ago
  To add, this form of mutual preliminary research should really be a standard approach, followed by a remote first contact. If everything goes smoothly, then things can me moved to the next level and a personal meeting can be arranged. Much better than blindly bringing people in, sometimes from hundreds/thousands of kilometers/miles away only to find out within ten minutes this was all a huge mistake. You're wasting your time, their time, money, electricity/fuel on nothing and it's highly inefficient.
norea-armozel 10y ago
I think the problem I have with fizzbuzz sorts of code 'challenges' is that it shouldn't be about if you got the right answer but more of how you go about finding the right answer; getting requirements, understanding the requirements, and coming up with something close to those requirements even if it's wrong. Instead, I've seen from other people's anecdotes is it's more treated as a standardized test for aptitude and it's just a bad approach to treat them as such. All the binary right/wrong approach proves is that some people aren't quick thinkers or they're bad test takers. In my own brief experience of a few years in programming professionally, the real world is rarely about binary right/wrong and more like iterative less wrong in terms of developing applications. The latter approach requires the ability to self-correct, seek solutions from others when you're lacking knowledge, and knowing when to tell your superiors that something contradicts earlier, mandatory, requirements of an application. So, I don't blame people pushing back against the HR-woo that's creeping into IT. Simply put, if a company thinks programming is like reciting all the capital cities of the United States and Territories then they have no clue what programming is about and maybe they should get out of that business altogether.

AndreyErmakov 10y ago

I hear you and understand the situation. What I'm saying is that some preliminary digging would improve your chances of encountering a truly skilled guy. Academic institutions generally don't teach people to code. It's always a personal quest. You can tell a lot about somebody who's graduated but never gone any extra mile. That should be the basic filtering criteria. I too have seen people studying at CS departments who were useless at coding. I even helped some mates with their assignments so that they wouldn't get thrown out having invested several years already, though our field of study was not purely CS but more the hardware side of things so graduating as a bad programmer wouldn't be a terribly bad thing. Yet I know for certain none of them ever planned to be looking for a job as a programmer. And if you investigated their programming accomplishments you would quickly find out they should be passed on. I also noticed that people who are smart and even brilliant do graduate with real programming skills but without personal projects of any sort. The thing is, they may join in as an ordinary programmer but do not plan to stay there long, meaning to quickly move into management or a business branch. You probably don't want them either. Some preliminary research is always the right thing to do. You won't believe how many times I arrived at an interview and watched the HR turn over my resume to the interviewer for the first time ever, so he had to quickly scan it to get an idea what to discuss. With that approach not much can be accomplished on the hiring track.

AndreyErmakov 10y ago
To add, this form of mutual preliminary research should really be a standard approach, followed by a remote first contact. If everything goes smoothly, then things can me moved to the next level and a personal meeting can be arranged. Much better than blindly bringing people in, sometimes from hundreds/thousands of kilometers/miles away only to find out within ten minutes this was all a huge mistake. You're wasting your time, their time, money, electricity/fuel on nothing and it's highly inefficient.

norea-armozel 10y ago

I think the problem I have with fizzbuzz sorts of code 'challenges' is that it shouldn't be about if you got the right answer but more of how you go about finding the right answer; getting requirements, understanding the requirements, and coming up with something close to those requirements even if it's wrong. Instead, I've seen from other people's anecdotes is it's more treated as a standardized test for aptitude and it's just a bad approach to treat them as such. All the binary right/wrong approach proves is that some people aren't quick thinkers or they're bad test takers. In my own brief experience of a few years in programming professionally, the real world is rarely about binary right/wrong and more like iterative less wrong in terms of developing applications. The latter approach requires the ability to self-correct, seek solutions from others when you're lacking knowledge, and knowing when to tell your superiors that something contradicts earlier, mandatory, requirements of an application. So, I don't blame people pushing back against the HR-woo that's creeping into IT. Simply put, if a company thinks programming is like reciting all the capital cities of the United States and Territories then they have no clue what programming is about and maybe they should get out of that business altogether.