Code Samples for a Job Interview
-
I've received an email from a prospective employer inviting me to set up a job interview. A note at the end requests a link to my GitHub code repo or sample code/projects prior to the interview. I don't have a personal GitHub repo or code samples because, unlike probably most here, I no longer do programming as a hobby on my own time. Everything I've done in the last 15 years that the interviewer would be interested in is proprietary code I've written for my current employer, and I don't feel comfortable sharing that outside the company, even though the two industries are not related by any stretch of the imagination, so they wouldn't be able to benefit. What would you do in this situation? Rewrite some of your code to remove any hints of its purpose or value to your employer? Write new code?
If you think 'goto' is evil, try writing an Assembly program without JMP.
Ask them for a problem, and solve it in front of the interviewer. If the interviewer doesn't praise your idea, don't even consider applying for such a company.
-
Jeff Moden wrote:
While I do whole heartedly agree that your job shouldn't be your entire life (especially if you have kids or are married), you DO need to spend some time learning your trade and that's what employers want to see because they're tired of people that can't even get a bloody date right.
I don't know about you, but I wouldn't wan't to show anyone the code I write when I'm learning something. Its typically code of the worst sort because it is one time use throw-away code. Maintainability and elegant design are not the focus, learning is. I find that maintainability, elegant design and polish are my value add -- they're what I can bring to the table beyond simple mastery of the topic, but they don't really kick in until the third project I do, and by then, I'm typically doing it for an employer and don't retain any rights to that work.
I live in Oregon, and I'm an engineer.
Yeah... strongly agreed. You mistook what I said. It's not the "learning" code that they want to see. They want to see that you're taking the time to learn. Once you've learned how to do something, then turn it into a formal but still personal bit of code and use it as an example of your work. I totally agree on the ideas of maintainable code, elegant design, and polish will set folks well apart from those that don't practice those ideas. Again, the chance to shine in those areas is the demonstrable code you send them when they request it. Of course, this should be YOUR code... not the code that an employer has proprietary rights to or anything else that would violate an NDA, Covenant not to compete, or ethics in general.
--Jeff Moden
-
Heh... I'm looking at this site and see the following at the bottom of the thread list.
Quote:
Last Visit: 31-Dec-99 19:00 Last Update: 8-Feb-18 3:29
With that, the forum code also cutoff the "La" of "Last" when I block quoted and I had to correct it. Perhaps if people spent a little more of their own time learning the trade that pays them, these types of silly mistakes wouldn't happen. And that brings us back to the subject of the original post. While I do whole heartedly agree that your job shouldn't be your entire life (especially if you have kids or are married), you DO need to spend some time learning your trade and that's what employers want to see because they're tired of people that can't even get a bloody date right. While I also agree that you shouldn't have to keep up a web-presence or list your code on the likes of Git-Hub, you should be prepared for an interview especially if you have 15 years experience like the OP does. It will also show them good common sense and respect on your part if you tell them that you respect the proprietary nature of a previous company's code but don't let that be a barrier to showing your stuff. After all, you're on an interview to determine if you have the skills to do your job. And, no... the stuff you put on your resume isn't enough. That's just the proverbial "knock on the door". Too many people either exaggerate their knowledge or flat out lie on resumes. During one run of interviews of both experience web developers (with good knowledge of T-SQL) and DBAs (all claimed at least 10 years of experience on their resumes), 20 out of 22 couldn't answer the simple question of how to get the current date and time. I had originally started asking the question as a simple ice-breaker question to help the candidates relax. Little did I know it was going to me the litmus test for how the rest of the interview was going to go. Out of that same batch of people, only 1 DBA knew anything about how to do native backups and restores (and no... I do NOT ask for the precise syntax). One of the people also claimed to be an expert T-SQL performance tuner (again, with more than 10 years experience). When I asked him about clustered indexes (and, no, I didn't make this up. It's just too silly to even think of such a thing) he told me that he never worked with them because he had never worked with clustered servers. Employers are sick and tired of wasting time on people that don't actually have
Thanks for your response. I get what you're saying. But not having a cache of personal code that demonstrates my knowledge doesn't mean I'm not learning new things. A constant part of my job here requires learning new things. But it doesn't leave behind any code that would be useful to demonstrate my skills, just a bunch of 'hello world'-like snippets. And it sounds like you were able to weed out candidates purely through the interview process without seeing any code or syntax. Hopefully my interviewers will be able to do the same.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
I've received an email from a prospective employer inviting me to set up a job interview. A note at the end requests a link to my GitHub code repo or sample code/projects prior to the interview. I don't have a personal GitHub repo or code samples because, unlike probably most here, I no longer do programming as a hobby on my own time. Everything I've done in the last 15 years that the interviewer would be interested in is proprietary code I've written for my current employer, and I don't feel comfortable sharing that outside the company, even though the two industries are not related by any stretch of the imagination, so they wouldn't be able to benefit. What would you do in this situation? Rewrite some of your code to remove any hints of its purpose or value to your employer? Write new code?
If you think 'goto' is evil, try writing an Assembly program without JMP.
I had to do that for a job and a friend of the interviewer stole the code and sold it under his on name and he was stopped by a lawyer (luckily). You can not trust people with private code. I would suggest that you could do some work on a open source project and then give them a link to that. That way you would not be in a position where your past companies would want to sue you over a NDA violation.
-
Yeah... strongly agreed. You mistook what I said. It's not the "learning" code that they want to see. They want to see that you're taking the time to learn. Once you've learned how to do something, then turn it into a formal but still personal bit of code and use it as an example of your work. I totally agree on the ideas of maintainable code, elegant design, and polish will set folks well apart from those that don't practice those ideas. Again, the chance to shine in those areas is the demonstrable code you send them when they request it. Of course, this should be YOUR code... not the code that an employer has proprietary rights to or anything else that would violate an NDA, Covenant not to compete, or ethics in general.
--Jeff Moden
Jeff Moden wrote:
Once you've learned how to do something, then turn it into a formal but still personal bit of code and use it as an example of your work
I don't generally have the time or inclination to massage throwaway, toy-project learner code to make it all pretty. That's something I'll do when I do my next project, and typically, that next project ends up being my first attempt at real work with the new knowledge.. which means it's already owned by someone else.
I live in Oregon, and I'm an engineer.
-
I've received an email from a prospective employer inviting me to set up a job interview. A note at the end requests a link to my GitHub code repo or sample code/projects prior to the interview. I don't have a personal GitHub repo or code samples because, unlike probably most here, I no longer do programming as a hobby on my own time. Everything I've done in the last 15 years that the interviewer would be interested in is proprietary code I've written for my current employer, and I don't feel comfortable sharing that outside the company, even though the two industries are not related by any stretch of the imagination, so they wouldn't be able to benefit. What would you do in this situation? Rewrite some of your code to remove any hints of its purpose or value to your employer? Write new code?
If you think 'goto' is evil, try writing an Assembly program without JMP.
Download a cool sounding small project from the public git hub section. 15 minutes with refactoring and formatting, upload to your private git hub and your good to go. What's that - there's an ethics test too? Crap. :-\
I'm pretty sure I would not like to live in a world in which I would never be offended. I am absolutely certain I don't want to live in a world in which you would never be offended. Freedom doesn't mean the absence of things you don't like. Dave
-
Jeff Moden wrote:
Once you've learned how to do something, then turn it into a formal but still personal bit of code and use it as an example of your work
I don't generally have the time or inclination to massage throwaway, toy-project learner code to make it all pretty. That's something I'll do when I do my next project, and typically, that next project ends up being my first attempt at real work with the new knowledge.. which means it's already owned by someone else.
I live in Oregon, and I'm an engineer.
No time and no inclination... that's fine but don't get mad if someone beats you out of a job that decided to make the time and had the inclination. ;-) I'm trying to explain how to win the job. You don't have to take that advice. It's your choice.
-
Thanks for your response. I get what you're saying. But not having a cache of personal code that demonstrates my knowledge doesn't mean I'm not learning new things. A constant part of my job here requires learning new things. But it doesn't leave behind any code that would be useful to demonstrate my skills, just a bunch of 'hello world'-like snippets. And it sounds like you were able to weed out candidates purely through the interview process without seeing any code or syntax. Hopefully my interviewers will be able to do the same.
If you think 'goto' is evil, try writing an Assembly program without JMP.
We didn't manage to hire anyone because we never got to the code part. The candidates were that bad. I also agree that just because you don't have a personal cache of code examples doesn't mean that you're not learning anything. But, when a company asks for such a thing as a part of the pre-interview, you need to have one because, in the absence of one under such conditions, you may never get invited to an interview. And, no... I'm not talking about the "toy" code some are speaking of. The internet is full of forums where people ask for help. Solutions to such questions make great examples for a code cache, especially the more complex ones. Again, I'm not trying to force anyone to see it my way. I've been on both sides of the hiring fence and I'm trying to help folks see it the way employers see it to give them a better chance at being the successful candidate for a job.
--Jeff Moden
-
Download a cool sounding small project from the public git hub section. 15 minutes with refactoring and formatting, upload to your private git hub and your good to go. What's that - there's an ethics test too? Crap. :-\
I'm pretty sure I would not like to live in a world in which I would never be offended. I am absolutely certain I don't want to live in a world in which you would never be offended. Freedom doesn't mean the absence of things you don't like. Dave
-
1. Imagine you owned the company you are interviewing for and you're interviewing a programmer. 2. Imagine you knew that the code is a representation of the actual business itself -- via business processes, etc. 3. Imagine that when the developer wrote the code that s/he would own a part of the business itself via owning the business processes it represents. 4. Imagine that the developer could walk out at any time leave behind a mess of business process behind that some other poor unfortunate would have to maintain. 5. Imagine your business might lose time, customers, and/or money because of that. Now, what questions would you ask? :laugh:
I always try to leave documentation, standards, and well-commented code behind. My purpose isn't job security, it's to make sure that the next programmer does not face the same mess I walked into.