It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I've been on both sides. I like it for more senior-level positions: if I'm interviewing someone for a lead or architect job, whether they can remember how to balance a b-tree is unimportant. If your architect is balancing b-trees, you're wasting their time and losing money. At that level, you need to know how they approach problems, how they design systems, and how they work with people. It's difficult to get a sense of that from compsci trivia.
For junior and midlevel positions it's more important to validate that the candidate can do the work you need them to do. I like take-home projects for that much more than live coding or especially whiteboarding, since (assuming you're not fully locked-down) they'll have access to Google and StackOverflow if they work for you. All realtime tests do is give candidates heart palpitations.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I ask them to talk me through the designs of things they've created, showing me their code or even just sketching the architecture out on a whiteboard. If you can communicate how and why these parts interact, what this choice simplifies, why integrating X made sense, what problems Y caused and how you addressed them, then that showcases both your understanding of software development principles and your architectural sensibilities.
I propose hypothetical scenarios and ask how they would address them. I'm not interested in the precise steps, but in how they think. My favorite for this is "you have a straightforward client-server-database web application. QA drops a screenshot of an error page they received after submitting such-and-such form in your lap. Go." Do they check logs? Do they try to reproduce the issue? Do they ask for more information? When they address it, what steps do they take to ensure the same or similar problems won't recur?
I do still ask technical questions, but I make a point of minimizing trivia for senior and junior candidates alike. I'm more interested in your understanding of principles: tell me what distinguishes inner from outer joins, how do database indexes work, what does inversion of control mean and what does it do for you, describe REST and how you would use it in an application, that sort of thing. Obviously these vary in "difficulty", but I don't care so much about getting dictionary definitions. If a junior candidate tells me that they aren't sure but inner and outer joins have something to do with filtering rows out based on what's in the joined tables, that's positive.
My single favorite interview question overall is "what's your least favorite technology to work with, and why?" The only wrong answer is one you can't support.
Also, if you don't mind me asking about more junior positions. Why do you feel asking them about their previous experience doesn't show you if they can do the work you need them to?
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Someone with junior-level experience is by definition less likely to have had the time to develop the vocabulary, the range of expertise, and the conceptual insight of a senior candidate. Erring on the side of practice over theory lets them show off what they can do and lowers the risk of getting into the weeds over abstractions.
That said, if a candidate has public code that's in the neighborhood of what I'm hiring for I will absolutely throw it up on the projector and make a code review/art school type critique part of the interview, but you can't depend on that being the case, especially for junior candidates. I'll have senior candidates do take-home projects too, depending on the position and their resume; this is far from an exact science.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've been on both sides. I like it for more senior-level positions: if I'm interviewing someone for a lead or architect job, whether they can remember how to balance a b-tree is unimportant. If your architect is balancing b-trees, you're wasting their time and losing money. At that level, you need to know how they approach problems, how they design systems, and how they work with people. It's difficult to get a sense of that from compsci trivia.
For junior and midlevel positions it's more important to validate that the candidate can do the work you need them to do. I like take-home projects for that much more than live coding or especially whiteboarding, since (assuming you're not fully locked-down) they'll have access to Google and StackOverflow if they work for you. All realtime tests do is give candidates heart palpitations.
Thank you for sharing!
Can you explain a bit more what questions do you ask for these senior-level positions where you apply this approach?
I ask them to talk me through the designs of things they've created, showing me their code or even just sketching the architecture out on a whiteboard. If you can communicate how and why these parts interact, what this choice simplifies, why integrating X made sense, what problems Y caused and how you addressed them, then that showcases both your understanding of software development principles and your architectural sensibilities.
I propose hypothetical scenarios and ask how they would address them. I'm not interested in the precise steps, but in how they think. My favorite for this is "you have a straightforward client-server-database web application. QA drops a screenshot of an error page they received after submitting such-and-such form in your lap. Go." Do they check logs? Do they try to reproduce the issue? Do they ask for more information? When they address it, what steps do they take to ensure the same or similar problems won't recur?
I do still ask technical questions, but I make a point of minimizing trivia for senior and junior candidates alike. I'm more interested in your understanding of principles: tell me what distinguishes inner from outer joins, how do database indexes work, what does inversion of control mean and what does it do for you, describe REST and how you would use it in an application, that sort of thing. Obviously these vary in "difficulty", but I don't care so much about getting dictionary definitions. If a junior candidate tells me that they aren't sure but inner and outer joins have something to do with filtering rows out based on what's in the joined tables, that's positive.
My single favorite interview question overall is "what's your least favorite technology to work with, and why?" The only wrong answer is one you can't support.
Also, if you don't mind me asking about more junior positions. Why do you feel asking them about their previous experience doesn't show you if they can do the work you need them to?
Someone with junior-level experience is by definition less likely to have had the time to develop the vocabulary, the range of expertise, and the conceptual insight of a senior candidate. Erring on the side of practice over theory lets them show off what they can do and lowers the risk of getting into the weeds over abstractions.
That said, if a candidate has public code that's in the neighborhood of what I'm hiring for I will absolutely throw it up on the projector and make a code review/art school type critique part of the interview, but you can't depend on that being the case, especially for junior candidates. I'll have senior candidates do take-home projects too, depending on the position and their resume; this is far from an exact science.