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.
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 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.