Unfortunately a lot of people do fluff up their resumes for sure. What would be some of the pitfalls in your position as an interviewer to give someone a small project? Do you feel like the pop-quiz is more time efficient?
I've been in the software game for 30+ years now. I cut my teeth with C and then moved to C++ in its early days. I have worked on a number of systems, mostly embedded systems and simulations.
Location
Bay Area, California
Education
BS Chemistry, USAFA and MS Systems Engineering CSU
There are two primary issues I see with giving someone a project. The first is related to IP. Most of the stuff we develop is considered "company-secret" and not to be disclosed to non-employees. So, handing company code to an "outsider" is not allowed.
The second issue is one of time. First is the time needed to explain the development environment. Then there is the time needed to explain the product - and the piece the interviewee is to work on. Finally, there is the time required to review the code produced by someone not really familiar with what we are doing or how it fits into the overall system.
If we don't give a small 'project' related to our overall business, then how is it really different from a quiz of some kind? It amounts to handing some toy problem to a developer and seeing what kind of code s/he produces. And we still have to deal with the time element for the review of the code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Unfortunately a lot of people do fluff up their resumes for sure. What would be some of the pitfalls in your position as an interviewer to give someone a small project? Do you feel like the pop-quiz is more time efficient?
There are two primary issues I see with giving someone a project. The first is related to IP. Most of the stuff we develop is considered "company-secret" and not to be disclosed to non-employees. So, handing company code to an "outsider" is not allowed.
The second issue is one of time. First is the time needed to explain the development environment. Then there is the time needed to explain the product - and the piece the interviewee is to work on. Finally, there is the time required to review the code produced by someone not really familiar with what we are doing or how it fits into the overall system.
If we don't give a small 'project' related to our overall business, then how is it really different from a quiz of some kind? It amounts to handing some toy problem to a developer and seeing what kind of code s/he produces. And we still have to deal with the time element for the review of the code.