Re:Technical Interviews at a Startup
by revorad on Saturday January 07, 2012 @02:59PM
(#3437922)
I interviewed with Tom's startup last week. I was impressed by the business logic questions. If you're looking for a job in London, you should apply there. They are a great bunch of hackers working on very interesting stuff.
Re:Technical Interviews at a Startup
by jt2190 on Saturday January 07, 2012 @04:31PM
(#3438123)
Part of me always balks when a company recommends using GitHub to share code with them. Don't get me wrong, I love GitHub, but posting code using a GitHub free account means you must also open source it. Or perhaps the project you contributed to doesn't host their source with GitHub.
I'd prefer it if they'd just say, "send us a sample of your work, or a link to your source online."
Re:Technical Interviews at a Startup
by xxqs on Saturday January 07, 2012 @05:58PM
(#3438291)
if the software is non-open-source, sending a sample may violate NDA and licensing.
in regards to Github, if Git is used already in the company's development process, the candidate would need to show that he or she is familiar with Git. Then Github is the first destination to show that. On the other hand, of course there are plenty of other Git hosting opportunities -- sourceforge, for example.
Re:Technical Interviews at a Startup
by georgemcbay on Saturday January 07, 2012 @06:26PM
(#3438363)
jt2190's post suggests the user is posting his/her own code, but not necessarily wanting to open source it to the world. If the code is yours, NDA and licensing are irrelevant in that situation.
"if Git is used already in the company's development process, the candidate would need to show that he or she is familiar with Git"
Any company that requires a potential hire to be familiar with their current source control system is an insanely stupid organization.
Re:Technical Interviews at a Startup
by xxqs on Saturday January 07, 2012 @06:32PM
(#3438380)
well, Git mastering requires time for training, and this involves additional costs. Besides, seeing how someone organizes their work in branches is a good help in understanding the developer's culture. The quality of commits is also quite important: granularity, good descriptions, focus -- all these things would be easier to learn from a public Git repository before making the hiring decision.
Re:Technical Interviews at a Startup
by xxqs on Sunday January 08, 2012 @01:47AM
(#3439047)
ok, let's rephrase it: If Git is in use and the candidate has experience with it, it's a benefit for both parties, and can influence the hiring decision
Re:Technical Interviews at a Startup
by therandomguy on Saturday January 07, 2012 @06:25PM
(#3438361)
Good post. Personally I would refuse to share my past code. Honest question: Would you be willing to share your code with the interviewee so that try can determine if they want to join you?
Re:Technical Interviews at a Startup
by tomblomfield on Sunday January 08, 2012 @06:00AM
(#3439309)
We'd absolutely be happy to share (parts) our code, and often do.
I've heard other companies give prospective employees a week-long project on a consultancy basis - I think this is a great method of determining if there's a mutual fit. Unfortunately, it's a bit unrealistic to expect most candidates to be able to drop current commitments for a week.
Re:Technical Interviews at a Startup
by tomblomfield on Saturday January 07, 2012 @02:27PM
(#3437841)
OP here. I'd love to how other startups run technical interviews - particularly when you're interviewing for roles that are outside your area of expertise.
Re:Technical Interviews at a Startup
by xxqs on Saturday January 07, 2012 @02:37PM
(#3437870)
I think the best would be to find a consultant with the required expertise to run such interviews.
I've been at two on-site interviews at Google, and that was the most exciting experience, especially the first time. Now I know how proper technical interviews should be done. In general, I realized how much more I'm able to do, compared to what I was doing at my place of work.
The general approach is to figure out how the candidate is able to think in a structured and analytical way. It doesn't matter if the candidate doesn't know something -- much more important is to see how he or she is developing the answers during the interview. Of course, the questions should also allow such freedom.
Also useful, is not to ask for definitions of something, but for difference: how A differs from B and why? Then you clearly see if the candidate understands what's behind it, even if they have forgotten some little details.
Re:Technical Interviews at a Startup
by tomblomfield on Saturday January 07, 2012 @03:36PM
(#3438012)
I'm always wary of consultants - we've had some really bad experiences using recruitment consultants.
I absolutely agree that the main aim of an interview is to determine if a candidate is able to think in a structured and analytical way. I'm much more interested in talking about situations when you might choose UDP over TCP, rather than being able to recite the details of a particular HTTP specification
Re:Technical Interviews at a Startup
by aen1 on Saturday January 07, 2012 @05:05PM
(#3438186)
Sadly enough, I've been ask the UDP/TCP question many times, so I have a good answer, though I have never studied either in depth. So, in theory that would be a great question. But, it is asked too often to really be of any use.
Re:Technical Interviews at a Startup
by xxqs on Saturday January 07, 2012 @05:11PM
(#3438195)
actually a great interview question is what happens when you click a link in the browser. All the steps down to how deep you understand it: through the kernel calls, DNS packets, ARP, Ethernet frames, IP routing, TCP acknowledgements, HTTP headers, MIME types, and so on.
Re:Technical Interviews at a Startup
by xxqs on Sunday January 08, 2012 @01:46AM
(#3439045)
nope, this is all about understanding the logic and how the system components interact with each other.
Besides, you can dig deeper in any direction, depending on the candidate profile. For a network engineer, understanding on the packet level is important. For a web programmer, the interaction between server and client is important (HTTP headers, MIME types etc, webserver scalability etc.). For a sysadmin, understanding of processes and interaction of applications and OS is important. All those can be derived just from a simple question -- what happens when you click on a link
Re:Technical Interviews at a Startup
by tomblomfield on Sunday January 08, 2012 @06:02AM
(#3439312)
I agree - you can memorise answers on a fairly generic level, but digging deeper in a relevant area, or talking about edge cases, exposes whether a person really understands what's going on.
I'd prefer it if they'd just say, "send us a sample of your work, or a link to your source online."
in regards to Github, if Git is used already in the company's development process, the candidate would need to show that he or she is familiar with Git. Then Github is the first destination to show that. On the other hand, of course there are plenty of other Git hosting opportunities -- sourceforge, for example.
"if Git is used already in the company's development process, the candidate would need to show that he or she is familiar with Git"
Any company that requires a potential hire to be familiar with their current source control system is an insanely stupid organization.
Not if it's my code. I shouldn't have to open source my own code just to show it.
at the moment I rent a minimalist VPS for about $35 a year and use gitolite to organise my private repos. Works perfectly so far :)
I've heard other companies give prospective employees a week-long project on a consultancy basis - I think this is a great method of determining if there's a mutual fit. Unfortunately, it's a bit unrealistic to expect most candidates to be able to drop current commitments for a week.
for a company, I don't see a problem to show some project internals under NDA
I've been at two on-site interviews at Google, and that was the most exciting experience, especially the first time. Now I know how proper technical interviews should be done. In general, I realized how much more I'm able to do, compared to what I was doing at my place of work.
The general approach is to figure out how the candidate is able to think in a structured and analytical way. It doesn't matter if the candidate doesn't know something -- much more important is to see how he or she is developing the answers during the interview. Of course, the questions should also allow such freedom.
Also useful, is not to ask for definitions of something, but for difference: how A differs from B and why? Then you clearly see if the candidate understands what's behind it, even if they have forgotten some little details.
I absolutely agree that the main aim of an interview is to determine if a candidate is able to think in a structured and analytical way. I'm much more interested in talking about situations when you might choose UDP over TCP, rather than being able to recite the details of a particular HTTP specification
Besides, you can dig deeper in any direction, depending on the candidate profile. For a network engineer, understanding on the packet level is important. For a web programmer, the interaction between server and client is important (HTTP headers, MIME types etc, webserver scalability etc.). For a sysadmin, understanding of processes and interaction of applications and OS is important. All those can be derived just from a simple question -- what happens when you click on a link
besides, you can silently participate in the interview, or review the sound recording afterwards.