3 ms·

Surprised it hasn't been mentioned yet... API design. (Perhaps people consider it middle-ware of sorts?) Anyways, your API is basically the interface to your ba

Surprised it hasn't been mentioned yet... API design. (Perhaps people consider it middle-ware of sorts?) Anyways, your API is basically the interface to your back-end and goes hand-in-hand with your database as the core components of your data model, which in turn, is probably the most critical aspect of most software.

gnulinux 8y ago
My company asks API design question in interviews (in fact, I designed and ask this question). We don't expect candidate to know anything about HTTP, REST and databases (if the candidate is junior). We have a question prompt that essentially summarizes what candidates need to know to solve the problem. Then, we give them an example API and a real life problem. We expect them to design the API between app and backend using RESTful HTTP requests, and for extra points they can design database structure too (how to store data coming from APIs) (and how to make it efficient, e.g. using which indices etc) Candidate has full freedom and I try to see if they can (1) read a technical document and understand (2) design a structure and process to solve a problem (3) can they collaborate with me to improve their ideas. In practice I thought this question is pretty useful. There are some hickups though (like if candidate is clueless about what REST is you need to give them 5 mins so they can read and understand it, which causes some silence, which I don't think is ideal) but so far we thought it's a good question.
- abraae 8y ago
  If by REST you mean full on HATEOAS then I definitely would not use that as an interview test. Advocates tend to be religious in their intensity, yet few real world APIs are full REST in that sense. Discussions around HATEOAS could be enlightening but requiring people to buy into it not IMO. I would structure interview questions around APIs rather about distributed systems/transactions, circuit breakers, etc. - practical aspects of running multiple systems talking to each other through pipes.
  - gnulinux 8y ago
    I let candidate design an API for a problem we solved in real life (and compare their API to the API and db I designed). It really isn't about HATEOAS purism, we chose REST simply as an abstraction candidate should operate in, but they're free to break some principles if they like (for caching etc we already break it). We're mindful of these and are very lenient with candidate's answer. As long as they can show signs of being able to solve the problem in real life, they're good to go. I should note that we use this question mostly for junior candidates, and this is the very final round of interview so all candidates will be asked ~6 45min questions and this is only one of them.

gnulinux 8y ago

My company asks API design question in interviews (in fact, I designed and ask this question). We don't expect candidate to know anything about HTTP, REST and databases (if the candidate is junior). We have a question prompt that essentially summarizes what candidates need to know to solve the problem. Then, we give them an example API and a real life problem. We expect them to design the API between app and backend using RESTful HTTP requests, and for extra points they can design database structure too (how to store data coming from APIs) (and how to make it efficient, e.g. using which indices etc) Candidate has full freedom and I try to see if they can (1) read a technical document and understand (2) design a structure and process to solve a problem (3) can they collaborate with me to improve their ideas. In practice I thought this question is pretty useful. There are some hickups though (like if candidate is clueless about what REST is you need to give them 5 mins so they can read and understand it, which causes some silence, which I don't think is ideal) but so far we thought it's a good question.

abraae 8y ago
If by REST you mean full on HATEOAS then I definitely would not use that as an interview test. Advocates tend to be religious in their intensity, yet few real world APIs are full REST in that sense. Discussions around HATEOAS could be enlightening but requiring people to buy into it not IMO. I would structure interview questions around APIs rather about distributed systems/transactions, circuit breakers, etc. - practical aspects of running multiple systems talking to each other through pipes.
- gnulinux 8y ago
  I let candidate design an API for a problem we solved in real life (and compare their API to the API and db I designed). It really isn't about HATEOAS purism, we chose REST simply as an abstraction candidate should operate in, but they're free to break some principles if they like (for caching etc we already break it). We're mindful of these and are very lenient with candidate's answer. As long as they can show signs of being able to solve the problem in real life, they're good to go. I should note that we use this question mostly for junior candidates, and this is the very final round of interview so all candidates will be asked ~6 45min questions and this is only one of them.