Alex Mukasyan Reading 02 Response

Over the past summer I interned at a big data company up as a data engineer. When I applied for the internship the skills which I listed most prominently on my resume were my ability to learn and efficiently use python packages as well as write complex SQL scripts. When I came in for the interview I was sat down in the office of the CEO with the CEO as well as the head data scientist. The interview started with general questions about the classes I had taken, how I perform when working with groups, what projects I had worked on and the problems and solutions I found and came up with for those projects. After 15-20min of that I was thrown for a loop when I was asked if I would be ok with doing some technical questions to which I agreed. Just like the stories in Why is hiring broken? It starts at the whiteboard. I was not given a computer to do these problems, but was given a whiteboard wall and a dry erase marker. Fortunately for me, the questions asked weren't about algorithms or how to invert a binary tree, but instead given a made up database, how would I most efficiently get a certain subset of data and do some minor analysis on it. The coding questions were all for SQL and it tested my ability to write nested queries, different built-in functions, and general script neatness and organization. I was confident in my ability to write anything in SQL so I went up to the board and wrote out what was expected. I was asked to explain the code and was questioned as to why I didn't do one of the scripts with a "having" clause instead of the way I had done it, to which I just replied that I had not heard of it and that answer was accepted as fine. As you can probably tell by the first line of this text, they must have liked me and a week later I had an offer! There were really no surprises, other than not knowing it would end up being a technical interview, to me because they both had my resume in their hands and asked questions that directly related to it and then the coding questions were completely fair in my opinion. Of course it would have been better to have a computer to piece together a script on where I can see how my results returned from the table change based on what I add to the script, but I visualizing tables isn't too difficult for me. Since I didn't know about the technical aspect of the interview I did not prepare for that at all and I have total confidence in my people skills to not need to do interview prep for behavioral questions. The general interview process is pretty flawed based on what Quincy Larson wrote in the article I mentioned above. It seems almost like any other test where you are just expected to be able to regurgitate information/algorithms in a timed and stressful setting that you may never actually use in your work. This method does not prove that you know how to code well or efficiently, but just that you happen to have a really good memory. From my experience this past summer, I would never need to write perfect code in under 10-15minutes, I always have the internet at my finger tips so memorizing algorithms isn't necessary, and I WILL ALWAYS HAVE A COMPUTER TO DEBUG MY CODE WITH. It makes no sense to be to test whether you are a good programmer under conditions that you would never actually deal with at work. I believe the best way to determine the hire-ability of a candidate would be to look over their past projects both from class and personal as well as to ask coding questions that demonstrate an understanding of general syntax, structure, and rules. After 4 years of CS I think we all know how to code, just not things like dijkstra's algorithm on the spot.