4 ms·

A perspective from the interviewer's side. Since I run a small startup, when hiring, my first thing to determine was that whether I would be able to work with t

A perspective from the interviewer's side. Since I run a small startup, when hiring, my first thing to determine was that whether I would be able to work with the candidate. Hence, I would come up with a puzzle, a maths problem, or even a guesstimate, just to see the thought process and that whether there is any "gelling". Things to evaluate are, original thinking, how well the candidate puts his perspective forward, how well he takes suggestions, how quickly he reaches the crux of the problem etc. If there is a face to face interview, the general assumption is that the candidate is talented, more important is that whether he can work with others in the company. If I am hiring someone who will work alone, without anyone's inputs, I might change the process (something like an integration or SSIS workflow) but have not needed to encounter that as of yet. I usually go through the resume, and have interviewed enough coders to understand that they would know about what is written on the resume. Hence, knowing the background is good enough for evaluation, but feels repetitive during the interview. (Also, if you have had 4-5 years of experience, and 2-3 jobs, you can only stay for long if you had good skillset)

gwbas1c 8y ago
I usually give my disclaimer: "These aren't real world problems. Some questions involve code that we wouldn't write in the real world. We only have 45 minutes. The goal is to have a conversation about code." And then I point out that "it's not practical to spend 2-3 days on-boarding you for a job interview. Thus, these questions are contrived. The best way to succeed is to have a conversation about code, and sometimes you need to play a little bit of the 'tell me what I want to hear' game". And then, for one question, I need to point out that, "I once had a candidate say, 'I like JSON better then XML. XML's outdated.' This question is to discuss concepts that are easy to discuss with C#'s XML APIs, because chances are, you've used them." (And if the candidate tells me that they don't have a lot of XML experience, it's okay.

gwbas1c 8y ago

I usually give my disclaimer: "These aren't real world problems. Some questions involve code that we wouldn't write in the real world. We only have 45 minutes. The goal is to have a conversation about code." And then I point out that "it's not practical to spend 2-3 days on-boarding you for a job interview. Thus, these questions are contrived. The best way to succeed is to have a conversation about code, and sometimes you need to play a little bit of the 'tell me what I want to hear' game". And then, for one question, I need to point out that, "I once had a candidate say, 'I like JSON better then XML. XML's outdated.' This question is to discuss concepts that are easy to discuss with C#'s XML APIs, because chances are, you've used them." (And if the candidate tells me that they don't have a lot of XML experience, it's okay.