Recruiters Are Your Friends, Not Food

Building relationships with technology recruiters will be one of the best things you can do for your career. Now when I’m talking about recruiters, I don’t mean the ones that don’t even look at your resume and blast out posting from a database of possible candidates, the ones you can’t understand, the ones that call and call and call. I’m talking about the good ones. The ones that call to check in, even when there are no opportunities on their plate. The ones that will review your resume for you and give you feedback. The ones that prep you for interviews and complete mock interview with you. These are recruiters.

Finding Recruiters

Recruiters are everywhere! Go on dice, monster, LinkedIn, Stack Overflow jobs, etc. 75% of all the posting are routed through recruiting agencies. Usually you can filter by recruiter only postings and apply. Apply to everything you think you are qualified for. This will get you in all the recruiters databases and this is how you insert yourself into their job finding funnel.

Try this experiment. Get onto Dice, fill your profile out fully, and upload your latest resume. Ensure you set your profile to visible. Wait. You will be getting flooded with all types of recruiters.

Utilizing Recruiters

Once you’ve found a recruiter to work with, utilize them. It is not common knowledge (based on the people I’ve discussed this with), that you can utilize a recruiter for furthering your career. I first came to the realization of the vast free benefits a recruiter can offer right before I landed my gig at SMC. I was in the dark when it came to recruiters; thinking their only job is to get you a job. Not only do they do a lot of the heavy lifting when it is coming to the actual “job search”, but they will become an invaluable networking connection when you’re moving to your next adventure.

Recruiters will give you valuable feedback on your resume. They’ll point out what areas you are lacking in, what areas to highlight, writing a good objective statement, formatting, skills, etc. Recruiters will only get paid when they get you a job, so it is in their best interest to ensure your resume is clean, professional, and relevant.

Ask your recruiter to take you out to lunch to discuss your resume and relevant opportunities in your area. Most of the time, they’ll foot the bill too! They have to deal with flaky candidates all day, so make sure you’re on time. Besides former co-workers, this is the backbone of your professional network. Having a strong professional network is paramount in your career development.

It is incredibly important that you clearly state to the recruiter exactly what you want. Boundaries need to be established so that you are not a developer getting harassed about a help desk job. If you’re a junior developer, looking to work with .Net at $55k, tell them that. I can’t tell you how many times I had recruiters calling and email me about irrelevant postings.

After the initial “recruiter interview”, you recruiter will find you client interviews. You can utilize your recruiter for mock interviews to prepare. Any recruiter worth half their weight will give you a fact sheet on the company and a detailed description of the posting at a minimum. After your client interview, the recruiter will most likely follow up, get your feedback, and give you the client feedback. Rinse and repeat.

Recruiters are your friends

It can often times get frustrating when you’re first getting bombarded with recruiters, but it is important for you to maintain your composure. Sometimes they can be relentless and won’t take no for an answer. They are for all intents and purposes a salesman for people; so, it makes sense that they will tirelessly chase candiates. With that said, always be respectful and they will be more willing to get you in to good companies at generous pay rates.

“If opportunity doesn’t knock, then build a door.” — Milton Berle

On the Importance of Design Patterns

The use of design patterns for software developers is the most important area that one must master. Design patterns are the solutions to problems which are commonly, and sometimes uncommonly, occurring throughout the course of a project. The solutions, in the context of object oriented design patterns, usually consists of the general arrangement of classes. Design patterns provide you with an easy way to create objects, control behavior of objects, and structure your code in the most reusable and robust ways. When interviewing people, I always ask about design patterns and disappointingly enough, 90% of new grads I’ve interviewed will have a 4.0 GPA but cannot accurately write an implementation for a singleton pattern. Seriously?!

During my time at MRG/Emerson, I was interviewing interns (post to come on this) and one of the interns put “Design Patterns” under his skills section. I questioned him about it and apparently his school taught design pattern theory with little to no practical implementations of design patterns. He even received an A in the class. Absolutely ridiculous! I proceeded to write a strongly worded email to the dean of his school’s computer science program, explaining how their “Design Patterns” course is inadequate for listing as a skill on their graduates’ resumes. It was incredibly frustrating that an entire organization, being that school, was ignorant to the fact that they were wasting their student’s time and money with their current course. After a few days, a response was given which in all honesty was eschewing the idea that they have a wasteful implementation of this course. He preceded to tell me that, “He could recommend a few other viable interns who would would be very knowledgeable in design patterns.” His suggested candidates weren’t any better. If you want to impress your interviewing, be able to talk at length about why you chose a specific design pattern and how you implemented it.

Reuse

Design patterns encourages SOLID principles.

  • Single responsibility principle
  • Open-closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle

The more you use other people’s code, the more you realize the importance of maintaining standards and adhering to a specific guideline. Take for instance the library available on nuget called, NBuilder. This is a unit test object creation library, built upon the builder design pattern. The design pattern dictates how the class must be implemented. We can see below, that a proper implementation of the builder pattern, as used with the NBuilder library, allows for the user of this object to have control over creating custom mocked objects.

 var customers = Builder<Customer>.CreateListOfSize(100)
        .All()
            .With(c => c.FirstName = Faker.Name.First())
            .With(c => c.LastName = Faker.Name.Last())
            .With(c => c.EmailAddress = Faker.Internet.Email())
            .With(c => c.TelephoneNumber = Faker.Phone.Number())
        .Build();

This is just one example of one pattern though. Searching in the nuget repository and throughout code on github, you’ll find design patterns everywhere. In Entity Framework alone, you have the use of 8+ patterns:

Factory Method, an Entity Framework ObjectContext provides a CreateObjectSet<T> method, which creates an ObjectSet<T> for the given type. Since those object-sets are the main approach to access the entities within a context, I would say it is also a very important pattern used in EF.
Proxy, obviously EF dynamically creates proxy-types for your entities (unless you tell it not to, or it can’t create a proxy because a class is sealed or does not qualify as a “proxyable” type).
Decorator, this might be a bit far fetched, but to implement lazy-loading in proxy-types, the property-getters of navigation-properties are overloaded, to perform the lazy-loading until requested. This is handled in the proxy type, but also depends on whether lazy-loading is enabled and the navigation-property itself.
Interpreter, EF introduced Entity-SQL which is a somewhat generalized form of SQL that also has knowledge of the object-oriented entities. You can define a those queries as strings which are then interpreted by EF and turned into provider-dependent SQL.
Strategy, looking at the various overloads of the ObjectContext.SaveChanges method, you can select from different strategies that are used to determine changes made on known entities.
Memento, the ObjectStateManager keeps track of changes made to the entities and can be used to access those information including the original-values.
Facade, exposing entity-sets as IQueryable should qualify as “a simplified interface to a large body of code”, since turning such expressions into Entity SQL and than provider-specific SQL is a big deal.
ObserverObjectContext provides two eventy ObjectMaterialized and SavingChanges. Since .NET events are an implementation of the observer-pattern, EF also qualifies for this one.

https://stackoverflow.com/a/8135609/2004122

Another less talked about aspect of design patterns is that it gives developers common language to talk about solutions. The pattern is agnostic of the implementation language which puts more focus on a strong idea design rather than getting caught up in physical technological design and language limitations. This enables the developer to be more empowered when choosing which technologies to work with for a given project.

Developers should keep in the forefront of their mind that code should be written in a reusable way, whether or not there are any current plans for reuse. I can’t tell you how many, small or one off projects I’ve had that in hindsight, I wish I spent more time analyzing the design and building for reuse.

Why are design patterns important to me?

If you happen to have read my earlier posts, you know that I worked in the field while attending school. Every project that I coded, for school or work, was very procedural in my head. My brain just didn’t have the aptitude to think abstractly about object design. Well, that is until I took a course on design patterns.

We started out learning simple design patterns. By examining the differences between creational patterns such as the abstract factory and the builder pattern, it all started to come together and make sense. Design patterns make your job easier. Anything that makes my job easier, I’m always advocating for.

The class would normally begin with the professor giving us a problem statement on the board and we would individually or sometimes as teams, figure out a design using one of the Gang of Four design patterns, and then justify our design. This exercise demonstrated that not only is there more than one answer to certain problems, but that collaborative design where there is a common shared understanding of design patterns, yields the best software designs. Out of all the classes I have taken for Computer Science and Management Information Systems, this was by far the most valuable class I have taken.

How do I begin learning about design patterns?

Here are a list of resources I recommend:

“Learning from your mistakes makes you smart. Learning from other people’s mistakes makes you a genius.”

-Anonymous

Imposter Syndrome is No Joke

The offer I had last accepted was for a company called MRG Solutions. It was a company which does engineering consulting, mainly inside the oil and gas industry. Knowing how dependant the world is on oil left me with the warm and fuzzy feeling of job security. Though this was short lived after I realized how dependant our company was on the price of the oil. The job was a junior developer position working directly under the relatively quiet, light hearted development manager. I remember in the interview, he was more excited to have me join the team than I was! After accepting the offer, I was then informed that the company was being acquired by Emerson within the next year, which I was indifferent to at my junior level.

The company was located in Sandy Hook, CT, right inside an old mill factory. The interior of the building had beautiful natural exposed wood architecture which gave you the feeling of inside a historical artifact. There was a peaceful stream rolling behind the building which was a pleasant sight to see every day while walking in to and out of the office.

The main body of work I was hired for was to support an application used by the engineers in the field, called Catapult. There were asset management aspects to the application, building bill of materials, reporting, etc. It was a behemoth of a code base.

Being overtaken by this massive codebase, I chose to reorganize the libraries a bit and refactor the code so it was easier to navigate and less grandiose. That was my first mistake working there. My manager calls me into his office and proceeds to berate me for messing up the stable code base. In hindsight, I can understand his frustration. Some new guy coming in, judging and ripping apart the work he had spent the last 10-15 years writing. It definitely was a kick to his ego.

A few months go by and I keep busy by chiseling away at the backlog for Catapult. Eventually, the COO of the company recruits me to build a new performance management system. The way the were tracking their practitioners key performance indicators was through a complicated process of extracting from the HR system, loading into a database, calling that database a “data cube”, and loading a bunch of excel reports from that “data cube”. It was a mess. From the extensive lessons learned from my former co-worker and data enthusiast Keith, I was appalled at the bastardization and improper use of our sacred passions!! But I digress.

My instructions were to take the spreadsheet and make a reporting application and dashboard using the same source data as in the spreadsheets. I ran with it (even though the “data cube” was a OLTP database). I produced a pretty functional application that looked nice within a month. I designed the architecture, chose which technologies, implemented IoC containers, and coded every line. This application was my magnum opus for this company. Catapult will live on whether I stay here or not, but my app is how I would be remembered. If it screws up when I’m gone, it’ll be “God damn Steve wrote this crappy application”, or if it is a success, it’ll be “We are so grateful for this wonderful application”. I felt immense accountability for the success of the application, which we then coined, OPIS Operational Performance and Information System.

Around this time the company started becoming Emerson-ized. We started getting added to their network, getting new email addresses, and told that we were going to be moving to Watertown. The timing was great because I was looking to move in the same time period.

We moved to this flat, ugly, bland looking building, both inside and out. The interior had white painted bricks for every wall and the distant clanging of workers in the factory. I was worried that my cubicle wouldn’t have a window so I had said jokingly to my manager, “You guys better give me a window!” To my disbelief, it worked, I got a window seat, but it was right next to the entrance. So, I was privileged to feel the cool breeze of every employee walking through the door. All in all, pretty smooth transition.

Things here started becoming pretty routine. We would go on a walk through the suburbs during lunch almost daily. I would be the primary Web developer for our section of the company and my manager would be the win forms developer. I was eventually promoted to mid level developer. In all honesty, I didn’t deserve to be promoted at the time but was in fact an HR technicality because of salary grades. That’s how many people get through the ranks of being a senior developer. Time. That is of course applicable to the “classic corporate” model of growth where you have dev 1, dev 2, dev 3 style titles.

I can say with confidence that at that moment I was experience symptoms of impostor syndrome. For those who are newer in this field or are unaware of this condition, here is the wikipedia definition.

Impostor syndrome (also known as impostor phenomenonimpostorismfraud syndrome or the impostor experience) is a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a “fraud”.


Wikipedia contributors. (2019, March 19). Impostor syndrome. In Wikipedia, The Free Encyclopedia. Retrieved 14:09, March 19, 2019, from https://en.wikipedia.org/w/index.php?title=Impostor_syndrome&oldid=888434541

Most developers experience this at some point in their career. Either they get a project that they don’t understand, get responsibilities they believe they aren’t ready for, are in charge of people and feel unqualified, etc. Utilize this feeling for self improvement. Confront your fears square on. If you feel you are lacking technically, then get off the video games and start taking courses on your weaknesses. If you feel like you have too many responsibilities, automate them wherever possible. Imposter syndrome is a temporary state of mind and all states of mind can be controlled yourself.

Though I believe in the frequency of imposter syndrome, I think the opposite syndrome needs to be brought to the awareness of people in this field.; the Dunning-Kruger effect. This is where a person has such a delusional superiority, usually to their coding abilities, which usually will get interpreted as arrogance.

The Dunning–Kruger effect is a cognitive bias in which people of low ability have illusory superiority and mistakenly assess their cognitive ability as greater than it is


Wikipedia contributors. (2019, March 14). Dunning–Kruger effect. In Wikipedia, The Free Encyclopedia. Retrieved 14:19, March 19, 2019, from https://en.wikipedia.org/w/index.php?title=Dunning%E2%80%93Kruger_effect&oldid=887735939

In my opinion. a way to combat this is by maintaining a learners mindset. Understand, that it is physically and metaphysically impossible for know person to know everything and chances are, you’re wrong anyways. Refocus into team orientation rather than the individual orientation that is the root cause of this effect. You believe your contributions are of more value than everyone else.

“The only true wisdom is in knowing you know nothing.” ― Socrates

Lessons Learned:

  • Just because you are technical, doesn’t mean you should focus only on programming. The industry you’re in is just as, if not more important than your technical work.
  • Communicating an idea effectively is more important than fast execution of that idea.
  • All promotions are deserved, even if you didn’t feel like you deserved it.
  • Being aware of imposter syndrome and the Dunning-Kruger effect reduces its’ occurrences.

Dreaming in code

So after I had returned back to the main office in CT, crunch time was on. We had gotten all the information we could get from them and now the actual development work needed to be done. I was busy from the second I walked in the office until the second I left and it was amazing. Every day I was learning something new, figuring out clever ways to efficiently query the data warehouse, and trying to understand this complex world of deducibles and special billing to end-stage renal disease. Who would have thunk kidney disease gets billed differently?

Eventually, this project got pretty monotonous and repetitive. Luckily for me, a new project was brewing for me at Connecticare, in Farmington, on-site. I was on a team with my last projects’ manager, Tracy and a business analyst. We were tasked with creating an application that the insurance company would be using internally to audit claims. The requirements were very prescriptive. I had to use WCF. I never used WCF. I had to use Asp.Net Web Forms. I made 2, maybe 3 basic website with Asp.Net at the time. I had to use their enterprise level bit masking security scheme. What the hell is bit masking?!

During this first 2 to 3 weeks of the projects inception, I spent a whole lot of time taking courses on Pluralsight and reviewing sample programs that use their prescribed enterprise architecture. The architecture of the windows services was so overy complex. Death by architecture.

At the time I was experiencing serious symptoms of imposter syndrome and was dreading figuring this crazy architecture, but now I understand what the enterprise architect that was enforcing these standards, was actually trying to accomplish. Reusability, autonomy, and a standardized service inventory. I soon got the hang of it and was on my way to creating what was in essence, my own project that was going to be heavily used. Yes there was a PM and a BA who assisted in requirements and documentation, but the product itself, was mine. Under these supposition, I wanted to put my all into this application. I wanted to work harder on this than any other school or work project. This was my legacy at this company and I didn’t want that to be a half assed job.

To accomplish this, I was working 70 hour weeks. After about a month of that, I came to the realization that continuing to put in that many hours would damage both my physical and mental health. I started dreaming in code. It was terrifying at first but then the answers I was looking for would start coming to me, which of course was to be desired. Physically, I started gaining weight and just generally feeling lethargic and losing energy. I started cutting back my hours to around 40-45 a week and those issues started to dissipate.

My application was pretty well liked as far as I know and I was content with the job I had done. It wasn’t the prettiest, but it was exactly to spec on the approved mock ups. I then had to hand off my creation. My baby. What I had worked so hard to create. I spent about a week meeting with one of the Connecticare employees who would then be responsible for maintaining my application. To be honest, he seemed just as offput as I when reviewing the architecture that was mandated. But I did my best to cover everything about the application that I could.

When that project was over, I was moved to work on a project for Blue Cross Blue Shield of Vermont. This was a DB2 conversation project and I was intrigued because I had never used DB2. About 2 weeks into the project and I started dreading coming to work altogether. Not necessarily because of the work, but I was doing another project solo. I wanted to work on a team. To feel valued. So I started interviewing at different companies. I found one in particular that would cut my commute in half and about 50% more in salary. I figured, why not?

I leave you with this final note: Never stop interviewing. The market is constantly changing, new interviewing techniques come out, new technologies, etc. You need to stay current. You need to stay relevant. If you’re not getting harassed almost daily by recruiters on LinkedIn or phone calls, you aren’t putting enough effort into your career.

“There is no illness that is not exacerbated by stress.” ― Allan Lokos

Lessons Learned:

  • Pluralsight is an amazing resource for both technical and non-technical folks.
  • Sometimes you need to pull a lot of hours but be aware of how your body responds to that much stress. Long days like that aren’t sustainable.
  • Don’t be afraid to interview at other companies. This is to be expected if you are a valuable employee.

I shot a man in Reno just to watch him die (First business trip)

I started my first non-intern development job at SMC Partners in Hartford. The company is a systems & management consulting (SMC) for the health insurance industry. Keep in mind at this time, I was just fresh off my first internship and had absolutely no knowledge of the health insurance industry besides going to the doctor for my annual physical with a $20 copay.

I was commuting roughly 60-90 minutes depending on traffic. This didn’t bother me too much because at the time, I was beginning the work for my Bachelor’s degree at Central Connecticut State University, which is located in New Britain — about 15 minutes from the office. I’d be driving basically that far anyways, so it worked out.

The health insurance industry is incredibly complex. This is in part because of the differences in law between state insurance regulations and the other part being because of the various business areas that encompass the entirety of health insurance systems. Overwhelmed with the complexity of my upcoming work, my manager reassured me that, “If you can figure out the health insurance industry, you can figure out any company out there.” That gave me some piece of mind at the time and was some pretty decent advice.

My second week at this job and I was assigned to assist with the development from the ground up of an enterprise data warehouse for Hometown Health in Reno, Nevada. Some of the tasks that needed to be completed were designing the ETL process, designing the structure of the tables, and consolidate & parameterize approximately 550 reports. I was told we were to use SQL Server Reporting Services (SSRS) for the reports, which at the time was brand new to me.

I was informed the following week that I was necessary for us, my manager and I, to go to Reno and visit the client on site. This is amazing! I just started and they are going to pay me to travel! I was beyond excited for this. This was about a month away, so in the meantime, I performed analysis on the reports and cataloged them into an access database.

When I finished my Reno prep work, I assisted a fellow team member and data architect, Keith Evans. Keith is a humorous irish guy that was incredibly well versed in all things data. He taught me the foundations of data warehousing, OLAP databases, and ETL. He taught me that a star schema is preferred over a snowflake, he taught me about abnormal database normalization such as 5th normal form and higher, and taught me the power of SQL Server Integration Services (SSIS). I don’t think I enjoyed talking with any other co-worker as much as I did with him. I will be forever grateful for everything I learned from him because what I learned from him was incredibly unique skills to have with someone with my level of experience. And the most important thing I learned from him was that M&M’s from Ireland taste better than the American variations!

The time had come for my flight to Reno. We were only staying for the week but some clean mountain air would do me good. When we land, I discover the airline lost my luggage. So I had no clothes, no ties, no business wear, and was informed that the client perfred consultants to wear business formal. My nerves are at an all time high. Luckily, after getting the rental car, we drove to Marshall’s and bought a few outfits until my luggage was found.

The next morning we go to the client’s office after a restless night of sleep. This was my first ever real client meeting and had no clue what to expect. My manager begins discussions with the client and asks me to take meeting minutes. I never liked taking notes. Not in school. Not in work. But as a subordinate, I had to comply no matter how poor my notes were. I was so attentive to the content of the conversation because I was afraid to miss anything and disappoint my manager. It was exhausting hanging on every word everyone said. Is this what being a developer is like? I thought I’d be coding most of the time but here I am, taking notes for hours on end.

My luggage was found and delivered back to my hotel room at the El Dorado in downtown Reno. Now that I had my things, I was able to relax a little more and started exploring the casino.

Most of the week I spent at the client’s office, fighting off nose bleeds from that clean Tahoe mountain air, taking notes, listening, and meeting all the key stakeholders. Even though I did less than an hour of coding my entire trip, I learned the most about what it means to be a consultant. I left Reno, re-energized, reinvererated, and ready to learn everything I could in both the business and technological spaces.

If you think adventure is dangerous, try routine; it’s lethal.

–Paulo Coelho

Lessons learned:

  • Commuting more than 30 minutes one way is not sustainable for a long time.
  • Complex industries make development work more interesting.
  • Never check luggage on business trips.
  • When at higher altitudes, drink more water.

Poem by Jack Kerouac

The world you see is just a movie in your mind. 
Rocks dont see it. 
Bless and sit down. 
Forgive and forget. 
Practice kindness all day to everybody 
and you will realize you’re already 
in heaven now. 
That’s the story. 
That’s the message. 
Nobody understands it, 
nobody listens, they’re 
all running around like chickens with heads cut 
off. I will try to teach it but it will 
be in vain, s’why I’ll 
end up in a shack 
praying and being 
cool and singing 
by my woodstove 
making pancakes.

I read this poem today and enjoyed it thoroughly. I’m usually not too interested in reading poetry but this really resonated with me and where I am in my life right now.

Learning Corporate Culture

After getting my first offer to get paid for actual development, I was elated. I couldn’t wait to start making a name for myself and building innotivate solutions. Keep in mind, I was still pulling in 38 hours a week at the grocery store, full-time school, and this internship which was 40 hours a week.

I began the internship at the Housing Authority Insurance group and was placed in a software subsidiary company called Housing Systems Solutions. They positioned me in the team responsible for taking a popular system that was widely used amongst housing authorities, and reverse engineer some of those features inside a new, modern product. To be blunt, that task was daunting for a brand new intern. It took my team 6 months before I even started to get the code for Midas to even compile. It was written about 8 years prior in Asp.Net web forms. I believe it was .Net framework 2.0. For the first two weeks of my job, my tasks was “figure out how this works”. It was the most boring work to a fresh developer. I wanted to write code!!

My dissatisfaction didn’t go unnoticed. Eventually, I was given some tasks concerning the database. I was delighted at this because I was currently taking a database class focused on SQL Server at my community college; so I wasn’t completely lost. My manager gave me what would’ve been, 1-2 days worth of updating stored procedures but with a little googling and some regex, I was able to complete the task in 30 minutes. My manager was shocked and incredibly pleased at the speed at which this was completed.

I often times would talk to a friendly, talkative contractor on my team named Muzzy. He was an incredibly gifted developer but he had an very apparent stutter that made longer conversations a little cumbersome. Him being an contractor and not a salaried employee, he was not under the same loyalties as the rest of the company. He was on contract and was incredibly aware of the separation of employee and contractor. Having been a contractor at Northeast Utilities gave us things to bond and talk about since I understood, at a basic level, about contractors being “outsiders”. My experience with Muzzy was education to say the least. He mentored me in his own way, telling me things like “don’t drink the red kool aid”. Meaning, don’t buy into the corporate culture that was almost cult like at that place. Dissatisfaction started to grow as a saw a preference for politics and procedure over logic and reason. We were a god damn software company and we were getting bogged down with corporatism, just like Muzzy was warning me.

The main developers of the application were located in Belarus. If you’ve never heard of it, it is on the European side neighboring Russia. A tiny poor country with a unique Belarusian culture. I asked my managers, “Why did you guys outsource to Belarus, everyone uses Indian sources?” His response, “Indian developers always agree with everything you say. You tell them to do something, they do it. There is no push back; they aren’t thinking, they are doing. The Belorussians will question whether you are making the right decision for the good of the company.”

This was my first entrance into a distributed team. We practiced agile scrum and had the Belarusians on the conference line every day at 9am (5pm for them). They often ignored what our project managers suggested and did there own thing. They had an attitude like, “We’re the experts, do it our way.”

Every few weeks, a couple of the business analysts, develops, or architects would come in person to visit. During one of the visits, the lead architect on the Belarusian side, tasked me and Muzzy with creating a stock ticker application in Asp.Net MVC 3, Jquery, HTML, IoC container, etc. I had never used so many different concepts and technologies at once. I was overwhelmed with anxiety of the unknown. Imposter syndrome, feelings of not being smart enough to finish this application; feelings that I am a fraud. But Muzzy and I rallied and took on the this fool’s errand. The rationale for having Muzzy also work on a sample application, was to help demonstrate the capabilities of MVC’s scaffolding and code conventions. We both made pretty weak applications but proved to them that we were capable of contributing to the actual software product they were trying to build.

This was all in the time during which I’m realizing the type of corporate culture they had at that company does not match with my needs which enable me to thrive. Individual needs are often overrun by the needs of the company as a whole. I do not like that one bit. So I began interviewing at many other companies. I was tired of the indirect disdain that senior developers showed towards interns. That their work is less valuable, that they are less of a contribution.

I eventually found a company called SMC Partners in Hartford, CT. I literally had no “real” development experience. I haven’t wrote a single line of code that had seen production. The interview seemed to go on forever — 3.5 hours to be exact. I met with 2 developers, who then passed me onto a manager, who passed me onto another manager, who then passed me onto the CEO. This was unlike any interview I had ever experienced because whether it was intentional or not, it had a dynamic feel to it. The interview was long but the content of our conversations were free-flowing and non-monotonous. I could tell right away that this company would help me grow into my career.

That same night, I received an offer letter with a salary much higher (in comparison to the $20/hr as an intern), that I couldn’t have dreamed that it would be this easy. I was so excited, I didn’t even think to negotiate and eagerly accepted the offer. That was my first big mistake. Always negotiate. Know your worth. Do your research. Research the role, research the company, research what the company pays that role. After, ask for 10% more than what you see. Managers and executives are given a lot of wiggle room with salary negotiations and will respect you more for knowing your worth.

Lessons Learned:

  • Spreading your focus seems like a good idea in the moment to accomplish a lot. Be mindful of getting burned out.
  • Never call a Belarusian a Russian. Two different cultures and they will be offended.
  • Consider the culture of outsourced work. It will be embedded into your project.
  • Always negotiate. They will never offer you what you’re worth, you need to tell them your worth.

All our dreams can come true, if we have the courage to pursue them.

– Walt Disney