Forem: Anna Simoroshka

My Interview Experiences

Anna Simoroshka — Sun, 10 Feb 2019 18:57:13 +0000

Every interview process is different and often it is difficult to imagine what one can expect, especially if you are a beginner or generally don't go through interviews very often. I decided to share my experiences with technical interviews.

All of the interviews except the first one happened in Finland.

A talk over a cup of coffee.

I told a few things I was doing in uni and got a part-time job without a contract. Shortest and easiest interview, the worst job which drove me out of the industry for years.

Whiteboard interview.

This one was for a summer internship at a university. I was asked about a few simple algorithms and I had to come up with some data structure for the base of the future project (building animations in javascript).

Paper programming.

It is almost like a whiteboard interview but messier. I was asked to write a function to calculate Fibonacci numbers and that was it for this part.

Home tasks.

I was going to be a graduate with little experience and a desperate need for a job, so I gladly took every opportunity to show I have some skills. I got my first full-time dev contract this way.

The best thing is when you get good feedback on your work. The worst is when the feedback is simply "you are too junior" or "your code quality is below our standards". Or even simple "sorry, but we decided not to continue with the process". I understand it might be taking some time to write feedback, but so does the homework (and a lot more).

Technical discussions.

Usually, all technical interviews have this in one way or another but sometimes it is just that and nothing else. No tasks and problem solving questions.

This type, if you are a junior, can be a bit stressful. I was bombarded with all kinds of questions from different areas, to probe my knowledge. It is easy to lose confidence in yourself when you answer "I don't know" too many times. It is nicer when you actually know some things well and have at least heard about many other things.

One, recent, was a bit weird. Most of the time I was listening about their system and asking questions about it. No one tried to specifically test my knowledge of anything.

Code challenges / pair programming.

This is the most challenging but also the most fun, in my opinion. I had this type of tech interview twice, but in the same company. I had to write code in a shared environment with some scaffolding for the task and tests needed to be passed while thinking out loud and asking questions if necessary. Tip: it is much better to bring your own laptop to avoid additional stress because of unfamiliar layout/OS.

I failed the first one because of little experience with modern javascript and also because I was very nervous and uncomfortable with this format. Thinking out loud is tough if your head is full of doubts of yourself and you have no idea where the curly braces are hiding.

The second one went a lot better even if the tasks I was given were a bit harder. I knew what to expect and did not feel like I must be perfect on every step of solving the problem. Console-logging is okay.

Showing your own code.

I asked for some advice about this in a recent post. For some reason, I expected scrutiny and going through most of the project (at least structure and tech stack) but ended up showing one component and one test suit, and one part of the backend. It was nice because I could show my latest code which was better than the rest of the app. :D

Doing a code review.

This one was the most fun and my favorite so far! I was left alone with some really bad javascript code for 10 minutes. After that, I told everything I thought was wrong with it.

I think this is a lot better than a "code on demand with somebody over your shoulder" way of testing a potential candidate. Also, less stressful because of the perceived role switch: now you are the one who evaluates somebody else.

What about you?

Which are your most and least favorite tech interviews of those you had?

Getting paid per hour or per project?

Anna Simoroshka — Mon, 04 Feb 2019 15:43:18 +0000

Ever since my first job (entering some data into excel sheets during school summer holidays) I've been asking myself this question: "does it make sense to be paid per hour if the work can be finished faster?".

For example, if you work as a guide, it does make sense to get hourly pay. But if you are doing a set task that produces a concrete result, why are you, in most cases, being paid for the hours?

I always was fast and good with my homework. It made sense to start early and to be efficient because I would get more free time. And I was faster than other people, entering rows in those datasheets. As you can guess, it did not pay off and felt super unfair and stupid (teen's thoughts).

If you are fast and efficient ultimately you get paid less for the same amount of work. And since it might be still expected for you to work full hours it is possible to get overworked and burnt out. Concentrated work is more demanding.

The incentive to be fast is lost. You start conserving energy. Thinking in hours, not in results. You don't get more free time or more money. Maybe you get a promotion a year later if you can keep up the tempo.

On the other hand, if you get paid per project it is really important to have a good estimate of the days (not hours!) you will need to finish it, so you get enough money to go on. And it is notoriously hard to do in the software world. Most of the time you have no idea how much time the project will take to finish, unless it is something standard. So it probably makes sense to pay developers for hours worked, even from the point of view of the developers.

15 years later, I am still debating this topic with myself.

It would be nice to hear about your experiences.

Did you work in software companies that do not count how many hours you work? Or is this possible only if you are a freelancer?
Are you a 'sprinter' or a 'steady' developer? Do you practice deep work? How many hour of it are you capable of pulling off daily/weekly?
Which compensation type do you prefer? Maybe both, depending on a case?

Showing Your Code in an Interview: Advice?

Anna Simoroshka — Tue, 29 Jan 2019 09:27:02 +0000

In a week time, I am going to have a technical interview and I was asked to bring an example of my own work to discuss. I am going to show the project I've been working on for the last 1+ years in my spare time. I know it inside out but I am still worried.

Would you have any advice on how can I prepare myself? I am revising and cleaning my code a little bit, what should I pay the most attention to?

Diaries of a Diary Platform - 1: Follow Your Dreams

Anna Simoroshka — Mon, 28 Jan 2019 14:13:56 +0000

Intro

For the last one and a half years, I've been developing a platform for online diaries - very personal blogs. This series is going to be a very personal story of this journey.

A Dream

September 2017, I had a dream. The platform for online diaries where I spent half of my life went down, for good. I kept refreshing the page only to see "This site can’t be reached" message over and over again. For years, I've been documenting thoughts, emotions, dreams, aspirations, fails, love stories, almost everything, and now it was gone. I was making amazing friends there, and now I had no way of contacting half of them. We've been a social network before social networks even existed. For years and years, it was the safest and coziest place on the whole Internet. And now everything was lost, poof.

I woke up, everything was still online and working. The same old website, looking exactly as a decade ago. But the dream made me wonder how long this dear place will last. I gave it 2-4 years before the owners will lose any remaining bit of interest.

The Power of Social Support

Of course, I wrote a sad, contemplating post about this. I was musing about how there is no real alternative: these days you have a choice between social networks, specialized platforms (like dev.to), and stand-alone blogs. There hardly any place that encourages writing any random stuff in any form, for other random people to find it and start sincere conversations about, which can often lead to friendship. Diaries, not blogs. Online, not private, at least not entirely. Freedom of thoughts, expressions, identity, and freedom from "smart" algorithms and surveillance. Good old days.

I expressed a hope that one day somebody might make another one "just like this one" and we all will move there together. "Maybe it'll even be me, more experienced and knowledgable".

My friends ignored the last bit and we went into a discussion about how it could be not just the same but better, what things we need to keep, what we should ditch, and what would be really nice to add or change. Inspired, I said: "okay, I will try to play with this, should be fun". And not that difficult, right?..

The Strength of Ignorance

At that time I had about 2 years of quite random webdev experience in tiny teams and projects and 4 months of working with React on a big project. "I know Node and I know React, I have several online courses about building applications from scratch, it should be sufficient". I googled what the heck is SPA, PWA, SSR, JWT, and many other smart abbreviations and words. I spent a few weeks trying to understand how to build the best project configuration and what frameworks to use. I could not decide if I should use NoSQL or fall back to relational databases. Authentication seemed impossibly difficult to get right. There wasn't any clear picture in my head, just pieces, and many, many ideas.

However, it felt as if I am almost there, I just needed to get through some bottleneck and it will become very easy after that. Maybe another month. Those online courses make it in a dozen hours, right?

I knew nothing and I did not know even that. On the other hand, if I knew how long and difficult the journey is going to be I'd never have made this first step.

Dreams Coming True

And not in a good way. Two months after that dream of mine, the owners of the website announced it's going to be, what is now dramatically called, "The Last Autumn". Many were desperate, panicking, looking for possible alternatives (and there aren't any, remember). I braced myself and made a post about my endeavors and future plans. It went viral, and a new chapter has started.

Full-time, side projects, learning, and staying sane

Anna Simoroshka — Wed, 14 Nov 2018 12:46:49 +0000

It seems to be a rather common thing, especially among fresh developers, to feel that you can't manage working full-time, constantly learning and staying up to date with technology, doing a side project or actively contributing to opensourse, and having a life.

2 years ago I couldn't manage having a full-time job and a life at the same time, I was always exhausted and had a mild depression. Now it is much better: I work, have a long-term project, learn new things almost daily, do not neglect my health and life too much, and don't feel on a brink of complete burnout.

So, here are the things I learnt over the past years of struggling to find my balance.

Eliminate commute as much as possible. Even 45 minutes one way eats up 1.5 hours that could be spent exercising, resting, or doing important things. Find a job that is closer. Do remote. Move closer to your office. Anything. Moving to a flat 5 minutes away from the office was the absolute best decision of the last year.
At the very least, it could be a pleasant commute during which you either exercise (walking or biking) or can work and study.
Exercise and rest. It might seem like you really do not have time or even the right for this, especially if you under pressure of deadlines. However, it is paramount for both metal and physical health, and productivity. You will have more energy and will be able to do more things in less time. It's like an activity that takes negative time!
Focus. Choose 1-2 most important things you want to do right now in this period of your life, besides work. Learning a new language, building something, writing, doing an art project - whatever requires commitment. If there are too many things, decide what is more important and give up on the rest even if it is hard to do. You can pick them later when you're done with the first ones or when you have more time and energy.
Do a little bit every day. Set a goal of half an hour of learning or working on your own things. Do not wait for a free weekend. It is nearly not as effective, you can be tired, other things will inevitably come up, etc. As a bonus, you will constantly stress about not doing things that matter to you, and stress is not your friend.
Choose your social activities wisely. Accept that you might need to spend less time hanging out if you want to make time for productive activities. But never abandon social life entirely even if it feels like you don't have time for it. Spend time with people who support you and give you energy, not the other way around.
Get help if you cannot manage on your own. If you feel burnt out, depressed, constantly in a state of anxiety, always tired, it is okay to ask for medical help. It can do miracles in some cases.
Expect things to always take much longer than you think. Rather than going all in and putting everything else on pause, try to find a balance you can maintain as long as it might take. Even if it is a decade. Design your life here and now and live it, don't wait for the magical moment when you are going to be done.

Can't say I've reached a completely comfortable state, but these things certainly improved my life. None of them occurred to me before my plate got so full I was ready to break down under its weight. And also it took somebody else telling me that no one is a superhuman and we need to take care of ourselves first.

Do you do programming outside of work hours? Do you have many side projects and hobbies? Do you struggle with deadlines? How do you find your rhythm and stay sane?

The worst developers are those who complain there are no tests in a project

Anna Simoroshka — Mon, 05 Nov 2018 11:49:19 +0000

This is what I heard today from one of the senior developers. His philosophy is that people who want tests just don't want to think. They don't want to invest time into understanding what the code is supposed to do and how their changes will affect everything. They are lazy coders who think that testing will solve all their problems.

I completely disagree (except the part about testing not solving all problems). I've been trying to push some testing culture forward in our company and did some for my parts as much as time allows. But it is hard when the software is not designed to be testable. It is also hard when you don't get support from your seniors and when time spent on tests is seen as wasted money.

Hearing this is discouraging.

What would say or do in this situation? Do you think testing is for lazy developers? Does your company have testing culture?