6 ms·

I'm responsible for hiring developers at our company based in Berlin, Germany, and found it best to have a guided interview about the candidate's work experienc

by jonasvp 10y ago

I'm responsible for hiring developers at our company based in Berlin, Germany, and found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. I never understood the whiteboard hazing/CS trivia that are so widely discussed on HN since it seems extremely disconnected from the actual work that's being done. That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of. We worked with an HR consultant to develop a interview guide in the form of certain questions that we make sure to hit during the interview in order to be able to compare between candidates and make an informed decision. However, we're small and not in the US. Anyone have experience with other companies in Germany/Europe? How does the typical interview work over here?

lj3 10y ago
> found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. This. I advocate this method of interviewing here in the states every chance I get. The most common form of push back I get is from hiring managers terrified of being hoodwinked into making a bad hire. It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game. > I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of Junior engineers, I assume? I had problems with those questions when I first started out. It's hard to say with a straight face that the thing I was most proud of at that point in my career was creating a very simple templating system in PHP. Of course, the interviewers rolling their eyes and saying 'is that all?' didn't help.
- jonasvp 10y ago
  > It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game. Which is usually the case in larger companies, I assume. The person doing the hiring in that case is far removed from the people and work actually connected with the candidate. > Junior engineers, I assume? You're right, that's surely part of it. Not only, however - sometimes you get the feeling that work is something that happens to people, not something they seek out and try to get better at. Which for many positions is completely fine.
- _pmf_ 10y ago
  > Of course, the interviewers rolling their eyes and saying 'is that all?' didn't help. That says a lot about their maturity, not yours.
fsloth 10y ago
"found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. " When I've been job hunting in the past I've also found that these have been the best situations for me. I find coding questions beyond fizbuzz totally silly and when something more is requested of me my attitude shows this.
nherment 10y ago
We're in Denmark and currently hiring. I'm not sure why there is such extreme hate for the whiteboard. Yes it has plenty of caveats when it comes to actual coding and recruiters should not expect any candidate to write precise code on that medium. I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal. Candidates have the option to use my laptop (not ideal because the keyboard has a US layout) but they are welcome to use their own computer as well (if they thought about bringing it). It weeds out candidates who can't even produce basic code. And yes, a candidate with 2+ years of experience should be able to write a basic function on a whiteboard, a napkin, or whatever. If not, the interview is not lost but the candidate will have to prove his skills another way. For most candidates, we also give a longer technical test which is to be done at home and takes 2 to 4 hours to complete. Candidates are given as many days as they want to complete it. Whiteboard is an excellent medium however when discussing architecture and higher level ideas. It's also a tool that I've used during day to day activities with colleagues. Software based tools don't come even close.
- jonasvp 10y ago
  Interesting! I actually love using the whiteboard to sketch solutions and architectural decisions. I believe the hate comes from having to code on a whiteboard - which is justified, since no one ever coded on a whiteboard except in an interview.
- muse900 10y ago
  I believe the hate comes from unprecedented and hard CS questions asked on the whiteboard. I recently went to an interview that asked me to balance a binary tree on a whiteboard. It can be done, and I can do it. Thing is when you go to interview for that company that has 2 developers(small team, small company) and ask you that kind of question it puts you off thinking that those guys won't be great to work with (arrogance etc comes in mind). I am fond of simpler questions, like you said fizzbuz etc. Obviously if you are interviewing a guy that has 2+ years of experience, he has to be able to pass the fizzbuzz test. When you are interviewing someone with 5+ years of experience for a higher up position I guess you do have to ask some harder question, but I personally think just speaking to the guy and asking him stuff about his past projects etc will give you a hint on if he has the skills he is talking about or not. Asking him to outline a hard task he took part and how he solved it is an amazing start. As a 5+ years guy personally would rumble about a few things and it would take me days talking about them. (That will give you an understanding if I've worked before or not on the things outlined on my CV).
napoleoncomplex 10y ago
Also from Europe, and we have a similar approach, discussion with the candidate about previous work, interesting problems, any public code they've written, etc. Just to figure out what kind of challenges excite them, and get to know them better. We also do a coding challenge after that, basically the candidate behind a computer, with all the resources they want accessible to them, implementing a simple example directly relevant to the type of work they'll be doing, while the interviewers are in the room and debate with them if needed. To me, the most important quality in a candidate, once we determine that the basic skill level is good enough, is their ability to learn, quickly find the resources needed, and rely on the team when they need help. Whiteboard interviews don't seem to select for any of those qualities.
bbcbasic 10y ago
> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of. I have trouble recalling the details of things I worked on even say a week ago sometimes. I also don't find most of the work I do that interesting as I've been coding along time solving the same kinds of problems. However to play the game i would of course brush up for questions like that, and be quite convincing.
- sgift 10y ago
  > I have trouble recalling the details of things I worked on even say a week ago sometimes. No problem here, it probably wasn't very exciting but have you never encountered something which stuck in your mind? Or that you could at least recall some part of a project if someone asked "So, you've written here that you've worked on project xy and did this and that, can you tell us a bit more about it"?
  - pm215 10y ago
    Asking about project xy is different though, it's more guided. I think it's much easier to answer than the really open ended ones that ask you to pick an incident from all 10-15 years of your work history: the field there is so wide that unless I've specifically considered the question in advance I'm likely to sit there going ummm for a bit. In general I think the question format favours people with a good memory for anecdotes and story telling ability.
et-al 10y ago
> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of. It could be that this technique favors people good at telling stories. Personally, I'm a horrible storyteller. If you were to ask me what I did over the weekend, I'll offer some facts like "oh, went swimming in a river and Bob lost his hat, but we found it later. The water was nice." Whereas Bob could easily regale you with stories about the epic hunt for his hat and throw in a punchline in the end. If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for. But if given the choice between speaking about myself or whiteboarding, I'll take the whiteboard. I've always preferred math over history for that matter. It's easier for some of us to apply processes than to recite chronologies.
- jonasvp 10y ago
  Good point. When I notice that people are struggling with finding something, I usually just pick one thing from the resume and try to go more in depth about that.
  - et-al 10y ago
    You sound like a good interviewer that adjusts to each candidate. I wish more interviewers would learn the importance of this.
- pmiller2 10y ago
  Or, they just don't find the work terribly exciting. There's a lot of unexciting work to be done in software, and somebody has to do it.
  - rtpg 10y ago
    There's definitely an industry bias towards "programmers as artists". If you don't love your work with a passion you're seen as less good. It's an alright proxy for other things, but there's a ton of good developers that leave their ego at the door, and their work at work.
zerr 10y ago
> one solution that they're proud of. Pride is a very strong word, especially for those of us with impostor syndrome...
- _pmf_ 10y ago
  The things I'm proudest about are the things I should probably not be proud of at all as a responsible professional.
andrewingram 10y ago
Generally speaking, someone's ability to recall things is very dependent on how they're feeling. If you're happy, it's easy to recall positive things, if you're depressed it's practically impossible. A lot of developers also have imposter syndrome. After I've solved an interesting problem, within a few days i'll probably have dismissed it as not being a big deal and started to forget about it. These kind of questions are useful, but candidates should be preparing their talking points, because the risk of forgetting the story that's going to get you hired is too high
- mdpopescu 10y ago
  Yes. I read about this idea a few years ago (tell a story about a project you liked) so I had to make an effort to focus on ONE story and tell it well. I've been doing it a couple dozen times so far (I'm a contractor who likes small projects, six months is starting to get too long) and I've had significant success with it. (When I think about the problem "objectively", all I did was use SSDT to simplify deploying database changes from QA to production without having to shut down either. No big deal. However, it was something that the company had been doing manually for years, spending three error-prone days each month, and they were extremely happy with my solution.)
atirip 10y ago
We are currently hiring. Denmark. We received i think few hundreds applications, picked 20, discussed internally, picked 5. Those 5 received invitation for homework, simple functional Javascript exercise. We dropped 2, the rest received invitation for UI Javascript exercise, vanilla btw. Then we talked with them. Picked one. In my previous gig in UK we had 3 homeworks and then chat. Sometimes we did drop the third when candidate was exceptional. So far only one candidate refused homework next stage, but the first stage result was bad enough for us to not consider him anyway. All top candidates and hires were eager to do the homework.
cmollis 10y ago
So true.. and this is a great interviewing technique. I basically ask one question during an interview: what was the hardest problem you ever had to solve? It may sound stupid at first glance, but it gives you insight into not only the breadth of their technical knowledge (since that problem may not be germane to the position you're hiring for), but also the depth of their abilities. The way they answer this question reveals quite a bit about the person. Not only technical, but also their interpersonal abilities.. how they manage their place on a team, how they manage expectations up and below, etc. I can glean quite a bit about the person based on how they answer this one question. Only asking questions about your particular domain doesn't necessarily indicate how good they'll be at solving those types of problems, only how much they happen to know about them. Of course, you can say that perhaps they shouldn't be interviewing for a position they may not be qualified for, but frankly the best people I've ever hired had very little experience in problem sets that were specific to my day-to-day responsibilities, but delving into details about things that they've done told me a great deal about how they solve anything. It may not be the best way to hire, because it requires a breadth of technical knowledge of the interviewer, but it definitely has worked for me. Asking someone to solve a ridiculous puzzle on a whiteboard..when they're obviously nervous about being there in the first place seems kind of dumb to me. However, digging into a problem that they've solved immediately puts them at ease.
- AgentIcarus 10y ago
  I'm not a huge fan of this question. I've been programming for 20 years (professionally for 13). Is the hardest problem some noddy maths i worked out at 15 to convert real coordinates to screen coordinates? Is it the first app i wrote out of college when i learned that servlets aren't thread safe? Is it what i worked on last year to design my current company's authentication/authorization system? I find it very hard to interpolate between these examples. And none of them are "hard"! I haven't written an OS or a more efficient linked list. All I've done is plugged away at something until it works.
ergothus 10y ago
Interesting. I've done a fair number of interviews for my last few companies, and while I've found that whiteboarding isn't terribly useful, likewise I've found that I really do need people to do some coding. I've definitely encountered people that talk a great story but don't have the chops behind a keyboard. My usual process (which isn't to say it's perfect, but it's a process I regularly edit to address problems I see) is to give a few, simple problems, and have them actually code it on a system. * I know that the computer and environment are unfamiliar to you, so I expect there to be chopiness and typos * I know that most people are nervous during interviews, so I don't fail people if they freeze on one of the questions or miss a concept * I don't give "trivia" questions - the problems tend to be fairly easy ones that cover your ability to approach basic problems. Example: "here is a nested data structure (like an array of objects). Write a method to pull these sorts of elements out." * I'm actually hoping you'll screw up - I'm far more interested in seeing how you deal with a bug than if you can dash out an algorithm flawlessly. Nonetheless, I keep the questions simple because I want to minimize the impact of nervousness * I inform people they are absolutely allowed to use Google, StackOverflow, etc - I'm trying to mimic the actual work experience as much as I can. I WILL judge people on their searches, but I'm pretty loose - I can only recall one person that I dinged for searching, and that's because they went to about.com and copied the answer there without trying to understand it (and it subsequently didn't work). Usually this ends up GIVING people points, because if they demonstrate comfort with finding solutions, I expect that we can hire them and know they'll improve over time. Despite this, I still ask a few questions that are purely verbal. I want to see if you are someone that will force your preferences on others or are willing to bend. (I'm not looking for a doormat, but I've never met one, so that's a bit moot) I want to see that you are continuing to learn things, because the skills you have now will just not be the skills we need in a year or two. but overall - I have to judge candidates based on the limited info I can glean in an interview. Of: * resume * whiteboarding skills * discussion skills * coding skills ...I find the latter to be the best measurement of the options, even allowing that it won't be fully accurate.
segner 9y ago
Hi JonasVP, a little late but regarding your original question... We were building a tech team at a start-up in Germany. Our hiring process evolved and stabilized into the following process, which worked exceptionally well for us: 1. Review of written documents, accepting any kind, any style and any medium. 2. Telephone interview with recruiter from HR about motivation, personality and the formal aspects of education and experience. 3. Personal interview with VP of engineering. Future employee is asked to bring some of his or her source code to the interview, any language any style any form is good. We don't copy the code, we don't keep it, we don't use it in any way. This is the only technical interview. 4. Interview with the CTO, immediately following. This is the most important social interview, and it also contains the main salary negotiation. 5. Decision. Between any of the steps, we would briefly exchange our impression of the candidate, and it turned out that it is wise to sleep a night before taking the decision. My function was VP of engineering and lead architect, and I would conduct the interviews of step 3. My principles are as follows: - Keep the candidate at ease as much as possible. We want developers to crack hard problems with "feet on the table" as the Dutch say, most of the time. Stress distorts things, and I want to see the undistorted version. - Get to know the candidate, and what makes him or her tick. This requires respect, tact and genuine interest in the person and his or her achievements. - Estimate the fit with team and company. I can talk a lot about this---but in the end it either feels right or it does not. - Gauge the technical capabilities of the candidate. For this I let the candidate choose a piece of the source code at will and have her explain what it does, and why it is the way it is. For all our hires, some form of dialog on software architecture in general emerged. This usually takes between 10-30 minutes. - Do your best to get the candidate interested in the company. For this I do not advertise the benefits of the company but simply explain what the company does, what the software we create does, which languages and systems we use and maybe even demo some of it live. Also I explain the risks of working for a start-up company to the less experienced candidates. I don't do programming exams of any kind. Interactive exams exhibit dangerous positive feedback: you start with something in the middle. If the answer is good you make it more difficult. If the answer is bad you make it easier. Repeating this quickly converges to either extreme, which means you missed the chance to learn something more profound about the candidate, and even risk loosing suitable candidates at split-second blackouts. I don't like take-home exams either, although they are all the buzz these days. A take-home exam is a large investment for the candidate, and most of the people I hired never even touched the programming systems we were using (Erlang, Python, Ocaml, GLPK to name few). All hires did exceptionally well after a few weeks, and with a little bit of guidance. So what could a take-home exam tell me? Even worse, take-home exams are supposed to reduce the risk for the company, at the expense of the candidate. But do they actually do that? At what price? In addition, the large German probationary periods provide an easy way to correct mistakes later, which I had to do only twice so far.

by jonasvp 10y ago

lj3 10y ago

> found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. This. I advocate this method of interviewing here in the states every chance I get. The most common form of push back I get is from hiring managers terrified of being hoodwinked into making a bad hire. It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game. > I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of Junior engineers, I assume? I had problems with those questions when I first started out. It's hard to say with a straight face that the thing I was most proud of at that point in my career was creating a very simple templating system in PHP. Of course, the interviewers rolling their eyes and saying 'is that all?' didn't help.

jonasvp 10y ago
> It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game. Which is usually the case in larger companies, I assume. The person doing the hiring in that case is far removed from the people and work actually connected with the candidate. > Junior engineers, I assume? You're right, that's surely part of it. Not only, however - sometimes you get the feeling that work is something that happens to people, not something they seek out and try to get better at. Which for many positions is completely fine.
_pmf_ 10y ago
> Of course, the interviewers rolling their eyes and saying 'is that all?' didn't help. That says a lot about their maturity, not yours.

fsloth 10y ago

"found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. " When I've been job hunting in the past I've also found that these have been the best situations for me. I find coding questions beyond fizbuzz totally silly and when something more is requested of me my attitude shows this.

nherment 10y ago

We're in Denmark and currently hiring. I'm not sure why there is such extreme hate for the whiteboard. Yes it has plenty of caveats when it comes to actual coding and recruiters should not expect any candidate to write precise code on that medium. I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal. Candidates have the option to use my laptop (not ideal because the keyboard has a US layout) but they are welcome to use their own computer as well (if they thought about bringing it). It weeds out candidates who can't even produce basic code. And yes, a candidate with 2+ years of experience should be able to write a basic function on a whiteboard, a napkin, or whatever. If not, the interview is not lost but the candidate will have to prove his skills another way. For most candidates, we also give a longer technical test which is to be done at home and takes 2 to 4 hours to complete. Candidates are given as many days as they want to complete it. Whiteboard is an excellent medium however when discussing architecture and higher level ideas. It's also a tool that I've used during day to day activities with colleagues. Software based tools don't come even close.

jonasvp 10y ago
Interesting! I actually love using the whiteboard to sketch solutions and architectural decisions. I believe the hate comes from having to code on a whiteboard - which is justified, since no one ever coded on a whiteboard except in an interview.
muse900 10y ago
I believe the hate comes from unprecedented and hard CS questions asked on the whiteboard. I recently went to an interview that asked me to balance a binary tree on a whiteboard. It can be done, and I can do it. Thing is when you go to interview for that company that has 2 developers(small team, small company) and ask you that kind of question it puts you off thinking that those guys won't be great to work with (arrogance etc comes in mind). I am fond of simpler questions, like you said fizzbuz etc. Obviously if you are interviewing a guy that has 2+ years of experience, he has to be able to pass the fizzbuzz test. When you are interviewing someone with 5+ years of experience for a higher up position I guess you do have to ask some harder question, but I personally think just speaking to the guy and asking him stuff about his past projects etc will give you a hint on if he has the skills he is talking about or not. Asking him to outline a hard task he took part and how he solved it is an amazing start. As a 5+ years guy personally would rumble about a few things and it would take me days talking about them. (That will give you an understanding if I've worked before or not on the things outlined on my CV).

napoleoncomplex 10y ago

Also from Europe, and we have a similar approach, discussion with the candidate about previous work, interesting problems, any public code they've written, etc. Just to figure out what kind of challenges excite them, and get to know them better. We also do a coding challenge after that, basically the candidate behind a computer, with all the resources they want accessible to them, implementing a simple example directly relevant to the type of work they'll be doing, while the interviewers are in the room and debate with them if needed. To me, the most important quality in a candidate, once we determine that the basic skill level is good enough, is their ability to learn, quickly find the resources needed, and rely on the team when they need help. Whiteboard interviews don't seem to select for any of those qualities.

bbcbasic 10y ago

> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of. I have trouble recalling the details of things I worked on even say a week ago sometimes. I also don't find most of the work I do that interesting as I've been coding along time solving the same kinds of problems. However to play the game i would of course brush up for questions like that, and be quite convincing.

sgift 10y ago
> I have trouble recalling the details of things I worked on even say a week ago sometimes. No problem here, it probably wasn't very exciting but have you never encountered something which stuck in your mind? Or that you could at least recall some part of a project if someone asked "So, you've written here that you've worked on project xy and did this and that, can you tell us a bit more about it"?
- pm215 10y ago
  Asking about project xy is different though, it's more guided. I think it's much easier to answer than the really open ended ones that ask you to pick an incident from all 10-15 years of your work history: the field there is so wide that unless I've specifically considered the question in advance I'm likely to sit there going ummm for a bit. In general I think the question format favours people with a good memory for anecdotes and story telling ability.

et-al 10y ago

> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of. It could be that this technique favors people good at telling stories. Personally, I'm a horrible storyteller. If you were to ask me what I did over the weekend, I'll offer some facts like "oh, went swimming in a river and Bob lost his hat, but we found it later. The water was nice." Whereas Bob could easily regale you with stories about the epic hunt for his hat and throw in a punchline in the end. If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for. But if given the choice between speaking about myself or whiteboarding, I'll take the whiteboard. I've always preferred math over history for that matter. It's easier for some of us to apply processes than to recite chronologies.

jonasvp 10y ago
Good point. When I notice that people are struggling with finding something, I usually just pick one thing from the resume and try to go more in depth about that.
- et-al 10y ago
  You sound like a good interviewer that adjusts to each candidate. I wish more interviewers would learn the importance of this.
pmiller2 10y ago
Or, they just don't find the work terribly exciting. There's a lot of unexciting work to be done in software, and somebody has to do it.
- rtpg 10y ago
  There's definitely an industry bias towards "programmers as artists". If you don't love your work with a passion you're seen as less good. It's an alright proxy for other things, but there's a ton of good developers that leave their ego at the door, and their work at work.

zerr 10y ago

> one solution that they're proud of. Pride is a very strong word, especially for those of us with impostor syndrome...

_pmf_ 10y ago
The things I'm proudest about are the things I should probably not be proud of at all as a responsible professional.

andrewingram 10y ago

Generally speaking, someone's ability to recall things is very dependent on how they're feeling. If you're happy, it's easy to recall positive things, if you're depressed it's practically impossible. A lot of developers also have imposter syndrome. After I've solved an interesting problem, within a few days i'll probably have dismissed it as not being a big deal and started to forget about it. These kind of questions are useful, but candidates should be preparing their talking points, because the risk of forgetting the story that's going to get you hired is too high

mdpopescu 10y ago
Yes. I read about this idea a few years ago (tell a story about a project you liked) so I had to make an effort to focus on ONE story and tell it well. I've been doing it a couple dozen times so far (I'm a contractor who likes small projects, six months is starting to get too long) and I've had significant success with it. (When I think about the problem "objectively", all I did was use SSDT to simplify deploying database changes from QA to production without having to shut down either. No big deal. However, it was something that the company had been doing manually for years, spending three error-prone days each month, and they were extremely happy with my solution.)

atirip 10y ago

We are currently hiring. Denmark. We received i think few hundreds applications, picked 20, discussed internally, picked 5. Those 5 received invitation for homework, simple functional Javascript exercise. We dropped 2, the rest received invitation for UI Javascript exercise, vanilla btw. Then we talked with them. Picked one. In my previous gig in UK we had 3 homeworks and then chat. Sometimes we did drop the third when candidate was exceptional. So far only one candidate refused homework next stage, but the first stage result was bad enough for us to not consider him anyway. All top candidates and hires were eager to do the homework.

cmollis 10y ago

So true.. and this is a great interviewing technique. I basically ask one question during an interview: what was the hardest problem you ever had to solve? It may sound stupid at first glance, but it gives you insight into not only the breadth of their technical knowledge (since that problem may not be germane to the position you're hiring for), but also the depth of their abilities. The way they answer this question reveals quite a bit about the person. Not only technical, but also their interpersonal abilities.. how they manage their place on a team, how they manage expectations up and below, etc. I can glean quite a bit about the person based on how they answer this one question. Only asking questions about your particular domain doesn't necessarily indicate how good they'll be at solving those types of problems, only how much they happen to know about them. Of course, you can say that perhaps they shouldn't be interviewing for a position they may not be qualified for, but frankly the best people I've ever hired had very little experience in problem sets that were specific to my day-to-day responsibilities, but delving into details about things that they've done told me a great deal about how they solve anything. It may not be the best way to hire, because it requires a breadth of technical knowledge of the interviewer, but it definitely has worked for me. Asking someone to solve a ridiculous puzzle on a whiteboard..when they're obviously nervous about being there in the first place seems kind of dumb to me. However, digging into a problem that they've solved immediately puts them at ease.

AgentIcarus 10y ago
I'm not a huge fan of this question. I've been programming for 20 years (professionally for 13). Is the hardest problem some noddy maths i worked out at 15 to convert real coordinates to screen coordinates? Is it the first app i wrote out of college when i learned that servlets aren't thread safe? Is it what i worked on last year to design my current company's authentication/authorization system? I find it very hard to interpolate between these examples. And none of them are "hard"! I haven't written an OS or a more efficient linked list. All I've done is plugged away at something until it works.

ergothus 10y ago

Interesting. I've done a fair number of interviews for my last few companies, and while I've found that whiteboarding isn't terribly useful, likewise I've found that I really do need people to do some coding. I've definitely encountered people that talk a great story but don't have the chops behind a keyboard. My usual process (which isn't to say it's perfect, but it's a process I regularly edit to address problems I see) is to give a few, simple problems, and have them actually code it on a system. * I know that the computer and environment are unfamiliar to you, so I expect there to be chopiness and typos * I know that most people are nervous during interviews, so I don't fail people if they freeze on one of the questions or miss a concept * I don't give "trivia" questions - the problems tend to be fairly easy ones that cover your ability to approach basic problems. Example: "here is a nested data structure (like an array of objects). Write a method to pull these sorts of elements out." * I'm actually hoping you'll screw up - I'm far more interested in seeing how you deal with a bug than if you can dash out an algorithm flawlessly. Nonetheless, I keep the questions simple because I want to minimize the impact of nervousness * I inform people they are absolutely allowed to use Google, StackOverflow, etc - I'm trying to mimic the actual work experience as much as I can. I WILL judge people on their searches, but I'm pretty loose - I can only recall one person that I dinged for searching, and that's because they went to about.com and copied the answer there without trying to understand it (and it subsequently didn't work). Usually this ends up GIVING people points, because if they demonstrate comfort with finding solutions, I expect that we can hire them and know they'll improve over time. Despite this, I still ask a few questions that are purely verbal. I want to see if you are someone that will force your preferences on others or are willing to bend. (I'm not looking for a doormat, but I've never met one, so that's a bit moot) I want to see that you are continuing to learn things, because the skills you have now will just not be the skills we need in a year or two. but overall - I have to judge candidates based on the limited info I can glean in an interview. Of: * resume * whiteboarding skills * discussion skills * coding skills ...I find the latter to be the best measurement of the options, even allowing that it won't be fully accurate.

segner 9y ago

Hi JonasVP, a little late but regarding your original question... We were building a tech team at a start-up in Germany. Our hiring process evolved and stabilized into the following process, which worked exceptionally well for us: 1. Review of written documents, accepting any kind, any style and any medium. 2. Telephone interview with recruiter from HR about motivation, personality and the formal aspects of education and experience. 3. Personal interview with VP of engineering. Future employee is asked to bring some of his or her source code to the interview, any language any style any form is good. We don't copy the code, we don't keep it, we don't use it in any way. This is the only technical interview. 4. Interview with the CTO, immediately following. This is the most important social interview, and it also contains the main salary negotiation. 5. Decision. Between any of the steps, we would briefly exchange our impression of the candidate, and it turned out that it is wise to sleep a night before taking the decision. My function was VP of engineering and lead architect, and I would conduct the interviews of step 3. My principles are as follows: - Keep the candidate at ease as much as possible. We want developers to crack hard problems with "feet on the table" as the Dutch say, most of the time. Stress distorts things, and I want to see the undistorted version. - Get to know the candidate, and what makes him or her tick. This requires respect, tact and genuine interest in the person and his or her achievements. - Estimate the fit with team and company. I can talk a lot about this---but in the end it either feels right or it does not. - Gauge the technical capabilities of the candidate. For this I let the candidate choose a piece of the source code at will and have her explain what it does, and why it is the way it is. For all our hires, some form of dialog on software architecture in general emerged. This usually takes between 10-30 minutes. - Do your best to get the candidate interested in the company. For this I do not advertise the benefits of the company but simply explain what the company does, what the software we create does, which languages and systems we use and maybe even demo some of it live. Also I explain the risks of working for a start-up company to the less experienced candidates. I don't do programming exams of any kind. Interactive exams exhibit dangerous positive feedback: you start with something in the middle. If the answer is good you make it more difficult. If the answer is bad you make it easier. Repeating this quickly converges to either extreme, which means you missed the chance to learn something more profound about the candidate, and even risk loosing suitable candidates at split-second blackouts. I don't like take-home exams either, although they are all the buzz these days. A take-home exam is a large investment for the candidate, and most of the people I hired never even touched the programming systems we were using (Erlang, Python, Ocaml, GLPK to name few). All hires did exceptionally well after a few weeks, and with a little bit of guidance. So what could a take-home exam tell me? Even worse, take-home exams are supposed to reduce the risk for the company, at the expense of the candidate. But do they actually do that? At what price? In addition, the large German probationary periods provide an easy way to correct mistakes later, which I had to do only twice so far.