Writing 02: Employment

First of all, I have to say that it has been very interesting hearing people’s experiences in the tech industry, especially as an “outsider.” At a general level, tech companies seem to expect more technical skills out of their applicants, and in some ways care less about personality or their actual character. Perhaps that’s a bad way of phrasing it. Perhaps you could spin it as “tech companies do not care less about a person’s traits, they simply care MORE about technical skills than in other industries.” At the end of the day though, it becomes more possible in the tech industry to outweigh bad personality traits with sheer technical skills, so it seems.

I’ll talk about insurance and the actuarial world, which is where I am going to find myself in. On the whole, I generally approve of the hiring process, as though actuaries require strong technical skills, they are still “business” people at the end of the day, and thus require strong interpersonal skills. It’s less important what skills you actually have, and more important what mindset you have, as skills can be taught but creating the right mindset takes time (so do interpersonal skills). I believe that this is a good approach to have in hiring, and so I consider hiring in the actuarial field to be efficient, effective, and generally ethical.

It’s interesting though to compare hiring in the actuarial field vs in the computer science field. Let me first highlight some key differences and similarities, and then I will share some thoughts on these. The first: coding interviews are fairly common in CS (which is reasonable given the value placed on technical skills) whereas in the actuarial field they are non-existent. The second: actuarial interviews are almost entirely behavioral, with any more “technical questions” being of a case study nature where there really isn’t a right answer and is more meant to showcase how one thinks, which is in contrast to CS interviews, which seem to require greater knowledge of actual algorithms and data structures (technical knowledge, in other words). The third, a similarity: the gender balance in both fields is skewed towards men, and as such there have been recent pushes to bring greater equality (which has some interesting dilemmas). Before I proceed to my thoughts, I will admit a couple of things. One, that I haven’t really had to interview in the last couple of years, as my last interview was back in sophomore year and I am not planning on entering recruiting this semester, and two, I have not had a CS-related interview, and so this is only based on my understanding given what others have said.

First, the subject of coding interviews. In CS-related fields, coding interviews seem to make sense. After all, employers want the best of the best, and the best must be able to code well. But I don’t think coding interviews are as simple as that, for a couple of reasons. First, skills used in the coding interview are not necessarily used in the job. For example, an algorithm you may need for the interview might never turn up in your actual job, so what’s the point of testing for this algorithm specifically? Second, knowledge is highly teachable, and very googlable. For example, if a person could not recall an algorithm, he/she could simply google and then copy/paste, and any information needed for a specific project can be learned on the job from more experienced people. If coding interviews then test skills that may not be needed, and could easily be learned on the job, what is the point then? It may not be just a knowledge test. What is more likely I think is that these challenges are meant to be a barometer for a person’s traits. For example, knowing a specific algorithm is not important, but a person knowing it means that he/she is more likely to have a better understanding of the algorithm, and other ones as well. He/she is also more likely to be a hard worker, as preparing algorithms for interviews is a time-consuming and difficult task. That’s why I think coding interviews where an interviewer is actually watching (as opposed to a task that is simply timed and done on the interviewee’s own time) are better for all parties, as the interviewer can delve into a person’s mindset, and an interviewee can demonstrate that he/she is a good fit, even if the coding task was not successfully completed. Thus, coding tasks I believe are not simply used as “tests” of knowledge, but rather barometer of a person’s mindset and diligence.

The second difference is very related to the first, but in Actuarial science, interviews are primarily behavioral, conversational, or at “worst” case studies. Actual technical skills are not tested. This is likely due to what is expected of people who are actually working. At tech firms, a person’s ability to code is likely more important than one’s ability to make a presentation or be personable, not to say that it’s not important, just less important compared to other fields. Actuarial science however is very focused on communication and “debating” with statistics, and as such requires a more communicative personality.

The last point is that of gender, which is a problem in both fields due to both being highly technical, which tends to attract more males than females. As such, there has been a push to recruit more females, and as a result in some ways a girl in CS or actuarial science has an advantage over their peers (think Grace Hopper, as an example). The question though is: is that fair? This brings up the issues of equality, justice, and meritocracy and the interactions within. In CS, there is an idea that the “best code” should win, thus perpetuating a meritocracy. A meritocracy though is only fair when all participants start from the same playing field. Thus, if women are actually disadvantaged in their field, they deserve to have some benefit to help them out, which would be “just” and would contribute to proper “equality”, and judging from Silicon Valley’s rumored “bro culture,” I think women are actually disadvantaged, and so the “help” they receive is justified, though ultimately it could be argued both ways.