Technical coding interview is too basic, requires processing a tabular dataset which doesn't fully evaluate the candidate's ability in problem solving or programming. Second interview is system design. Interviewer was looking for a deep knowledge in specific AWS tools. The job description doesn't specify these tools as a requirement. The people team need to learn how to write more specific job descriptions to avoid wasting the interviewers and interviewees time.

During the initial call with an in-house recruiter, it became clear that he was unable to provide any information about the role. He had to look up the salary information for the role while we were speaking, after telling me a salary that was 20% lower than the value the external recruiter had told me. Oh well! I trusted that the engineers I spoke to later on would be able to answer my questions about the work. The technical interview for the ML engineer role was basic data engineering. There was no spark of anything interesting or algorithmic. Don't expect to discuss ML or deep learning. I asked at one point about the balance of work between ML and data science in Faculty and was astonished to hear that the data scientists are the ones who research and train models, and ML engineers are the ones who deploy it to prod. Based on this, I think their idea of a senior ML engineer is more like a data engineer. I got the impression from talking to the two engineers that Faculty's dev environment is a bit ad hoc. We were doing a kind of pair programming exercise. To import some data I wanted to use the csv format, because it is more closely integrated with Python libraries, but was told that I had to use Excel. The interviewers asked me where I would store data for ingestion into pipelines. Apparently it's Excel spreadsheets again. No matter that in many years of working as an ML engineer I have never thankfully needed to use Excel to handle my datasets. One interviewer seemed to have a 'box check' approach, in which he called me out for giving suggestions that weren't exactly what he would personally do, or what Faculty actually do. Fortunately I had experience with the python library required for the task, but if you have not used this one library then I don't see how you would proceed. After the programming part, we had the standard chat about ways of productionising the solution. In my current job, I am heavily involved in maintaining a robust CI system for containerised testing of ML applications. My experience was met by some confusion. I had to describe a system that met the interviewer's very precise expectations for moving Excel files around on a desktop and basic unit tests. Though I got unlucky with the interviewer, I got an insight into how Faculty, as primarily a government contractor, share the same clunky, legacy tech as their main client.