5 ms·
I usually ask what's your strongest language; then ask questions about that programming language. f.e. if it is python: > how would you explain the with statem
by je42 8y ago
I usually ask what's your strongest language; then ask questions about that programming language.
f.e. if it is python:
> how would you explain the with statement to a junior developer ?
then increasingly difficult questions that go into the language runtime/concepts.
one other favourite question of mine is:
> Imagine, you got a standard website the serves data from a database. When a customer types in the url into the browser bar what needs to happen until the customer see the website.
> Go as deep as you can in the answering the question.
When you got an answer, you'll see frontend engineers explain more about the browser, while backend engineers talk more about the backend.
There was one very senior engineer, that actually talked about the ethernet layer, he talked for more than 15min. Most medior engineers are done in 5mins. ;)
- retzkek 8y ago> Imagine, you got a standard website the serves data from a database. When a customer types in the url into the browser bar what needs to happen until the customer see the website. That's a favorite of mine too. It sets up a broad range of discussion without needing to spend much time setting up hypotheticals and lets the interviewee really delve into topics for which they have expertise and/or interest. It's also easily adapted or sets up follow-up questions for different positions or levels, e.g. "with TLS," or "how would you debug a problem with symptom x?"
- je42 8y agoexactly that you can have very interesting conversations. in a setting that the interviewee is most comfortable with, since the assumptions/details are determined by them. it put the pressure a bit on you as interviewer, since you need to adapt your questions. but in general i found it quite easy when you have a rough plan on the topics to ask.
- Consultant32452 8y agoI'm like the senior engineer you mentioned. I'll spend as much time as possible on them to see if I can wear out the attention of the interviewer. They usually give up by the time I get to how SSL handshakes work.
- matwood 8y agoThere is so much that can happen between the browser making a request and receiving a response, that someone could completely gloss over the OSI model and still talk for a very long time. I've toyed around with starting my answer with what happens when the physical return key on the keyboard is pressed. Could spend quite a bit of time on what happens before the browser even knows the return key was pressed :D
- caspar 8y agoSee https://github.com/alex/what-happens-when https://github.com/alex/what-happens-when
- je42 8y agohehe. however, if you look at this. do you think this is a server engineer or a client engineer ? :D
- je42 8y agoyep. indeed. and it is still a valid and interesting answer. if you talk about keyboard driver, rendering of the address bar, etc ;)
- baroffoos 8y ago> Go as deep as you can in the answering the question. I'm not a fan of this because it wastes time. Its better to give an overview of the steps and then if more information is required the interviewer can ask for it. They can keep asking for more information until they are satisfied the person knows enough or the person can not answer anymore.
- je42 8y agoyou test different things. you could go with breadth first and then depth. however, i would not skip depth, since depth indicates how deep this guy/girl can go if necessary to solve problems.