8 ms·

This question can be fine addressesd and be done with in 10 seconds. If you cannot answer this positively quickly I'd doubt your ability to ship a product (lon

This question can be fine addressesd and be done with in 10 seconds. If you cannot answer this positively quickly I'd doubt your ability to ship a product (long-term). Especially the remark about " obsessing on code/process quality can be useful" .. erm, asking about source control is not obsessing about code/process, it is the bare minimum and more to me like e.g. ask my future truck employer if their trucks have seatbelts.. tbh if I'd hear that from the guy that runs a small startup I'd run .. and that's good, people are different.

sumtechguy 4y ago
"we sometimes check things into sourcesafe but usually keep it on jims computer" That was 3-4 years ago. From a company that was in no way a 'startup'. That tells me they have no release system at all other than the late 80s crowd around a 'blessed' computer and hope it builds right. "have you considered git, svn, perforce anything like that?" "we don't have time for that" That tells me they do not have time to invest in having a good reliable thing for themselves. It tells me that as a developer I will not have any time to fix recurring issues. It is a question you can learn a lot from. Because it is something the developers do day to day. These are not new concepts. These are table stakes at this point. We were doing this sort of thing in the mid 90s. If you are not doing them. You are missing out on some cool debugging/regression/qa tools.
jon-wood 4y ago
I would (and do, when interviewing candidates on the other side of the table) frame this differently. I can more or less assume that a candidate at the level we're hiring has used git, and done some form of code review, so I don't bother asking that particular question. What I do get into is their approach to code review, how they go about handling a pull request, how they'd provide feedback to the submitter, and what particular red flags they're looking for when reviewing code. I indirectly also find out if a candidate hasn't used git, or done code review, but much more usefully I find out whether they're the sort of person who's going to take a quick glance and then throw a "lgtm" comment on the PR, or if they're actually going to review things.

sumtechguy 4y ago

"we sometimes check things into sourcesafe but usually keep it on jims computer" That was 3-4 years ago. From a company that was in no way a 'startup'. That tells me they have no release system at all other than the late 80s crowd around a 'blessed' computer and hope it builds right. "have you considered git, svn, perforce anything like that?" "we don't have time for that" That tells me they do not have time to invest in having a good reliable thing for themselves. It tells me that as a developer I will not have any time to fix recurring issues. It is a question you can learn a lot from. Because it is something the developers do day to day. These are not new concepts. These are table stakes at this point. We were doing this sort of thing in the mid 90s. If you are not doing them. You are missing out on some cool debugging/regression/qa tools.

jon-wood 4y ago

I would (and do, when interviewing candidates on the other side of the table) frame this differently. I can more or less assume that a candidate at the level we're hiring has used git, and done some form of code review, so I don't bother asking that particular question. What I do get into is their approach to code review, how they go about handling a pull request, how they'd provide feedback to the submitter, and what particular red flags they're looking for when reviewing code. I indirectly also find out if a candidate hasn't used git, or done code review, but much more usefully I find out whether they're the sort of person who's going to take a quick glance and then throw a "lgtm" comment on the PR, or if they're actually going to review things.