I've conducted many interviews. There are many reasons why I reject people, but there are recurring themes. I want to give a list of the most commo...
For further actions, you may consider blocking this person and/or reporting abuse
My current position did not have a "technical" interview. The CTO and Manager interviewed me personally and we just talked. At the end of the day are you hiring someone based on how they code right now in a bubble or the ability to learn and be part of a great team? I'm not saying they had the right way or wrong way, but it set an expectation of trust and collaboration from the get go. Idk food for thought perhaps. Great post by the way.
This is why I place a lot of value in the feedback during the interview. While it's important that they come up with a working solution, it's their behaviour that determines whether that will happen.
I will often have people who could not solve the problem on their own, but by listening to their thoughts and reading their code, I can guide them towards a working solution. This fulfills the requirements I think you want: can this person learn and grow.
Well said, thank you for the reply.
I think that can totally work, but it's also true that some people are much better at talking the talk than walking the walk. Having a session where you can spend an hour or so working with someone to see how they organize their thoughts and solve problems can be quite illuminating. If a person you're considering hiring already has a decent amount of experience, and maybe they can point to a body of code that they've written, it may be less crucial to actually do a coding interview, and just a get-to-know-you session is good enough.
How do you deal with false positives? Where a programmer has these issues only in the moment because of social anxiety?
I try to create an environment to minimize interview stress, and I think I'm an okay judge of character. However, that said, there are two, rather cold, views on this.
A) There's enough candidates that you don't have to worry about failing somebody incorrectly. It's better to accidentally reject qualified people than to occassionally accept unqualified people. The quantity of applications makes it harder for individual applicants.
B) It's part of the job. The skills you use during the interview will be required again while you are working. If the pressure, or anxiety, hurts your performance in the interview, should I not assume it might also hurt your performance in a job? I know the interview tends to exacerbate issues, but I don't think it fundamentally creates them.
As an interviewer you try your best to see through interview stress, but you won't be perfect. The unfortunate truth is that interviews aren't merely an assessment of your abilities, they are a competition. And you have to train to win at them. I'd prefer this weren't the case, and I try to minimize it, but it's still the reality we face now. :(
Not a direct answer to your question, but maybe this can lead to some meaningful conversation.
Before I switched to becoming full time developer, I used to be a musician. One thing I never quite got over from HS was stage fright. After years of dealing with this, I noticed a couple of trends that would trigger my stage fright. Often times I feel like it was brought on or enhanced by a lack of preparedness on my part. Knowing that, I was able to lessen the effects of stage fright but over time I learned, it never really goes away.
The stage fright is always there. The thing is, you get comfortable with being uncomfortable. You learn to sort of work around it. From my experience, the only way you can develop this level of comfortability is by putting yourself in the "spotlight" often.
Practice interviewing with other people. Try to change it up and maybe schedule an interview with someone you're not so familiar with. Give yourself some real stakes. Make it as close a simulation to the real thing as possible. I exposed myself to situations like that often enough that I knew exactly how I was going to feel and how I should counteract it or at least minimize my stage fright.
very well said: i guess i will print and frame it :-)
Not to be contrary, but for some folks with social anxiety, no amount of practice is going to fix that. What I would frame from these responses is the complete lack of empathy that a person could be a badass but have a genuine disorder, which makes them worthy of rejection.
I think even people with severe social anxiety can improve their ability to deal with interviews, although in some cases it may not be a good idea to do it alone. For some, it may be wise to get some professional help from a psychologist who specializes in that area.
Not everyone has to be thoroughly extroverted, but in many professional environments it's important to be able to interact effectively with other people.
I have worked as CTO and some other leadership positions and done my handful of interviews. In those cases, I have always tried to strike a conversation with the person, see what he likes about the software world and try to make him feel at ease (taking into account that it is an interview). If the person is especially anxious, going out to have a friendly coffee works too because it's a more neutral ground.
I completely agree with most of the points here, especially "don't know the basics of coding". When I started interviewing people, I was surprised how much difficulty most people have with writing a single loop and a conditional statement.
That said, I'm not entirely convinced about "overthink and complicate the question". In general, you shouldn't look for things that "aren't there" but in some cases it's desired for the candidate to try to understand the problem better before coding. We used to have a simple assignment rooted in a real business scenario and I always valued it when people asked questions about how the business really works instead of making rush assumptions.
By overthink I really mean overthink, not just understanding the problem. If you don't understand, or are uncertain, then ask. By overthink I mean things like planning for future requirements or making extension points that are unnecessary. These are things you shouldn't be doing in normal coding either.
I agree it's not a well defined line, but there is difference between understanding the problem, and complicating the problem.
Totally agree with you, sometimes we focus only in complexity things and we forget the simple ones.
Some months ago I took a lot of interviews and at the beginning it was so hard (first because my English is bad, second to be honest I didn't have a good level), but one think that I hate is that recruiters didn't give me ANY feedback about what I did wrong (even if I asked them, they said we can not give you the feedback now, I didn't ask about the feed back, I asked about a recommendation how to improve, because how Can I do it good if I don't know what is wrong with me?).
Feedback is so important to improve.
Hiring laws, relating to discrimination, can make it tricky for companies to provide honest feedback. It's unfortunate.
Sites that provide prescreening and practice interviews are a bit more flexible.
Why not bring a cheat sheet or two to an interview? When I develop/test I use checklists for my work. Shouldn't that be allowed during an interview? It won't give the person the answers, but I always struggle with syntax as I bounce around many languages.
A simple cheat sheet might be good, especially if all it does is keep your thoughts focused.
There are certain items a person could bring to an interview that would be a plus in my book.
I'd not be opposed to this. It's still better to have them memorized, for time reasons, but a nicely organized cheat sheet could definitely help. If you're capable of using the reference quickly, then when not. If you don't know the language at all, a cheat sheet is unlikely to help you.
How can you pay attention to braces and semicolons knowing they don't have a formatter running? :/
Sorry if this is precisely nitpicking, but I found that line rather hypocritical.
I'm not so concerned about misalignment, but there's still room to be inconsistent, like putting some braces on a new line, and some not. Languages like JS have optional semi-colons. C++ allows if statements with braces, or single line ones without.
Overall, this type of thing is a minor consideration. It's highly unlikely my evaluation would be affected, but it is something I will point out in the feedback.
They might have a method to their madness that you don't immediately understand.
I feel like it's mandatory they at least once ask "can I use my editor to format" or "complain" about the interview editor not having a formatter :)
Shows that they are about the good practices and not the bikeshedding.
Asking "can I change the formatter settings" would be worrying though xD
Most candidates seem to have some experience, even in junior positions. It may be an internship, or short-term job they had. Though, the more junior somebody is the less I consider experience. Letting them talk about their position usually helps though, even if it was only for a few months.
Don't lie about what you did, give an honest assessment, or factual, of how you saw your position. It's easy to see through bravado and nonsense. Plus, you want the interviewer to understand where you are now.
"While you're coding, I expect you to talk about what you're doing."
I was "almost" rejected once because I spoke a lot instead of writing the code.
Soft skills are so underrated, yet 90% of daily interactions depend on them.
See personally a problem I can have in interviews is freezing up on questions that I know the answers to.
Any recommendation for that?
I would say the single best thing you can do for yourself is to put yourself into that situation repeatedly. It will be very uncomfortable at first, but it will get easier as time goes on. Human beings are very adaptable!