Homework assignment: They will ask you to create a library for their payment API. This task is pretty straightforward. However, it's a lot. From this assignment, you can tell that they don't assess your technical skill and ask you to invest tons of time in the beginning, then their reviewer will just say, "missing integration test," and then reject you. After the home assignment, they'll discuss this for the next round. Just like other reviews. It's not worth your time. They're not interested to see your quality. I abandon the test since I'm pretty sure with this kind of test, anyone can pass with just extra effort.

Would not reccomend. Very streamlined process. I was approached by the HR via LinkedIn; they were extremely polite and described the position and the entire process from start to finish. It begins with a take-home exercise, a review and (if you passed the review) three quick technical interviews. There is no problem if you do not know their commonly used language, Golang. Apparently, they care for the talent and not the familiarity in the language which is an amazing "thumbs up" for company culture or at least that is the impressions you get in the begging. I submitted my exercise, and they replied in exactly 5 days. When it came to my review, my code was well written, documented and well tested and the feedback was positive about it. But the assignment was rejected without a further discussion for the below reasons: - Not liking the way data are passed into functions (in context you are asked to learn the language and get the job done) so using method A or method Z should not matter. - No retries policy implemented. This is a dealbreaker. Arguably, they create a myriad of services doing payment processes, of course they would want a standalone policy for each process, but they should give more context on what they expect. Retries policy are commonly handled manually. - Not enough assertions in the Create Response. Assert every single variable. That is a quite ridiculous statement to reject an assignment to. My final verdict, quite unfair handling. It is quite possible that they have passed lesser assignments just for the retry policy as it is quite important internally for the company but that does not judge a good software engineer. They should be more objective with their approach. In the code assignment they should judge code and ability to cover the assignment. Just for context, you are asked to learn a new language, create a package for that language, read their API documentation, make integration tests and finally have it containerized and tested against a fake version of their API in a provided docker-compose. So, outright rejecting an application from the coding assignment with mixed feedback is quite questionable. Knowledge should be judged in the technical interviews. Honestly, would not recommend. The impression from the engineers was like being "human-robots" - missing the forest for the tree. This is quite a red flag.

I was referred by an ex-colleague who already worked at Form3. After referring the recruiter sent me an e-mail for an initial call. It was a nice and easy going conversation and got really excited by the fact that she was confirming what I already knew about their values, how they work, what life of a senior engineer looks like at Form3 etc. After the first call I've got a take home exercise to implement an API Client (in Go) for their Fake Account API. This is where you can show your quality (even though the exercise itself is not that challenging), you can show that you understand best practices, how to test your software and how to make it readable and understandable etc. After finishing your take home exercise an Engineering team of Form3 is gonna review the code and this code will, after a short introduction on Form3, be part of the discussion in Part 1/3 of the next interview steps, where you can explain your approach, your tradeoffs etc. But this depends on the review of your code. One other thing I liked about their approach is that they don't mind if you're not experienced with Go (as long as you write that in your README). They will take the lack of experience into account, as they're looking for problem solving ability and engineering standards. Interview part 2/3 is about System Design and how you would change an architecture if certain requirements would change (how would you plan for fault tolerance, resiliency, high availability, consistency etc.) to see if you understand the fundamentals of distributed systems. The final part is a debugging exercise where you're simulating an on-call rotation. You'll get scenario based questions based on an microservice architecture diagram and get to ask the interview all the questions you like (what's in the logs, what metrics are available, other characteristics that may lead to finding the simulated issue in the scenario. Before the aforementioned interview takes place, the recruiter will reach out to you to make sure you're well prepared and know what to expect. For some companies every candidate is just a number on the list and for some companies you're a person they care about and they want to give an equal opportunity. The latter is the case with Form3. This is something I really liked and many other companies could take this as a good example to learn from.