What editor do you use? As you dive into your set up, you open up about how much you care about your craft.
Which is not to say that there aren't people who simply don't care about the env they work in, yet are great SWEs: it's just that it reveals the persons attitude, preferences and can get them excited (for better and for worse :)).
I like the "getting excited" idea. A lot of people I've met really open up when they can get to talking about something they understand and are interested in. Instantly more comfortable now that the conversation is "in their domain"
One I suggested to my team lead was to ask what was a problem or challenge the applicant had been wrestling with recently w.r.t the language or job. I think an organic, open question like this would help to identify what the applicant spent time thinking about and provide insight into their nature as a programmer beyond what leetcode might offer.
I think a similar interesting question: asking for one or several things the applicant dislikes most about the programming language, would be similarly revealing.
YMMV when it comes to people who are smart but not very good talkers, but I think it's better than, say, asking people to sing a song, like some recruiters do.
I basically just ask questions about hash tables; starting from the concept of associative arrays, down to the implementation of a table specific to a purpose (a minimal perfect hash with a rolling hash function). Generally if a person is trying to be a SWE and doesn't know about associative arrays, they're not going to work out. I don't expect people to answer deep questions about specific hash performance you'd get from a CS grad who studied Knuth; I want to know how you think about a mildly complicated data structure.
Along the way I ask a few questions about bits, which provides some dynamic signal (for example, would this person be good at low-level stuff?)
I think asking a question like this largely depends on domain, what sort of (even exceptional) lets say, rails developer is going to know in-depth information about hash table implementations off the top of their head?
I'd expect anyone who knows how to code in anything to understand the concept of an associative array, but not necessarily the nuances of hashing and performance, especially not the performance of specific hashing algos. Most of that work is handled by language designers/compiler designers for you in the majority of use cases.
I suspect you work in a field where this sort of information is far more well known/common to deal with in day to day?
I try to be different when asking my share of questions in interviews...
My favorite to ask is:
"Tell me about a time you really screwed something up."
This can be a design decision, or may accidentally running "drop table users"...
This is an open ended question. The more experienced interviewees will pivot to how they learned something from it or whatever. I'm just looking for general humility tbh.
If they're nervous or confused, I'll share a few of my stories, like the time I really did drop that users table, or tripped over a power chord in a data center when disaster recovery testing was being done.
I spent a few years interviewing people while working for a megacorp -- candidates applying for software engineering roles were subjected to a variation of this question fairly regularly.
Warning signals in responses could be someone claiming they've never failed at anything, or trying to push all the blame onto former colleagues without owning any part of it, or when asked what they'd do differently in a similar situation in future, saying that they'd do exactly the same thing.
All that said, I'm not sure this kind of question adds that much value to an interview pipeline. Many candidates early in their career may not yet have war stories of how they broke production, or may have poor interview technique and not really know how to handle this well. Arguably asking this question is putting someone under pressure in the stressful context of an interview, to see how they respond. People who are already terrified by the interview process may not respond very well at all -- but how relevant is this to the role you're hiring for?
This question might give you a strong red flag to reject a candidate < 5% of the time, but it doesn't give you a reason to accept them. They still have to do well on the other parts of the hiring process that assess technical skills & problem solving.
9 comments
[ 3.3 ms ] story [ 43.5 ms ] threadWhich is not to say that there aren't people who simply don't care about the env they work in, yet are great SWEs: it's just that it reveals the persons attitude, preferences and can get them excited (for better and for worse :)).
I think a similar interesting question: asking for one or several things the applicant dislikes most about the programming language, would be similarly revealing.
YMMV when it comes to people who are smart but not very good talkers, but I think it's better than, say, asking people to sing a song, like some recruiters do.
Along the way I ask a few questions about bits, which provides some dynamic signal (for example, would this person be good at low-level stuff?)
I'd expect anyone who knows how to code in anything to understand the concept of an associative array, but not necessarily the nuances of hashing and performance, especially not the performance of specific hashing algos. Most of that work is handled by language designers/compiler designers for you in the majority of use cases.
I suspect you work in a field where this sort of information is far more well known/common to deal with in day to day?
My favorite to ask is:
"Tell me about a time you really screwed something up."
This can be a design decision, or may accidentally running "drop table users"...
This is an open ended question. The more experienced interviewees will pivot to how they learned something from it or whatever. I'm just looking for general humility tbh.
If they're nervous or confused, I'll share a few of my stories, like the time I really did drop that users table, or tripped over a power chord in a data center when disaster recovery testing was being done.
Warning signals in responses could be someone claiming they've never failed at anything, or trying to push all the blame onto former colleagues without owning any part of it, or when asked what they'd do differently in a similar situation in future, saying that they'd do exactly the same thing.
All that said, I'm not sure this kind of question adds that much value to an interview pipeline. Many candidates early in their career may not yet have war stories of how they broke production, or may have poor interview technique and not really know how to handle this well. Arguably asking this question is putting someone under pressure in the stressful context of an interview, to see how they respond. People who are already terrified by the interview process may not respond very well at all -- but how relevant is this to the role you're hiring for?
This question might give you a strong red flag to reject a candidate < 5% of the time, but it doesn't give you a reason to accept them. They still have to do well on the other parts of the hiring process that assess technical skills & problem solving.
How big of a fuck up are you looking for?
Do you wanna hear about the time I broke all internet e-mail for the entire world in 1996, or do you want something more recent?
Hen you ask an intro question like that, I think you would want to have some idea of how you'd answer my questions like this.