4 ms·

Designed and implemented GraphQL API for 30 objects serving 200 Queries per second

by treis 6y ago

ubercow13 6y ago
That still seems meaningless. 200 queries per second, while pegging 8 CPU cores. Meanwhile my coworker got the short straw implemented a less-used API serving 10 queries, but did it much better than me and used no CPU.
- zerkten 6y ago
  That's far from a perfect statement, but it's not the worst that you see. As an interviewer, the difference is between junior and senior developers. It's an indication that they they understand the currency and some metrics for an area/business, but more than that, it sets out their position. That position is something I should be challenging in the interview with questions to probe deeper: * Can you tell more about the GraphQL API? Was this new or replacing an API? Tell me about the constraints and goals you were working towards? * What issues did you have getting to that level of performance? What trade-offs did you make when you hit issues? * What are the challenges with running your API in production? * Can the API you implemented scale higher? If so, what would need to be changed with it as you scale to 400 and 1200 queries per second? If this person has done the work this should be a good discussion and you can start to bring in some of your business or technical problems. It will be very evident whether someone has just invented metrics, or the statement is describing the work of others. I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews.
  - mcenedella 6y ago
    OP here. This is exactly right: "I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews." Hope you don't mind if I steal some of your comment to use in the update of my post! :)
    - zerkten 6y ago
      Quote away!
redisman 6y ago
To me that would still tell nothing. Did you just implement 30 queries that are “get item by key” from a database someone else designed so that your job was extremely easy ?
- treis 6y ago
  Even if it doesn't answer every question it gives you at least some insight into the scale and scope of what they did. Sure numbers can always be fudged but it's better than no numbers. How would you write that line?
  - cercatrova 6y ago
    > Sure numbers can always be fudged but it's better than no numbers. You can make the same argument for user engagement or business metrics numbers too. For most managers reviewing resumes, any number is better than none.
- mcenedella 6y ago
  Thanks for the comments. Perhaps I can be helpful by walking backwards from something you do perceive as valuable? For hiring conversations, what's a great one look like to you?
mcenedella 6y ago
OP here. Hope you don't mind if I borrow this for the update of my post!

Designed and implemented GraphQL API for 30 objects serving 200 Queries per second

by treis 6y ago

Designed and implemented GraphQL API for 30 objects serving 200 Queries per second

That still seems meaningless. 200 queries per second, while pegging 8 CPU cores. Meanwhile my coworker got the short straw implemented a less-used API serving 10 queries, but did it much better than me and used no CPU.

zerkten 6y ago
That's far from a perfect statement, but it's not the worst that you see. As an interviewer, the difference is between junior and senior developers. It's an indication that they they understand the currency and some metrics for an area/business, but more than that, it sets out their position. That position is something I should be challenging in the interview with questions to probe deeper: * Can you tell more about the GraphQL API? Was this new or replacing an API? Tell me about the constraints and goals you were working towards? * What issues did you have getting to that level of performance? What trade-offs did you make when you hit issues? * What are the challenges with running your API in production? * Can the API you implemented scale higher? If so, what would need to be changed with it as you scale to 400 and 1200 queries per second? If this person has done the work this should be a good discussion and you can start to bring in some of your business or technical problems. It will be very evident whether someone has just invented metrics, or the statement is describing the work of others. I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews.
- mcenedella 6y ago
  OP here. This is exactly right: "I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews." Hope you don't mind if I steal some of your comment to use in the update of my post! :)
  - zerkten 6y ago
    Quote away!

redisman 6y ago

To me that would still tell nothing. Did you just implement 30 queries that are “get item by key” from a database someone else designed so that your job was extremely easy ?

treis 6y ago
Even if it doesn't answer every question it gives you at least some insight into the scale and scope of what they did. Sure numbers can always be fudged but it's better than no numbers. How would you write that line?
- cercatrova 6y ago
  > Sure numbers can always be fudged but it's better than no numbers. You can make the same argument for user engagement or business metrics numbers too. For most managers reviewing resumes, any number is better than none.
mcenedella 6y ago
Thanks for the comments. Perhaps I can be helpful by walking backwards from something you do perceive as valuable? For hiring conversations, what's a great one look like to you?

mcenedella 6y ago

OP here. Hope you don't mind if I borrow this for the update of my post!