langsa

where are you applying that does NOT ask these types of questions? passing one to two rounds of LC type questions before going to the on-site seems like its the standard now

I think the most important trait of any CTO is to be technical enough to understand what the best choice of tools to use is to accomplish the goals of the business you are running. You will be doing all of the coding at the beginning since your co-founder is not technical, but the important thing to remember is that the choices you make now while acting as the only developer at the company will greatly influence decisions you will make later once you are able to do more CTO level duties (how many devs to hire, how easy it is to find good talent to hire, etc…)

It’s easy to just keep being a developer and making choices on how the tech stack works based on things engineers care about, but you need to be able to say no to things that don’t make sense for the business. The new engineer wants to rewrite the API in a language that no one else is familiar with for performance reasons? No. The team wants to go to a micro service architecture before you have product market for? No. There will be some cases where the answer is yes of course but it should be justified why this is needed and you need to be able to understand technically what the impact will be of each decision.

I have been seeing this as well, it seems like the “gotcha” levels at even the early stage of interviews are at an all time high as well. A few years ago getting the “gotcha” part of a question was mostly icing on the cake as long as you could solve the rest of the problem.

It seems like there is just such a massive influx of people applying for the same positions that companies can be extremely selective, so it’s not that you are doing poorly in the interview necessarily but there are much higher chances of a few people acing the interview now

As others have said, the market right now is incredibly tough for job seekers now and especially so for junior candidates just looking to get their foot in the door. I have confidence the job market will start to get better in the near future, but who knows.

For now, start searching for roles in companies that are entry level and might write or maintain a little bit of code as part of the job description. These can be tricky to find, but can often be listed under things like support specialist, marketing operations, solution engineering, etc… and apply to as many as you can.

Even if you don’t write any code in your first role, look for opportunities to do so any chance you get.

I started out this way and tasked myself with rewriting an internal meeting tool the company had neglected. I used that experience to help sell myself to teams looking for new developers, and it’s how I got my first SWE job.

This is an interesting use case, I could see why GraphQL would be useful here where the contract between frontend and backend modules is not known in full and can change often.

Out of curiosity, is the reason for the contract between these modules not being fully known / being able to change often because of how your company wants to use them or is there another reason? I'm just wondering if the reason for this is wanting to be able to reuse modules across different projects for multiple clients or writing integrations for other tools or something totally different.

I agree with you there, having GraphQL force adherence to a schema is definitely a good thing for a larger team, but smaller teams will probably get bogged down without previous experience

Thanks for your reply, I would love to hear more about which one you prefer in general REST or GraphQL, or if you have different situations where you choose one or the other and why.

Here were some of the things I noticed when comparing to REST:

  - Caching can become a nightmare and requires a lot of effort to get working correctly for non trivial use 
    cases / you cannot really use the already "built in" cache control headers in the browser with GraphQL

  - Another caching one, but you almost are required to have some kind of server side cache in addition to 
    the client side cache, it can quickly become disorienting trying to figure out exactly where something 
    is cached and why, or why you are getting stale data, etc...

  - Some abstractions in GraphQL can make the code hard to follow / read in my opinion (data loaders for 
    example) and also make it hard to follow where the data is actually coming from especially in federated 
    subgraphs

  - Error handling in GraphQL can be really unintuitive and more work is needed to not have the error 
    response come back as a 200 status code (or handle it correctly if it is an error inside of a 200)

Mostly comparing it to REST. The main turn off for me personally is it really seems like you have to reinvent the wheel to get caching to work correctly with GraphQL for non trivial use cases. Not saying that it works perfectly out of the box if you choose REST instead, but you can get pretty far without needing to optimize anything.

Why do you prefer auto-generated GraphQL clients?