I'm proficient in HTML, CSS, MongoDB, Node.js and Swift. I having a passing knowledge of Ruby and C++. My two best programming languages are Javascript and React.
Keys
I think one of the main principles of software engineering, and one I try to live by, is to keep things as simple as possible. You're often already dealing with complex algorithms and design concerns, so no need to make things even more difficult with overly complicated, resource-heavy code. Your code should be simple, lean and easy to read. If you start there, the rest will follow.
Key Principles:
I code at least 30 hours a week. The rest of my time at work is spent working on design reviews, scrums, meetings and other tasks to keep projects moving forward.
Areas of Strength:
There is something to be said for the predictability of working in a more established company with it's set goals and office hours. However, I must say I really enjoy the unpredictability and excitement of working at a startup. Yes, the hours are long and everything moves at a breakneck pace, but there's nothing quite like building something from scratch and seeing where it goes.
Look For:
A great software engineer has a healthy balance between perfectionism and pragmatism. Too often engineers want their code to be perfect, while losing sight of the overall goals of the project. A great programmer also learns not to fall in love with their own code, to keep a healthy skepticism until it's been thoroughly tested, making sure it is the right choice for the project at hand. And yes, I believe have the qualities of a great programmer, though working on my need to be perfect is an ongoing battle.
General Qualities
This spring- when I was working as a tech lead- I found myself in a situation in which action needed to be taken- and, given my leadership position, I was the only person available to do it. While I am very skilled at giving directions and often find myself in the position of the primary initiator- I got into a scenario that involved me alone witnessing another employee's failure to complete his assignment on time. My leadership style isn't predicated on micro-managing my teammates. It’s not like me to takeover a teammate's portion of a project or pull them off a given assignment- but in this situation- what was happening was very clear- and there was nobody else who was going to take the initiative. I ended up talking with the teammate- exposing the failure of meeting the deadline and creating a step-by-step process by which the employee could complete their portion of the project by the deadline. Looking back on it- confronting the teammate in a face-to-face scenario, was one of the hardest decisions I have made in my professional life because I don’t generally like to get involved with other people’s work- but it was the right thing to do.
Once when I was working in a startup, my tech lead hired a new employee in the middle of a coding grind. One of our most senior members went down with the flu, so we were in deseperate need of additional help. After a week of workig with us, the new hire was not willing to do the work that was needed. I didn’t like working with this individual because he didn’t ever pull his weight. Rather than make a complaint about having to work with him, as I realized it was not up to me, I simply did whatever tasks he left undone. For example, if code needed to be rewritten because this person refused to follow the team's coding etiquette, I would rewrite it. The fact I had to clean up his mess slowed the pace of our progress, threatening our team goal of meeting the deadline. In reporting to my tech lead at the end of every day, I would make note of the extra tasks I had to complete. This way, the neglectfulness of the new employee was shown, rather than me having to try to criticize him directly. That employee ended up getting fired and the actions I took actually led to my promotion. After he left the team, I was given additional responsibiliites and the project was completed on time.
I have always been the techy within my social group. As a result of having a lot of experience explaining technical issues to non-technical people, I developed a sure fire process to get non-technical people to understand a complicated technical issue. The process is as follows:
My boss put me in charge of building a series of MySql databases. One day, a group of visiting project managers with little experience dealing with MySql databases stop by my boss's office. They asked him to talk about the database situation and he called me into his office. I pulled an old presentation I used for my nephew's "Bring a Relativeto Work Day" and I provided packets with charts and graphs to complement my presentation. I focused mostly on the differences between MySql databases and MongoDb databases. I told them MySql databases would be a beneficial solution to their needs while breaking down how the components of a MySql database worked at their more basic level rather than the intricate changes in technology
My team and I built a web application that allowed customers to buy parking passes online. This prevented customers from having to wait in line to purchase them at payment terminals or exit gates. One day, A customer called, and she was quite angry that she’d waited more than two weeks for a reply from our sales team regarding a parking pass that did not allow her to leave the parking garage. I needed to address the customer’s immediate concern and find out what went wrong in the normal query response process. I apologized to the customer and took down her details, and then passed them to our head salesperson, who contacted the customer within the hour. I ask one of my web developer's to discover why the inquiry hadn’t been answered. He discovered that there was an error in the code that prevented a user from deleting old mobile numbers and an old email addresses that the customer was no longer checking. I let the customer know, and I instructed another developer to fix the code to include all of her new contact information, and then we offered a goodwill discount on her next order. The customer not only continued to order from us but also Instagramed about her positive experience, and wrote up a five-star Yelp review of our business.”
In my recent freelance experience- I was hired to complete a project for an important and high-profile client. I was offered the opportunity to add other employees to my team for the job- but instead I chose to take the majority of the work on by myself- believing mistakenly that if I wanted it done right- I would have to do it myself. The workload proved to be too much for me. The project failed the first time around- and I ended up having to hire other team members at the time when I should have had the original project already completed. Together- we did end up bringing the project to completion eventually. Bouncing back from that mistake was a huge blow to my ego- but I have learned since that teamwork- delegation and working seamlessly with others is sometimes the best and only way to accomplish large tasks such as the one I was assigned.