Snowpal’s first Indian English Comedy Short Film. And it’s “based on a true story”. If you know me, you surely know I tend to have a number of stories. It’s not easy to convert them to videos (with limited $) but when has that stopped us from trying? 🙂
Well, you know they say you shouldn’t leave any stone unturned. So, here I go (context: Snowpal Marketing!), taking a break from the usual Technical Videos and trying my hand at yet another thing I may or may not be great at – Stand Up Comedy.
1. If it isn’t too bad, then Thank You! 2. If it is terrible, then you ought to cut me some slack. This is my first attempt, and by the time, I get to the 100th video, I will in all likelihood be at least, tolerable 🙂
On the eve of Mexican Independence Day, I wanted to take a moment to share my thoughts on the very (read: very, very) little I know of Mexico, & Latin America.
I haven’t had the opportunity to work with folks based out of Mexico or Latin America, up until my most recent project, that is.
Since the beginning of this year, I’ve had the absolute pleasure of working with extremely talented & humble engineers living in Mexico, Argentina, Colombia, Brazil, Costa Rica & more. And I have learned a few things (Spanish, unfortunately, isn’t one of them), & I am thankful for all of those learnings.
1. Every country in Latin America is beautiful. Just brilliantly picturesque & blessed with fantastic landscape.
2. The people are extremely friendly (and there’s a lot of similarities with Indian & South Asian culture).
3. They have a lot of phenomenally talented software engineers (& I’ve more than plenty to learn from each one of them).
4. They may or may not have a lot of vegetarian food options 🙂
5. I may not have to pay for hotels when I travel to that part of the world (& travel there, I surely will).
Every day goes by in life, I realize how little I know about things in general – be it cultures or software development.
But, accepting my ignorance is one innate trait of mine I’ve always been proud of. If for no other reason, but simply because it has allowed me to continually learn, even if only a minuscule amount every day.
If you don’t enjoy what you are doing, you better not do it at all.
Yes, we all have bills to pay & commitments to keep but if you aren’t enjoying the biggest chunk of your week (which is at work, for most of us), you are bound to have regrets in life.
I have always felt blessed that I’ve been able to spend over 85% of my career doing what I’ve wanted to do, & more importantly, how I’ve wanted to do what I’ve wanted to do. And trust me when I say, it certainly didn’t happen by chance. I had to make (and continue to have to make) a lot of effort to realize that.
The only regrets I’ve are not the promotions that eluded me or the pay raises I didn’t get but the 15% of the time I spent doing what I didn’t want to do. I would love to get that time back.
So, go find that career your heart beats for, and knock it out of the park. Take risks. If you succeed (and there’s a good chance you will), great! If you fail, you at least failed doing something you loved doing.
One of the things my heart beats for is https://snowpal.com. It’s not the easiest thing I’ve signed up for in my life (not by a distance) but I wouldn’t change a thing, and will relentlessly march towards taking it where I know it has all the potential to go towards, & deserves to go.
– Judge us by the breadth of our features – Judge us by the quality of our offerings (be it the web app, or mobile apps) – Judge us by the attention to detail we pride ourselves on – Judge us by the depth of each of our features – Judge us by what we’ve achieved so far, and in a short span of time
Last but not least,
– Judge us by the number of cool things that are in the coming!
As Robert Frost would say, “…and miles to go before I sleep”.
I’ve been meaning to do that for a while. And before you ask, if I am qualified to do that, let me answer that. No, I don’t think so.
Here are some of the reasons why I am not qualified to teach:
1. I don’t have a Ph.D. (unless I am given an honorary doctorate by virtue of spending about 8 years in College :)).
2. I have hardly ever taught before (other than the 1 year back in College when I worked as a Teaching Assistant).
3. I am not particularly good at repeating the same thing more than once (you need a lot of patience to teach, and I would love to have some of that patience).
4. My subject matter expertise is questionable. I know what I know, I am not sure I know what I don’t know, but I know quite well that what I don’t know is a whole lot more than what I do know.
With that said, here are some of the reasons why I am qualified to teach:
1. I would like to share what I do know with someone else in the hope that it will help them find a slightly better job that will enrich their lives (even if a tiny bit more). I am confident it will.
2. I know that what I do know is useful enough to build good, performant, scalable, distributed, meaningful, extensible, stable software. (…and did I say cool?)
3. I am not looking to gain anything (definitely not intending to) from this effort and I expect for it to remain pro bono.
4. I don’t ever give up on anything I ever do till I get it done.
So, if you are new to Software Development, or want to make a career change to building software, don’t hesitate to reach out to me. I surely don’t have a foolproof plan (not by a distance), and if history serves as any precedent, I tend to do a lot of mistakes before I perfect anything (or even come close to perfection) but I have good intentions. And that’s all I care for.
And for those of you who might be skeptical if I can pull this off, or if I have a clue what I am talking about, I will simply request you to go to https://snowpal.com, and/or check out our iOS and Android Apps, and if those impress you, you can sign up for these free classes (the format, frequency, topics, yada, yada, yada are all pretty much up in the air right now, and we’ll need to play it by ear).
NOTE: If you can afford to pay for lessons, you should consider signing up for paid classes elsewhere as my intent here is to primarily help folks who may not have that affordability.
————– The good news is – I might actually have 2 interested students and that should be a lovely place to start! ————–
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.
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.
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:
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.
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.
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.
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.
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:
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).
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!
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.
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.
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 🙂
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.
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!