As a software engineer, I didn't learn about programming until I was in college. During my freshman year in college I took an introductory programming course. I was going to be a chemical engineer that was my plan when I started out. It was like programming so much I switched my major, I also didn't like chemical engineering that much. So I switched Major from chemical engineering into a different major like financial engineering for a bit. I realized I enjoyed programming more than anything else. So I switched into a computer science major at the midway of my sophomore year of college. From there I really worked on getting technical internships. I was able to get a product management internship at the end of my sophomore summer than my junior summer interned at Pandora like the online radio company. I think that was like the year 2016 and now I am a software engineer full time at Medium. I've been here for about a year and a half a little more than that they started off in 2017. A lot of what I think brought me here is a combination of having good training. When I was in college taking a lot of programming courses and being very proactive in interview stuff. I was definitely always on the interview grinds. Talking to companies and trying to make sure I got myself prepared for interviews for my junior summer. Then doing the same thing for my senior fall of college. Just making sure I got a bunch of interviews over and over again, to set myself to get this job and then I've been here ever since.

I normally get to the office around like nine o'clock or nine-thirty then leave at six or six-thirty and that's pretty chill. I'll talk about responsibilities and decisions. I would say maybe on a good week, sixty percent of my time will be coding. We have a lot of product to do for a given given month. I try to spend a lot of time on the grind and get stuff done. I always have some meetings that we have to get in sync with other teams about what work we're doing that effect of a team, things like that. What was that role model? Are we hitting our key results for the quarter? that kind of stuff. So a lot of meetings are about how we're doing as a team and how we can keep moving in the future. Then the remaining forty percent is probably taking interviews. Medium is a company that is growing pretty quickly right now. I just came out of an interview actually so a lot of what I have to do is interview other people. I have to ask them questions like are they fit for the Organization? Are they technically capable? and I think there'll be other weeks where that changes that maybe we'll have more meetings because that's the way the week is will be suddenly trim to swap with interviews and that will be rough. A lot of the time I can spend might be to work coding which is good like I enjoy coding most and I want to contribute with the technical standpoint in terms of decisions. I wouldn't say I'm a super junior engineer. I do have a pretty strong voice in the technical implantation of things on what we would call if I see an individual contributor. Most decisions I make around are about how we influence something, why we implement it or what props I think we should pursue, why certain things might want to prioritize talking to my product manager about that. I think there's another set of people that make more people decisions, like where we're looking to hire, what teams will get the next hire and things like that. Who we're trying to promote things like that's a more of a commander decision. The decision for the managers and for me, it's more about purely technical decisions. Like what we're trying to blend in the best and most efficient way

I think languages are an important part of no matter what you’re doing, the languages we primarily use node so JavaScript, in addition to node right now a lot of go too, go have a lot of advantages over node in terms of performance like those multi-threaded nodes is type safety good. We use to go in a lot of our more micro servicing stuff, for node I wouldn't say legacy coded medium but historically has been more of a node monolithic service. We're trying to spend that more to go services, which is kind of like in vogue right now but go is a really nice language, I really enjoy it. For data pipeline stuff slash machine learning thing we use a lot Scala so the Scala stuff is basically heavy-duty computation and building off of that, I can talk more about the framework to use so especially in Scala rely heavily on spark for handling very large data sets and medium we have the easily million or two people coming today to this site so it's a lot of data we gather and to be able to use that to make the most informed decisions we're using very high-pressure Scala jobs that rely heavily on a spark, what's it called, parallel computing and things like that. In addition to that, I'm trying to think mediums also primarily Amazon Web services an AWS shop which means that all the databases we use live in AWS include things like Dynamo DB which is a no sequel database. There's RDS which is a relational database system which is my sequel database and Amazon hosts. Cashing stuff we use RDS for a lot for that very high performing with the memory cache system. There's also for a notification email stuff, there's SQS Simple Queue service, which we use to basically, let's say, I want to send an email out on medium. You'd emit an event, sending emails to this user that goes to a queue we have different servers there. Pulling those queues every few seconds or so are many time to second rather and then you pull the event off the queue. You sent it to a different server that will then process whatever you want to do for that particular event and send email out to the user. Think about queuing systems like SQS like how those queues function and here’s the last thing I will address. One thing I found about being professional software engineer, I don't use many of the algorithms that I learned in school I thought I would. I've never seen a red-black tree after I left college. I don't think about this sorting algorithm over that sorting algorithm the vast majority of time, but the closer I come to that I feel do I want to use the staples order or not because order may matter in some cases, more than others but I would say it's more around the data structure usage like it's obviously very useful to know how hashing works or how a lister to works but not a lot of them popped up in my daily life. A good question. So most our machine learning stuff is in Scala. AWS going back to the U. S. there's a service called Stagemaker that provides libraries and a bunch of languages, scala included, reading test different algorithm HG boost is straight out of the box. We don't use PyTorch I don't think TensorFlow supports or maybe it does support Scala I haven't checked at all but we want to use more python for machine learning stuff but we haven't gotten around to that yet. We've been playing around with some notebooks and stuff to use python but all of the machine we’ve been using for production were trained to be around Scala job but as we invest more machine learning which were definitely doing as a recognitions company. We're going to start playing around with what was provided out of the box by AWS. There's a lot of different algorithms to try there and it was about understanding the map. I'm the way a neural network, for example, is important but it's still for us more about having production ideas like how can we be constantly training different algorithms in a safe and easily understandable way. I'm trying to think, I'm a little bit aloof from the NLP part of what we've been doing. I know in the past, we've been using word evictors and try to extract some more understanding of stories based on just the raw text. I'm not quite in touch with how those efforts have been doing but we have had efforts around that just how do we like a lot of the ranking model we use more metadata and we're still delving into what can we do to just use raw post text to represent to understand what's going on but I think we're still making advancements on how that’s going to work and it's still an ongoing process for us.