As a Software Developer and Architect, I realize that I need a machine for a number of things. I obviously couldn’t do my job without a computer. Okay, that’s a no-brainer. And before you judge me for stating the obvious, hear me out.
What I am beginning to state is that you don’t really need a machine for a few other things that you would do as a Software Developer or Architect. Sure, you could do those very same things in front of a machine but I’ve actually seen that it can be counterproductive. And here’s my rationale for that argument.
Let’s take one of the things I do as part of my everyday professional life — Software Design. And if you are wondering why I might have to do this on a daily basis as every design is followed by development, my simple answer to you is that there is so much we have to do at Snowpal, hardly a day goes by without a design for that next feature. Long story short, I do a ton of design work. And if I waited to sit in front of my machine before I did each and every one of those designs, it would simply eat up a good amount of my development time and we certainly can’t afford that. That apart, it isn’t the most productive approach either so I can hardly see myself do that.
3 paragraphs later, let me try and get started with how else do I do it then. Well, here is the approach I’ve taken for a long time and it has worked very well for us. So, you may want to give this a shot too, and let me know how goes.
I document both my initial thought processes about new requirements and the follow-up software design work during my daily walks.
I record them into a series of voice memos on my iPhone and number them.
I then upload them into the respective directories in Dropbox or Box.
I recap the gist of every voice memo in the last 25–30 seconds.
As with everything else in life, it is best to take a simple example and understand the process I called out for (aka, recommended) above.
Say, we are designing a restaurant management application and are beginning to think about the high level requirements. Here is what the first voice memo will likely include:
Voice Memo #1
We need to build a SaaS Web Application that allows an admin user to sign in to view all the restaurants they manage. The first page should show them all restaurants under their purview, let them add a new restaurant and also view the employee roster for each of those restaurants.
At this point, I would stop recording this voice memo (in the real world scenario, the requirement — even the very first one — wouldn’t be this simple so the voice memo would tend to range from 2 to 5 minutes, and sometimes can get as along as 15–20 minutes, so the corresponding transcript wouldn’t be as short as 4 lines long either, but you get the idea).
The next voice memo can aim to take a stab at the underlying APIs that we would need to implement to support these requirements. Now, the API implementation could be based on REST or GraphQL (or something else). But, much like we all have a native tongue that we “think” in before translating to the other languages we may converse in, a lot of us developers also have a native language, framework, library or protocol that we first “think” in. And when it comes to APIs, it’s REST for me. So, even when I am developing Graph APIs, I tend to first think in REST before I convert it to the Graph equivalent. So, having said that, here is how I would think about the APIs.
Voice Memo #2
I would assume the API is public (which it of course wouldn’t be) and not worry about securing it initially. My focus would be on the underlying specification. So, the first thing we need is a list of restaurants, then we need a single restaurant and finally, all employees that work at the restaurant. So, the API list would be something along these lines:
That would be it as far as the second voice memo is concerned. Now, the 3rd voice memo would touch a tiny bit on the user interface.
Voice Memo #3
Admin user signs in entering their username and password, or via a Social Media sign in. Once they do, they will see a list of restaurants (be it listed on a grid or as cards, or using one of the most common UI components). They will see the name of the restaurant along with some metadata (like last modified date, etc). When the hover over a restaurant, they will see some actions and one of them would be to list all employees who work at that restaurant. When they pick that action and hit Enter, they will see a list of all employees listed once again in either a grid or as cards (now, the same UI component can be reused to render the employee roster).
With these 3 voice memos, I think we have enough to get started with the implementation work, really. Sure, we can draw the UI so there is a wireframe or a mockup and if these UI pages are so unique and new, we would need to do that. But it’s likely you already have similar pages so you can simply reference those pages or components in the voice memo and you should be good to go.
At this point, we are ready to start coding the APIs and the implementing the UI as well. Which means, when we go to the machine next, we can actually open our favorite editors of choice and hit the ground running!
Now, to be honest with you, there are occasions where I tend to do a bit more in voice memos (like think about file names, class names, dependencies, repo decisions, GitHub issues, checklist items, and yada, yada, yada) but that will take a bit more explaining and I think it would be worth writing about it in a different article.
I’ve been on all sides of Technical Interviews over the years, and if I had to summarize it quickly, here’s how I would do it.
First and foremost, be honest. Credibility is key and is second to none.
Apply only to positions that your heart skips a beat for. Not everyone is passionate about what they do so if you truly have a passion for Software Development, you already have an advantage.
Don’t embellish what you know. We can’t all know everything and no one expects us to. The interviewer certainly does not. They are looking to find out if you know what you claim to know and if you have the aptitude to learn what you don’t already know.
Get your basics right and this is easier said than done. Find a quiet space for the interview (assuming it is online) so there are no distractions. Make sure there are no audio/video issues so everyone can see and hear you clearly.
Speak slowly, clearly and time your answers so you don’t end up not having time to share your more important accomplishments.
A lot of interviews have some standard questions (like: “most challenging project”, “avoiding conflict”, etc.) but that doesn’t necessarily mean you provide standard answers. Try to answer the same question differently depending on your read of the interviewer and/or their organization. They are not looking for cliched answers.
Volunteer to create a demo application (a small one but one that works) to share with the team. It could be a Web App, Mobile App, an API-only layer, shell scripts, or just about anything that gives them the confidence that you can not just talk the talk but you can walk the walk as well.
Answer questions in a more contextual manner. This requires you to do a little bit of work learning about the company and/or their domain. Once you do that, your examples could be tailored to their industry so they have to make less of an effort to understand your responses.
You may or may not be a polyglot developer and even if you are one, it doesn’t mean you know the language, framework, library or tool your client is using. Don’t fret. They already know that learning a new language or framework isn’t hard for a good developer. All you need to do is make them understand that you are a good developer.
Don’t be afraid. Remember that it is always easier to ask questions than it is to answer them! So, if you don’t understand what is being asked, ask for clarification.
A lot of companies require LIVE coding interviews. And not everyone handles them well (even the best of developers tend to struggle here sometimes). There are a few ways to make this experience less painful.
Do not be afraid to be judged. Isn’t that what interviews are for?
You are your only competition and you don’t need to prove yourself to anyone else.
Failing a coding session is success as well — in its own way. The more you fail, the more you learn. And the closer you get to winning.
Do your best but have a plan. If the session is 90 minutes long and there are 10 questions, its about 9 minutes a question but you will need 10–15 minutes to hit the ground running. So, it is more like 6–7 minutes per question and not all questions are created equal as well. So, take this average with a grain of salt (unless they are multiple choice questions).
Your aim should be one of 2 things: (a) Do a lot of some of the questions and not worry about attempting all of them, or (b) Do some of all of the questions in which case not every question might be answered to completion. If you can do both, great but that’s not where you may start necessarily.
Be cognizant of the time so you know how much time is used up and what’s left. But, don’t let that distract your concentration from what needs done. Even if you completed only 1 question, you want to make sure that was done well.
Being confident is important but what tends to generally happen is the longer we look for a position, the more the toll it takes on our confidence levels. But, it can only do that if you allow it to do so. So, go to every interview as though it were your first and last one. Tell yourself that past failures are not negatives but they are actually positives as they gave you an opportunity to fix some of your mistakes. Do NOT lose any part of your confidence.
If a thought springs to you that goes something like “there are so many developers why would they hire me?”, replace that with another thought “there are so many companies out there so while it would nice to clear this interview and work for this company, there may be a more deserving company out there for me and therefore, I have no reason to be desperate”. Trust me, it will help.
Some interviews will be easy. Others will be tough. Some will be brutal. That’s how it is. So, don’t deny that, accept reality and enjoy the experience.
When the outcome doesn’t go your way, don’t be too hard on yourself. Try not to speculate on why they passed on you. There could be a thousand reasons and more importantly, none of them matter. Think about any mistakes you may have made right after the interview so you can improve but don’t ask yourself any of these questions after you know the outcome. The timing is crucial for future success and present peace of mind.
Don’t forget that life isn’t fair. You may have done real well but they choose to still pass on you. At the same time, there will most certainly be interviews where you just did alright but you got lucky and actually got hired!
Life is short. Work hard. Work smart. Enjoy what you do. Don’t let other people’s opinions determine your day, week, month or year ahead.
Best wishes for your next interview!
Plan your job search and make the entire process as organized as possible. You’ll need a tool to help you do this. Check out https://snowpal.com!
Download the Mobile Apps, and crack your job interviews!
Given the situation we all find ourselves in 2020, I’ve surely seen an increase in the number of LinkedIn Posts that relate to unemployment where, in many cases, folks have been looking for a while. And while I’ve always had the urge to try and provide some help (as small as it may be), it has not been without its share of challenges either. One of the first bottlenecks I’ve run into is that my knowledge and experience are limited to Software Development, and while I believe it covers a whole gamut of roles (almost) within that area, that isn’t what everyone who is looking for work is hoping to get into. Obviously.
Folks from all walks of life are looking for jobs at any given time, but I’ve had people ask me what they should do if they wanted to switch careers into the world of computing. While I am not a career guidance expert, and I am surely not going to be pretend to be one, I feel like it may be useful to call out (even if at a high level) for a typical set of roles in a small Software Company so it helps anyone who is looking to make that switch. I want to stress on small because that’s where I’ve spent a lot of my recent years, and I am not certain I am exactly sure how the division of labor works in a large organization. Take what I mention here with a grain of salt, but I hope it helps you understand a little bit about how things work. Remember that there are bound to be a lot of gray areas where roles and responsibilities spill over but so long as you’ve learned at least one more thing, this article would’ve been worth your time, in my opinion.
I am going to list the roles in an atypical order simply because it is easiest for me to think that way (given our development process). So, don’t look at these as the right order.
UI Developer
This person is generally responsible for implementing the User Interface, and while they will work closely with the other members of the Development team, they will try to stay focused on ensuring that the look and feel of pages in your application conform with the specification, and that the pages support the necessary actions so the end user can interact with your product.
Take the page below, for instance. This is one of the many pages that our platform comprises of, and is the Dashboard. The UI Developer would be responsible for implementing all aspects of this page.
Screenshot 1 – Dashboard Page
API Developer
In the above screenshot, you see some data. There is 1 Pod Due, 0 Tasks Due, the pod due is called Team Members, there are a number of Recently Modified Pods, etc. Now, all of this data has to be coming from somewhere, and that somewhere is the API layer (as you can imagine, Software Architecture can get as complex and distributed as you wish but in the interest of not overwhelming someone who is new to this world, I am going to trivialize a lot of this stuff).
The API developer is primarily concerned about storing user’s data (along with metadata) in a persistence layer (typically, a database), and returning that data to the client. The UI Developer is agnostic to where this data is stored, how it is retrieved and so on and so forth, much like the API developer is agnostic to whether the returned data is rendered in a grid, or a tree component.
They would likely return a JSON response that looks something like this –
There are other formats they could choose to return this response in, say XML,but that’s rather unlikely. Regardless, just so you know the difference, here is what the XML representation of this content might look like –
They would implement what’s called an API, and that could be implemented in a variety of ways as well, but if they used a RESTful interface, it could look as simple as this:
https://api.snowpal.com/dashboard
Now, if you wrote a new API today, I suggest you go with GraphQL but that discussion is for another day 🙂
The UI and API Developer will exchange a contract so each of them knows what the other person’s expectation is. This is called a Specification.
UX Designer
We now know that a UI Developer will implement the User Interface but what they would implement is driven by what a UX Designed gives them. Think of a UI Developer’s role as one that is made up of 2 parts:
Implement the page from a cosmetic standpoint
Implement the page from a functional standpoint
The UX Designer provides the requirements so the UI Developer can take care of #1 above. And how do they do it? They have many options as well but what they will likely end up giving the UI Developer are Wireframes or Mockups.
Think of a Wireframe as something that is drawn digitally (doesn’t have to be digitally created to begin with, as sometimes, it is quick and efficient to hand draw it and then, share a photo of it)and represents the look and feel of the page.
A Mockup, on the other hand, goes a step further and shows how the page might literally look, along with navigation as well (so the UI Developer knows what should happen when the user clicks a button on the page, or hits a link).
As to how detailed the artifact should be, regardless of which of the above 2 it ends up being, that’s entirely left to the designer, and/or the organization. It can range from giving the UI developer an idea to defining it to a tee.
Or, it could be like the image below that, believe it or not, was one of our “wireframes” and in such cases, it is much like telling the UI developer to Go, figure!
But, ultimately, what matters is that the end result is what your Product Manager has in mind – something like this!
And that’s not a good segue to discuss the next role – Product Manager.
Product Manager
This is the person who determines what is it that your product should even be doing to begin with, but more specifically (and for an existing offering), they determine what that next page your team builds should be, and what problems it should aim to address, and how competitive it might be.
If you are building an internal product for a mid-sized or large company, this person will work with your Business team to identify gaps, requirements and the whole nine yards, and put together artifacts that dictate the next set of things your team should work on.
If you are building an external product, their job would entail doing market research, competitive analyses and more to come up with that next list of things to do. I know a lot of people who were developers at one point, and then moved on to do Product Management work. This is a very exciting role as well! After all, in this role, you get to make the call on what gets done, and when it gets done. So, it ought to be exciting.
Requirements
In a smaller organization, the Product Manager ends up playing this role as well but in larger organizations, this person is responsible to define the requirements at a Business level. They will then hand it over to the Product Manager who will translate these requirements in plain English to a more technical document (aka, specification) that your developers would understand, and can work off of.
Architect
An application is made up of several pages (Dashboard being just one of the many pages), and many APIs, and multiple tiers, and numerous integration with both internal & 3rd party systems and services. And a number of applications will collectively work together to make your ecosystem. Now, how they do all interact amongst and within each other?
It is up to the Architect to answer that question. There are a number of Architecture related roles, some of which are:
Application Architect
Systems Architect
Network Architect
Database Architect
Integration Architect
Security Architect
Platform Architect
and the list goes on…
For a smaller shop, it is usually the same individual (or same group of individuals) who handle all these areas. As to what separates these roles, I think it is beyond the scope of this article, so I’ll try to cover that in a follow-up article (at some point) but it should suffice to know that this person has a complex set of responsibilities.
While you could be an architect who’s hands off, I have never done that role so I can’t speak to it. I’ve architected a number of applications (across all tiers and stacks) over the years and I’ve contributed quite a bit to each of their code bases, and it is my (strong) personal opinion that this role should be hands on at all times (but I am sure not everyone might agree).
CTO
Once again, in a smaller organization, the architect would play this role, alongside doing development as well (hint: Snowpal!) but in a company that can afford this role, this person would oversee all the engineering teams, work with Architects and Developers in all teams, and ensure that the product(s) owned by the company are sound from an engineering standpoint, needed from a market standpoint, jazzy from a coolness standpoint, secure from a security standpoint, extensible from an architectural standpoint, stable & performant from a credibility standpoint, and more!
Tester
Sure, you have a nice product but before you release it to the larger world out there, someone (someone other than your development team, for sure!) needs to bless it so it does what it is supposed to. This responsibility lies with the Tester. They test your product in more than 1 way to make sure it works, and it works consistently.
They can do this in one of many ways:
Test it manually every single time (unlikely for many reasons, but a possibility)
Write test/automation scripts to test the various tiers in your application(s)
Write unit tests (though developers would do this), functional tests, integration tests, performance tests, end to end tests and so on and so forth.
Their job is to break your application so your development team can fix it, and make sure it is all good to go before your end user encounters a problem. This is a another important role because if you find a bug in development and fix it, it will cost you (both in terms of money and time) a whole lot lesser than if the same bug were to be reported in production.
DevOps Engineer
You have a great product, and a wonderful team but it isn’t complete (not by a stretch) till you have a DevOps Engineer who can ensure that your changes make their way (aka, deployed) to the various environments continually. This area has grown in recent years and while your developers might play this role in a smaller shop, as your company grows, you will need dedicated engineers to handle all the Docker, & Kubernetes stuff.
Your API Developers might be a tad more eager to pick up these tasks as they blend quite well with the tiers they work on.
CEO
In a small company, there is only C* role but, of course, in larger companies, you will need a CEO, a CFO, a CIO, a COO, and more…
I can’t write more in this section because I would merely be speculating 🙂
Creative Team
At Snowpal, we don’t yet have a Creative Team, but that will be one of the first areas we will expand on as we grow. This team will create our Campaigns for Facebook, LinkedIn, Pinterest, Apple and more. Right now, we take turns to do this, and it is certainly not easy (and definitely not if you don’t have the part of the brain that contributes to this – I surely don’t).
I am sure this team is part of the larger Advertising Teams, but I honestly don’t know more about the roles and responsibilities of this team in larger organizations.
Project (or Development) Manager
You need someone to make sure all your teams understand their asks, their dependencies, deadlines and so on. This is the Project or Development Manager’s role. They will organize daily stand ups, identify blockers, create and manage Sprints, and work with all the stakeholders to make sure your ship is sailing smoothly.
They may play the role of a Scrum Master as well, but some organizations separate these roles. In our case, and in smaller organizations, the Architect handles this responsibility.
Kanban View on snowpal.com for Project Management
HR, Legal, Sales, Marketing, etc.
I have an idea about the roles and responsibilities of the other teams but not enough to write about them (or answer follow-up questions) so I am going to leave them be!
That’s basically it. Hopefully, you’ve learned at least one thing that you didn’t already know from this article.
Check out how all these roles worked in sync to create the Web App, Mobile Web App and Native Mobile Apps @ https://snowpal.com!
Snowpal Software Services 