Got an offer from a software company: may *I* ask for a code sample now? [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
This question already has an answer here:
How can I ask a potential employer to show production code?
11 answers
I know this question will raise eyebrows and I kind of enjoy it.
I passed the interview with a company making software, and got an offer. May I ask for a sample of their codebase? The reason is that the company is founded and run by a number of highly talented PhDs in Mathematics and Physics, and this often implies the quality of the source code is pure junk (to quote a classic: https://academia.stackexchange.com/questions/17781/why-do-many-talented-scientists-write-horrible-software). Every "pure" software engineer knows that: behind a brilliant researcher an awful programmer is hidden, and I don't want to be the janitor cleaning after him/her.
Is that an acceptable request? If so, how can I motivate it without sounding rude?
interviewing software-industry communication job-offer
marked as duplicate by Telastyn, Chris E, gnat, Elysian Fields♦ Mar 21 '15 at 16:18
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
 |Â
show 5 more comments
up vote
4
down vote
favorite
This question already has an answer here:
How can I ask a potential employer to show production code?
11 answers
I know this question will raise eyebrows and I kind of enjoy it.
I passed the interview with a company making software, and got an offer. May I ask for a sample of their codebase? The reason is that the company is founded and run by a number of highly talented PhDs in Mathematics and Physics, and this often implies the quality of the source code is pure junk (to quote a classic: https://academia.stackexchange.com/questions/17781/why-do-many-talented-scientists-write-horrible-software). Every "pure" software engineer knows that: behind a brilliant researcher an awful programmer is hidden, and I don't want to be the janitor cleaning after him/her.
Is that an acceptable request? If so, how can I motivate it without sounding rude?
interviewing software-industry communication job-offer
marked as duplicate by Telastyn, Chris E, gnat, Elysian Fields♦ Mar 21 '15 at 16:18
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
2
I'm not sure how helpful the internet is going to be here. The only way you're going to find out is by asking them. It doesn't sound unreasonable to me. If I were the company, I would probably ask you to come in to the office instead of sending you anything.
– Bowen
Mar 20 '15 at 20:19
2
And one sample tells you nothing about how their other people code. Besides the question of whether they want to show you anything significant without a signed NDA, though that might be manageable. Basically, I think the answer is going to be that cleaning up others mistakes is always an implied part of the job, and making too much stink about that is a good way to get invited to apply elsewhere. Tl;dr: you can always ask, but you may not like their answer or their reaction.
– keshlam
Mar 20 '15 at 20:41
6
THAAAT's the attitude companies want new hires to show up with </sarcasm>. Did you consider that maybe the reason they want to hire a "pure" software engineer is to bring good practices to their company? Besides, this is a question you should have asked in the interview.
– Wesley Long
Mar 20 '15 at 20:57
3
@NathanCooper - "Good Enough" isn't the issue. As an engineer (whatever discipline), you are being hired to solve problems. No one said "Drop to your knees," but if you're such a prima-donna that you aren't willing to tackle a funky codebase, I'd be careful about calling yourself an "Engineer." The question of whether or not the position will have the authority to correct the funkiness is entirely appropriate, however.
– Wesley Long
Mar 20 '15 at 21:18
1
I suspect keshlam is right. It's unfortunate that this wasn't part of the interview. But I'm sure you could reach out to them and get some time to look at the code, the problem's they're solving and get a sense of your colleagues. I'm sure this company has no interest in hiring someone who doesn't want to work on the codebase.
– Nathan Cooper
Mar 20 '15 at 21:18
 |Â
show 5 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
This question already has an answer here:
How can I ask a potential employer to show production code?
11 answers
I know this question will raise eyebrows and I kind of enjoy it.
I passed the interview with a company making software, and got an offer. May I ask for a sample of their codebase? The reason is that the company is founded and run by a number of highly talented PhDs in Mathematics and Physics, and this often implies the quality of the source code is pure junk (to quote a classic: https://academia.stackexchange.com/questions/17781/why-do-many-talented-scientists-write-horrible-software). Every "pure" software engineer knows that: behind a brilliant researcher an awful programmer is hidden, and I don't want to be the janitor cleaning after him/her.
Is that an acceptable request? If so, how can I motivate it without sounding rude?
interviewing software-industry communication job-offer
This question already has an answer here:
How can I ask a potential employer to show production code?
11 answers
I know this question will raise eyebrows and I kind of enjoy it.
I passed the interview with a company making software, and got an offer. May I ask for a sample of their codebase? The reason is that the company is founded and run by a number of highly talented PhDs in Mathematics and Physics, and this often implies the quality of the source code is pure junk (to quote a classic: https://academia.stackexchange.com/questions/17781/why-do-many-talented-scientists-write-horrible-software). Every "pure" software engineer knows that: behind a brilliant researcher an awful programmer is hidden, and I don't want to be the janitor cleaning after him/her.
Is that an acceptable request? If so, how can I motivate it without sounding rude?
This question already has an answer here:
How can I ask a potential employer to show production code?
11 answers
interviewing software-industry communication job-offer
edited Apr 13 '17 at 12:49
Community♦
1
1
asked Mar 20 '15 at 20:11
guest
321
321
marked as duplicate by Telastyn, Chris E, gnat, Elysian Fields♦ Mar 21 '15 at 16:18
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Telastyn, Chris E, gnat, Elysian Fields♦ Mar 21 '15 at 16:18
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
2
I'm not sure how helpful the internet is going to be here. The only way you're going to find out is by asking them. It doesn't sound unreasonable to me. If I were the company, I would probably ask you to come in to the office instead of sending you anything.
– Bowen
Mar 20 '15 at 20:19
2
And one sample tells you nothing about how their other people code. Besides the question of whether they want to show you anything significant without a signed NDA, though that might be manageable. Basically, I think the answer is going to be that cleaning up others mistakes is always an implied part of the job, and making too much stink about that is a good way to get invited to apply elsewhere. Tl;dr: you can always ask, but you may not like their answer or their reaction.
– keshlam
Mar 20 '15 at 20:41
6
THAAAT's the attitude companies want new hires to show up with </sarcasm>. Did you consider that maybe the reason they want to hire a "pure" software engineer is to bring good practices to their company? Besides, this is a question you should have asked in the interview.
– Wesley Long
Mar 20 '15 at 20:57
3
@NathanCooper - "Good Enough" isn't the issue. As an engineer (whatever discipline), you are being hired to solve problems. No one said "Drop to your knees," but if you're such a prima-donna that you aren't willing to tackle a funky codebase, I'd be careful about calling yourself an "Engineer." The question of whether or not the position will have the authority to correct the funkiness is entirely appropriate, however.
– Wesley Long
Mar 20 '15 at 21:18
1
I suspect keshlam is right. It's unfortunate that this wasn't part of the interview. But I'm sure you could reach out to them and get some time to look at the code, the problem's they're solving and get a sense of your colleagues. I'm sure this company has no interest in hiring someone who doesn't want to work on the codebase.
– Nathan Cooper
Mar 20 '15 at 21:18
 |Â
show 5 more comments
2
I'm not sure how helpful the internet is going to be here. The only way you're going to find out is by asking them. It doesn't sound unreasonable to me. If I were the company, I would probably ask you to come in to the office instead of sending you anything.
– Bowen
Mar 20 '15 at 20:19
2
And one sample tells you nothing about how their other people code. Besides the question of whether they want to show you anything significant without a signed NDA, though that might be manageable. Basically, I think the answer is going to be that cleaning up others mistakes is always an implied part of the job, and making too much stink about that is a good way to get invited to apply elsewhere. Tl;dr: you can always ask, but you may not like their answer or their reaction.
– keshlam
Mar 20 '15 at 20:41
6
THAAAT's the attitude companies want new hires to show up with </sarcasm>. Did you consider that maybe the reason they want to hire a "pure" software engineer is to bring good practices to their company? Besides, this is a question you should have asked in the interview.
– Wesley Long
Mar 20 '15 at 20:57
3
@NathanCooper - "Good Enough" isn't the issue. As an engineer (whatever discipline), you are being hired to solve problems. No one said "Drop to your knees," but if you're such a prima-donna that you aren't willing to tackle a funky codebase, I'd be careful about calling yourself an "Engineer." The question of whether or not the position will have the authority to correct the funkiness is entirely appropriate, however.
– Wesley Long
Mar 20 '15 at 21:18
1
I suspect keshlam is right. It's unfortunate that this wasn't part of the interview. But I'm sure you could reach out to them and get some time to look at the code, the problem's they're solving and get a sense of your colleagues. I'm sure this company has no interest in hiring someone who doesn't want to work on the codebase.
– Nathan Cooper
Mar 20 '15 at 21:18
2
2
I'm not sure how helpful the internet is going to be here. The only way you're going to find out is by asking them. It doesn't sound unreasonable to me. If I were the company, I would probably ask you to come in to the office instead of sending you anything.
– Bowen
Mar 20 '15 at 20:19
I'm not sure how helpful the internet is going to be here. The only way you're going to find out is by asking them. It doesn't sound unreasonable to me. If I were the company, I would probably ask you to come in to the office instead of sending you anything.
– Bowen
Mar 20 '15 at 20:19
2
2
And one sample tells you nothing about how their other people code. Besides the question of whether they want to show you anything significant without a signed NDA, though that might be manageable. Basically, I think the answer is going to be that cleaning up others mistakes is always an implied part of the job, and making too much stink about that is a good way to get invited to apply elsewhere. Tl;dr: you can always ask, but you may not like their answer or their reaction.
– keshlam
Mar 20 '15 at 20:41
And one sample tells you nothing about how their other people code. Besides the question of whether they want to show you anything significant without a signed NDA, though that might be manageable. Basically, I think the answer is going to be that cleaning up others mistakes is always an implied part of the job, and making too much stink about that is a good way to get invited to apply elsewhere. Tl;dr: you can always ask, but you may not like their answer or their reaction.
– keshlam
Mar 20 '15 at 20:41
6
6
THAAAT's the attitude companies want new hires to show up with </sarcasm>. Did you consider that maybe the reason they want to hire a "pure" software engineer is to bring good practices to their company? Besides, this is a question you should have asked in the interview.
– Wesley Long
Mar 20 '15 at 20:57
THAAAT's the attitude companies want new hires to show up with </sarcasm>. Did you consider that maybe the reason they want to hire a "pure" software engineer is to bring good practices to their company? Besides, this is a question you should have asked in the interview.
– Wesley Long
Mar 20 '15 at 20:57
3
3
@NathanCooper - "Good Enough" isn't the issue. As an engineer (whatever discipline), you are being hired to solve problems. No one said "Drop to your knees," but if you're such a prima-donna that you aren't willing to tackle a funky codebase, I'd be careful about calling yourself an "Engineer." The question of whether or not the position will have the authority to correct the funkiness is entirely appropriate, however.
– Wesley Long
Mar 20 '15 at 21:18
@NathanCooper - "Good Enough" isn't the issue. As an engineer (whatever discipline), you are being hired to solve problems. No one said "Drop to your knees," but if you're such a prima-donna that you aren't willing to tackle a funky codebase, I'd be careful about calling yourself an "Engineer." The question of whether or not the position will have the authority to correct the funkiness is entirely appropriate, however.
– Wesley Long
Mar 20 '15 at 21:18
1
1
I suspect keshlam is right. It's unfortunate that this wasn't part of the interview. But I'm sure you could reach out to them and get some time to look at the code, the problem's they're solving and get a sense of your colleagues. I'm sure this company has no interest in hiring someone who doesn't want to work on the codebase.
– Nathan Cooper
Mar 20 '15 at 21:18
I suspect keshlam is right. It's unfortunate that this wasn't part of the interview. But I'm sure you could reach out to them and get some time to look at the code, the problem's they're solving and get a sense of your colleagues. I'm sure this company has no interest in hiring someone who doesn't want to work on the codebase.
– Nathan Cooper
Mar 20 '15 at 21:18
 |Â
show 5 more comments
2 Answers
2
active
oldest
votes
up vote
9
down vote
It may be difficult to ask this question without appearing to be rude or arrogant. You run the risk of poisoning the well if you ask the founders of the company to prove their competence at the very start of the relationship.
Let's say you're the hiring manager in a similar organization. What would you think of this request? If you consider what it implies about your day-to-day interactions with the employee for years into the future, would you want to have the person who made it on your team? Think carefully about these things when wording your question (or deciding whether to ask it).
If you decide to go forward with asking your question, you should phrase it as wanting to make sure your skills are a good fit for the existing code base, and not that you're worried about having to clean up someone's mess.
I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be
– Richard Tingle
Mar 24 '15 at 12:40
suggest improvements |Â
up vote
4
down vote
If you had warranted suspicions about the codebase being "pure junk", the time to probe that is during the interview process. It is perfectly fine to ask to sit down with someone and get a "code tour" and you could then ask pointed questions and see where things stand. I've actually done this myself more than once (although I consider myself to be on the domain side rather than dev side). The thing I learned from it, however, is that the codebase is FAR LESS important than the people you would be working with.
I would much rather have a crappy codebase and really mindful/creative team that is open to new ideas than a tight codebase with 'holes running the show.
Waiting until the offer comes and then having cold feet means that you haven't thought this through. It is OK to get second thoughts, but be up front about them to yourself rather than try to ascribe it all to "the codebase" just so that you can hold something in your hands that you can use to confirm your feelings.
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
9
down vote
It may be difficult to ask this question without appearing to be rude or arrogant. You run the risk of poisoning the well if you ask the founders of the company to prove their competence at the very start of the relationship.
Let's say you're the hiring manager in a similar organization. What would you think of this request? If you consider what it implies about your day-to-day interactions with the employee for years into the future, would you want to have the person who made it on your team? Think carefully about these things when wording your question (or deciding whether to ask it).
If you decide to go forward with asking your question, you should phrase it as wanting to make sure your skills are a good fit for the existing code base, and not that you're worried about having to clean up someone's mess.
I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be
– Richard Tingle
Mar 24 '15 at 12:40
suggest improvements |Â
up vote
9
down vote
It may be difficult to ask this question without appearing to be rude or arrogant. You run the risk of poisoning the well if you ask the founders of the company to prove their competence at the very start of the relationship.
Let's say you're the hiring manager in a similar organization. What would you think of this request? If you consider what it implies about your day-to-day interactions with the employee for years into the future, would you want to have the person who made it on your team? Think carefully about these things when wording your question (or deciding whether to ask it).
If you decide to go forward with asking your question, you should phrase it as wanting to make sure your skills are a good fit for the existing code base, and not that you're worried about having to clean up someone's mess.
I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be
– Richard Tingle
Mar 24 '15 at 12:40
suggest improvements |Â
up vote
9
down vote
up vote
9
down vote
It may be difficult to ask this question without appearing to be rude or arrogant. You run the risk of poisoning the well if you ask the founders of the company to prove their competence at the very start of the relationship.
Let's say you're the hiring manager in a similar organization. What would you think of this request? If you consider what it implies about your day-to-day interactions with the employee for years into the future, would you want to have the person who made it on your team? Think carefully about these things when wording your question (or deciding whether to ask it).
If you decide to go forward with asking your question, you should phrase it as wanting to make sure your skills are a good fit for the existing code base, and not that you're worried about having to clean up someone's mess.
It may be difficult to ask this question without appearing to be rude or arrogant. You run the risk of poisoning the well if you ask the founders of the company to prove their competence at the very start of the relationship.
Let's say you're the hiring manager in a similar organization. What would you think of this request? If you consider what it implies about your day-to-day interactions with the employee for years into the future, would you want to have the person who made it on your team? Think carefully about these things when wording your question (or deciding whether to ask it).
If you decide to go forward with asking your question, you should phrase it as wanting to make sure your skills are a good fit for the existing code base, and not that you're worried about having to clean up someone's mess.
answered Mar 20 '15 at 21:18
Roger
7,17132644
7,17132644
I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be
– Richard Tingle
Mar 24 '15 at 12:40
suggest improvements |Â
I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be
– Richard Tingle
Mar 24 '15 at 12:40
I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be
– Richard Tingle
Mar 24 '15 at 12:40
I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be
– Richard Tingle
Mar 24 '15 at 12:40
suggest improvements |Â
up vote
4
down vote
If you had warranted suspicions about the codebase being "pure junk", the time to probe that is during the interview process. It is perfectly fine to ask to sit down with someone and get a "code tour" and you could then ask pointed questions and see where things stand. I've actually done this myself more than once (although I consider myself to be on the domain side rather than dev side). The thing I learned from it, however, is that the codebase is FAR LESS important than the people you would be working with.
I would much rather have a crappy codebase and really mindful/creative team that is open to new ideas than a tight codebase with 'holes running the show.
Waiting until the offer comes and then having cold feet means that you haven't thought this through. It is OK to get second thoughts, but be up front about them to yourself rather than try to ascribe it all to "the codebase" just so that you can hold something in your hands that you can use to confirm your feelings.
suggest improvements |Â
up vote
4
down vote
If you had warranted suspicions about the codebase being "pure junk", the time to probe that is during the interview process. It is perfectly fine to ask to sit down with someone and get a "code tour" and you could then ask pointed questions and see where things stand. I've actually done this myself more than once (although I consider myself to be on the domain side rather than dev side). The thing I learned from it, however, is that the codebase is FAR LESS important than the people you would be working with.
I would much rather have a crappy codebase and really mindful/creative team that is open to new ideas than a tight codebase with 'holes running the show.
Waiting until the offer comes and then having cold feet means that you haven't thought this through. It is OK to get second thoughts, but be up front about them to yourself rather than try to ascribe it all to "the codebase" just so that you can hold something in your hands that you can use to confirm your feelings.
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
If you had warranted suspicions about the codebase being "pure junk", the time to probe that is during the interview process. It is perfectly fine to ask to sit down with someone and get a "code tour" and you could then ask pointed questions and see where things stand. I've actually done this myself more than once (although I consider myself to be on the domain side rather than dev side). The thing I learned from it, however, is that the codebase is FAR LESS important than the people you would be working with.
I would much rather have a crappy codebase and really mindful/creative team that is open to new ideas than a tight codebase with 'holes running the show.
Waiting until the offer comes and then having cold feet means that you haven't thought this through. It is OK to get second thoughts, but be up front about them to yourself rather than try to ascribe it all to "the codebase" just so that you can hold something in your hands that you can use to confirm your feelings.
If you had warranted suspicions about the codebase being "pure junk", the time to probe that is during the interview process. It is perfectly fine to ask to sit down with someone and get a "code tour" and you could then ask pointed questions and see where things stand. I've actually done this myself more than once (although I consider myself to be on the domain side rather than dev side). The thing I learned from it, however, is that the codebase is FAR LESS important than the people you would be working with.
I would much rather have a crappy codebase and really mindful/creative team that is open to new ideas than a tight codebase with 'holes running the show.
Waiting until the offer comes and then having cold feet means that you haven't thought this through. It is OK to get second thoughts, but be up front about them to yourself rather than try to ascribe it all to "the codebase" just so that you can hold something in your hands that you can use to confirm your feelings.
answered Mar 20 '15 at 22:15
teego1967
10.3k42845
10.3k42845
suggest improvements |Â
suggest improvements |Â
2
I'm not sure how helpful the internet is going to be here. The only way you're going to find out is by asking them. It doesn't sound unreasonable to me. If I were the company, I would probably ask you to come in to the office instead of sending you anything.
– Bowen
Mar 20 '15 at 20:19
2
And one sample tells you nothing about how their other people code. Besides the question of whether they want to show you anything significant without a signed NDA, though that might be manageable. Basically, I think the answer is going to be that cleaning up others mistakes is always an implied part of the job, and making too much stink about that is a good way to get invited to apply elsewhere. Tl;dr: you can always ask, but you may not like their answer or their reaction.
– keshlam
Mar 20 '15 at 20:41
6
THAAAT's the attitude companies want new hires to show up with </sarcasm>. Did you consider that maybe the reason they want to hire a "pure" software engineer is to bring good practices to their company? Besides, this is a question you should have asked in the interview.
– Wesley Long
Mar 20 '15 at 20:57
3
@NathanCooper - "Good Enough" isn't the issue. As an engineer (whatever discipline), you are being hired to solve problems. No one said "Drop to your knees," but if you're such a prima-donna that you aren't willing to tackle a funky codebase, I'd be careful about calling yourself an "Engineer." The question of whether or not the position will have the authority to correct the funkiness is entirely appropriate, however.
– Wesley Long
Mar 20 '15 at 21:18
1
I suspect keshlam is right. It's unfortunate that this wasn't part of the interview. But I'm sure you could reach out to them and get some time to look at the code, the problem's they're solving and get a sense of your colleagues. I'm sure this company has no interest in hiring someone who doesn't want to work on the codebase.
– Nathan Cooper
Mar 20 '15 at 21:18