I like the one where you ask the person to explain “what happens between when you type an address in a browser until you get something to show up” in as much details they can. It tells you a lot about people understand all the different concepts involving computing.
I did this as an exercise just now, and I noticed I answered mostly in networking terms. Sockets, ports, explaining what an autonomous system is and how DNS requests flow between them, explaining a TLS handshake, and HTTP and HTML and what a server is, and how it works, there's always more to cover.
I realized I know very little of what happens _inside_ the computer during the typing, what libraries are involved? How does data flow _inside_ the computer? I like to think I know enough about my hardware, but this has been humbling.
I tend to ask this type of question as well. Not only does it show you the level of detail they know, but it also show you how well they filter that knowledge to the situation and audience. I'd expect someone being hired for a networking role to talk more about the networking and DNS, while someone begin hired for a front-end role would talk more about the content that is sent and returned to the browser, and a back-end or full-stack dev to talk about how the destination server handles the request and builds a response. Even better if they ask a clarifying question to confirm which pieces I really want to hear about.
This is always my favourite question to ask as their answer tells me exactly where their knowledge is strongest and thus would the candidate be suited to the role - or get bored very quickly and I'd be back to square one for hiring in 12 months time?
In my first frontend interview at 18, the interviewer tested me on the most basic thing. He could have asked more difficult questions that I might have had the answer to, but instead he asked about markup.
“In this first line of HTML it says <!doctype html>, what will happen if we remove it and why?”
Unfortunately, it discouraged me at that age to try again for a long time, but it stuck with me.
It wasn't trivia back in the day, it was a basic yet critical piece of getting your site to behave consistently across browsers. But it is definitely a dated question.
> What would you do to radically improve test automation speed?
Speed questions are good ones since they show how people think, some will immediately jump into random action items while others will investigate the problem first and suggest different approaches to different problems.
"ELI5 to me how I can order something on Amazon using an iPad"
Engineering is about clear communication of ideas and sometimes we have to _really_ dumb down some things for a non-technical audience (think board members).
Trying to ELI5 a subject you feel is your strongest is surprisingly difficult - but a vital skill when moving up the engineering ladder.
"it says here that you've been using technology X for a few years. What is the most frustrating thing about X? If you had the resources needed what would you do to fix it?"
One of the most interesting question i was asked was: What is the biggest fire you created and how did you handle it?
The interviewer told me that the purpose of the question was to learn 1) are you willing to admit mistakes 2) what is the most responsibility you've been trusted with. After all the bigger the fire, the more you were likely trusted 3) how do you act under stress 4) can you learn lessons from your mistake.
I think it's a fantastic cultural fit type question.
20 comments
[ 3.1 ms ] story [ 64.3 ms ] threadI realized I know very little of what happens _inside_ the computer during the typing, what libraries are involved? How does data flow _inside_ the computer? I like to think I know enough about my hardware, but this has been humbling.
Thank you for bringing this up.
“In this first line of HTML it says <!doctype html>, what will happen if we remove it and why?”
Unfortunately, it discouraged me at that age to try again for a long time, but it stuck with me.
What would you do to radically improve test automation speed?
Describe accessibility in as much detail as you can.
In the context of web services explain full duplex service transmission.
What is something amazing you would suggest we implement with Node.js to reduce our operating expenses?
Speed questions are good ones since they show how people think, some will immediately jump into random action items while others will investigate the problem first and suggest different approaches to different problems.
1. Why do you choose Japan? (so why pick me during screening if you want me out?)
2. Tell me the largest achievement of yours. (completely parallel to work ability and don't even reveal any personality)
3. What's your future plan? (want me to tell you that I will quit 5 years later just to get a PhD?)
These question must be so epic that everyone must ask once everytime.
Engineering is about clear communication of ideas and sometimes we have to _really_ dumb down some things for a non-technical audience (think board members).
Trying to ELI5 a subject you feel is your strongest is surprisingly difficult - but a vital skill when moving up the engineering ladder.
The interviewer told me that the purpose of the question was to learn 1) are you willing to admit mistakes 2) what is the most responsibility you've been trusted with. After all the bigger the fire, the more you were likely trusted 3) how do you act under stress 4) can you learn lessons from your mistake.
I think it's a fantastic cultural fit type question.