I recently interviewed with Apella and while I like many of the people I talked to, I have some serious concerns about both their engineering situation and admin. I had to follow up no fewer than 4 times to get responses and to set up my technical screen. On the actual technical screen day, I realized I had never been sent a zoom link so I emailed multiple times the day of, only to finally get an answer once the scheduled interview was supposed to have started. We were forced to reschedule. As for the actual technical, I think these people were well intentioned but are in over their heads. They couldn’t produce any working code in time for the technical so they were forced to ask me to “imagine” my output and describe what it would look like. This was after not giving me a leet code style problem but rather a contrived API formatting problem with a fake data model. I can totally respect not doing leet code style problems but I think as an interviewer it’s important to know whether you’re choosing not to do those problems, or unable to judge those problems because you wouldn’t be able to do them yourself. Again, totally respectfully, I think if you’re going the API example route, you need either minimally working code or code that is meant to be able to run after the candidate adds to it. Neither of these was the case here. Furthermore I truly respect their choice to try to be language agnostic but I don’t actually think the interviewers are familiar enough with Python or interviewing to really do that well. Among other things, my interviewers did not know what I was talking about when I brought up: - time and space complexity - the fact that pulling from a hash map (a dictionary) is significantly faster than pulling from an array, even a sorted array - that an object, a hash map, and a dictionary all have the same syntactical structure in Python - that typically API output comes either in a json of objects, or a list of objects and that both are valid output depending on your situation. I would not recommend any traditionally marginalized engineers attempt to work here, especially less experienced ones. The system level issues at a place like this can sometimes be addressed early on if you have some experienced engineers understanding what the dynamics are doing, but I don’t really think these people know what’s going on at their own company. I think they’re well intentioned but not actually experienced enough engineers to know what kind of signals they’re sending out or to look at themselves critically. As anyone who’s worked in software engineering knows, working iteratively (with actual output) is far more common than not doing so, especially after the architecting and design phase. The only other company that asked me to imagine my output because they couldn’t actually produce working code ended up having major systemic issues and being a toxic environment for traditionally marginalized engineers.