this post was submitted on 14 Sep 2024
12 points (92.9% liked)

CS Career Questions

351 readers
1 users here now

Rules:

  1. Be welcoming - Not everyone is a 10 YOE senior engineer. Let's all help each other.
  2. No memes - Refer to the Programmer Humor community.

founded 1 year ago
MODERATORS
httpjames
12
Resources for RESTful API Integration practice? (self.cscareerquestions)
submitted 2 months ago by Habahnow to c/cscareerquestions
12 comments fedilink hide all child comments
 

I’m doing interviews for companies that would involve API integrations. I’ve done a couple now where I was given some general API information (some intentionally unclear, some more clear) and I felt I didn’t do well. Mainly I was nervous, and felt very pressured just to understand how the different parts of the APIs interact with each other and should be interacted with. This is despite doing this for work and myself not feeling as nervous doing more common coding tests which I don’t do as much at work(thanks to doing examples on hackerrank, Leetcode helping me feel more comfortable).

So what are the resources I should leverage to practice API integrations? How should I go about practicing? Especially considering that I do need to perform in a certain way during interviews.

top 12 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 2 months ago (1 children)

Restful API is an approach that is very open to interpretations and mistakes. Meaning, there's nothing that forces a given api to be restful unless the devs were able to do it correctly. Even then, most apis are not expected to be used without thorough documentation.

To practice I would suggest:

Go over the principles of RESTful and try to understand http better ( verbs, request and response structure, headers etc...

There are many free to use apis across the web. Pick any of them, read the docs and try creating a programmatic workflow with that api. It can anything - minimal ui to help uaer interact with it or some background service that talks to the api etc.

Be sure to check the ebtitiea docs as well.

Last thing, it is fairly common to see swagger(openapi) and if the api does support it, it'll make it a lot easier-for you to understand it.

Good luck:)

[–] Habahnow 1 points 2 months ago (1 children)

Any suggestions good APIs to interact with? What do you mean by Ebtitiea doc? the documentation for the API is what I assume you meant to refer to? yeah swagger is a great recommendation of something I need to get more familiar with.

[–] [email protected] 2 points 2 months ago (1 children)

You can try this list: https://github.com/public-apis/public-apis?tab=readme-ov-file

You can even use multiple APIs in a single app if the APIs you want to use are too simple(or for any other reason).

Sorry that was a typo. I meant to write 'entities' as in api entities which are crucial to describe the structure of the requests and responses.

[–] Habahnow 1 points 2 months ago

Thanks I'll check it out!

[–] sloppy_diffuser 2 points 2 months ago* (last edited 2 months ago) (1 children)

Never heard the term API Integration before but guess I've been doing it for years including building them from scratch after looking up the term.

Internally we've always called it API Orchestration.

No idea what these companies are looking for, but I do most of the technical vetting for hiring, so maybe my advise will be helpful.

We always start at the model. We create models that act as parsers/validators for any external data entering our system (database, APIs, files). We never trust data that hasn't been parsed. We are a TypeScript shop and I don't allow any hard assertions / type casting.

We wrap every API call with a client library hiding the fact an API call is happening. It makes the API call and passes it to our parser.

When we need to transform data between two or more systems we create bidirectional transformers. These are "pure" transformation with no side effects.

We then connect it all together with controllers which house our business logic. They call our client libraries, make decisions, transform data with our transformers, read/write to the database, etc.

We use functional programming techniques so a controller is just a set of functions. We typically have specialised controllers focused on a specific resource / use case.

We lightly follow CQRS paradigms.

The same resource may have multiple models/controllers. We have a model for the client, the database, internal runtime, and view. One controller is usually focused on a single resource that maps between our clients, the database, and internal runtime model. This abstracts it away from the orchestration layer.

Our orchestration controllers only deal with connecting multiple resources, only seeing the runtime models and converting to the view model. Our handlers typically just call one function in these orchestration controllers.

The resource specific controllers are not aware of each other. This helps with cyclic dependencies. They can see each other's (runtime) models, but the orchestration layer is the only one that can fetch resource A from its non-orchestration controller to pass to a non-orchestration controller focused on resource B that needs it.

This sort of dependency inversion makes it super easy to test.

Edit: Summary...

  • Models for the I/O between external systems.
  • Pure transformers between models.
  • Resource specific controllers for mapping the same resource between different systems (API clients, Database, Runtime, etc.) following CQRS paradigms.
  • Orchestration controllers for connecting different resources using an internal runtime model and view/presentation model.
  • Avoids dependency cycles using CQRS and orchestration controllers.
  • Small, easily testable units.
  • Stateless (horizontally scalable). Not mentioned but implied with FP techniques which typically uses immutable data.
[–] Habahnow 2 points 2 months ago (1 children)

This information is helpful. How do you usually test potential hires? This is a bit interesting because a lot of this I'm unfamiliar with and seems like information that the clients I would work with would implement. Basically, I work with a software company helping others to integrate with our API. That can range from just ensuring they understand what information to expect from certain calls, down to sitting with the customer's engineers to determining why certain calls aren't returning information as expected. Regardless, this information is nice to read more about. Thank you

[–] sloppy_diffuser 2 points 2 months ago* (last edited 2 months ago) (1 children)

I don't work at a FAANG, so no leet code or tests. We also don't have the best pay. Not horrid, but probably 2/3s what a FAANG engineer makes. In addition, I don't work at a company known for software development. Our primary business is networks and connectivity.

That all said, it can be a pain to find candidates. Our functional programming tech stack is pretty niche to make matters worse just for perspective.

Interviews are typically:

  • Video conference screening by the hiring manager (30min).
  • Video conference technical screening by someone like me (1h)
  • In person technical screening/personality check panel interview (4-5 people asking questions for 1-2h with 2h split between 2 groups), followed by a VP interview (30min-1h), and a final interview with the hiring manager (30min). About 2.5-3.5h hours. 2h panel is usually only for higher level positions, 1h is more typical. We try to time it to take them to lunch if they want to go.

Technical interviews are mostly just talking shop. I have a list of topics and sample questions, but just as conversation starters:

  • Networking tech: what are sockets, DNS, HTTP(s), describe what a browser is doing in as much detail as possible when you go to a website.
  • Code quality questions: what is linting, static code analysis, formatting, etc. Ask about their editor setup to get realtime feedback from these tools.
  • Repo maintenance questions: monorepo, tsconfigs (typescript shop), transpiling, bundling.
  • Testing: unit, integration, perf, property-based.
  • Security: encryption, sanitizing data, OAuth
  • Language question: What are generics, dynamic vs static types, generators, async/multiprocess/threads, stack vs heap, recursion/tail recursion, immutable/stateless, OO vs imperative vs functional. Big-O. Lazy evaluation/monads for those claiming FP experience.
  • API: Rest, HTTP methods as verbs and resources as nouns, query/path/body params (when isn't body allowed), cookies, web sockets, GraphQL, HTTP response codes. OpenAPI/Swagger.
  • CI/CD: Tools they know, pipelines they've built.
  • Cloud: AWS questions, distributed system: redundancy/high availability/scaling, micro service, API gateway. Disaster recovery. K8s/docker. Database: SQL/noSQL, primary keys, indexes, ORMs, joins, map/reduce, etc. Linux: Probe some common commands or tasks until I find their upper limit. Data: Relational, normal vs non-normal form, one to one/one to many/many to many/DAGs (directed acyclic graphs).

What I'm looking for is someone who understands the technology they work with. Great candidates will relate the question to their experience, not give a text book response. I'll drill into more nuanced questions if I suspect someone just power studied and doesn't understand the tech.

For a junior, 10-20% familiarity with the questions is typical. For my level, 70% is ideal. I also don't ask all of them. If you have 5 years experience with databases I may spend 1-2min with some harder concepts to test the claim and move on.

The more you talk about your knowledge that's applicable to the role, the more likely my questions will be geared towards your experience.

Personal projects and a public repo will vastly boost your preinterview appearance. I will look at your code, your commit history, tooling you use, etc. This usually tells me more than any interview. I'm not looking for the perfect repo with 100% code coverage, greats docs and comments, etc. I'm looking to see how the code evolved from inception.

I look for contributions to other projects big and small. It tells me you had a problem or needed a feature and had the problem solving skills to make it happen. A big +1.

We also offer APIs which customers integrate against. We don't want our customers to have to reach out. So in that specific domain I'll ask about what can be done to avoid those calls. Great docs, FAQ, tutorials, code examples, reference implementations of a client using our APIs, tutorials to build those reference implementations step by step, etc.

Our entire back end has a simulator implementation. Clients get the source. They can test against it locally, look at the source to see what its doing, etc.

We try to provide really good error messages. If a client sends a bad request, we send back exactly where it failed to parse. Clients, through the simulator implementation, can look at the exact parser we use to work it out.

Linux experience is a huge plus. Public dotfiles gives me good insight ahead of the interview.

Personal projects don't need to be all code. I've hired bootcamp programmers who were previously a musician, a baker, and a carpenter. Attention to detail, problem solving, and passion towards achieving a goal are great personality traits.

I ask some pointed questions about AI. I love GPT, but more as a search engine replacement and not an answer book. I have a couple juniors who are really smart, but rely on it way to much. Its output never fits our style guidelines so it stands out. Its vastly hampered their ability to read code. They've improved with some interventions, but I try to sus out how dependant a candidate is on it.

Hopefully some of this word soup is of assistance!

[–] Habahnow 1 points 2 months ago

Yeah this is great information I appreciate it!

[–] [email protected] 2 points 2 months ago (1 children)

Maybe start with python, either Django REST framework or FastAPI, and make a todo app. Start somewhere writing your own API and learn what the backend feels like, then when you work with other people’s API you’ll get what’s probably happening behind the scenes and know how to read between the lines with the incomplete documentation.

I’d also say take a look at GraphQL, that is another popular paradigm that’s related.

[–] Habahnow 2 points 2 months ago (1 children)

I'll look into this. The only doubt I have is that: during interviews, its really just reading up on the documentation for a real or fake API. Not certain how useful doing the backend work would be in that situation. I appreciate the feedback regardless.

[–] sloppy_diffuser 2 points 2 months ago (1 children)

Sounds like they are testing your ability to read and digest APIs which makes sense for the role.

What are all the HTTP verbs for? What can your infer from the paths of each endpoint? Can you read the schema for each of the inputs and outputs?

Making an API and back end can teach about API design. How do you make relations? What do you do if you synchronously need to update two resources? What if your resource is an action?

Another approach is to read and try to consume some APIs. The more you practice reading the better you will be at it.

Query releases on GitHub, song information on Spotify, or the weather. Make a crud discord or slack bot that intercepts commands and queries another API to send a response (e.g., /weather). Look into webhooks and callbacks. Make a song play via Spotify every time you push to GitHub.

I use GitLab's webhooks when an issue or merge request is modified. The webhook callback is GitLab's pipeline trigger API. I don't even need a webserver. The pipeline checks that the updated issue/merge request came from a user on an issue that the renovate bot opened. If true, it runs the renovate job (dependency upgrades) via an API call. This makes renovate work like GitHub where there are checkboxes that trigger actions.

The ability to read, understand, and integrate with APIs seems to be the skill they want, so I'd practice that skill.

[–] Habahnow 1 points 2 months ago

Thanks I appreciate the advice. I'll look into those questions you've asked as some I can't answer confidently. The first 3 are more or less questions I have been asked in interviews.