DEV Community: anabella

7 front-end interview processes I did in December 2021

anabella — Fri, 31 Dec 2021 09:08:49 +0000

I recently went through the task of getting myself a new job and, to do this, I took part of 7 simultaneous interviewing processes for front-end roles with React and Typescript.

I learned a lot as days, weeks, and interviews went by. I learned about myself and about the way companies evaluate candidates. I think this knowledge, paired with a real view into how front-end interviewing looks like today could be really useful for other people in search of a new job and teams who are looking to hire (to get interview ideas!).

In this article I'll go through each of the companies I interviewed with (without giving names, sorry papparazzi! 📸), I'll outline the process and its stages and try to give my view on the pros and cons of each approach.

Disclaimer

To be completely honest, doing 5-6 interviews per week wasn't such a wonderful idea.

It was stressful, tiring and came with a constant state of context switching. Interviewing is, in a way, a performance and you have to be at the top of your game on every call, 'cause it won't matter how well it went with the other company you spoke earlier in the day.

I'd recommend job seekers to focus your energy in 2, max 3 processes at the same time. Job hunting really is a full time job, and limiting your options will help you focus on the ones you're really interested in.

Company 1️⃣

Size	< 20
Domain	work management tool
Position	front-end developer
Process	Initial call with one of the founders (45 min) Show n' tell of a project with a FE engineer (1 hr) Call with the other founder (45 min) Demo of the product (at my request) (30 min) Call with the FE technical lead (1 hr)
Experience	good! 👍🏼

My take on it

The good 😇

Fair and easy going process
Show and tell of a project is one of the best ways to evaluate a candidate's tech skill without going through the dreaded "live coding" or the tedious "take home test"
"No wrong answers" approach to tech talks
Talks with C-level people (founders) were very interesting and layed back

The bad 😈

The talk with the front-end lead was confusing. They seemed undecisive and sloppy and not a "leader type". This had a big influence in my decision to drop out

The ugly 👹

They were trying to hire remotely but hadn't figured out anything about how to do it

Conclusion

I dropped out before they made an offer (they said they were ready to do so). I realized I wanted to join a bigger engineering organization.

Company 2️⃣

Size	> 3000
Domain	technical tools for developers
Position	front-end engineer
Process	Initial call with an internal recruiter (30 min) Algorithms live coding (w/ study material provided by them) (1 hr) Take home test (~a week) "More complex" live coding exercise (1 hr) Software design (FE) with whiteboarding (1 hr) Final talk with an engineering manager (1 hr)
Experience	bad 😒

My take on it:

The good 😇

Clearly structured process
They provided study material for the algorithms test
They provided thorough feedback after dropping me
They sent an anonymous Greenhouse survey about my experience

The bad 😈

Too many technical tests, all of them stressful
Slow (~weekly) communication
Unclear live coding test (they didn't say there were 2 problems so I took too much time on the first and simpler one)
Untrained technical interviewers reading questions from a script

The ugly 👹

Dropping an experienced candidate based on their ability to solve basic algorithms while under peer and time pressure 🚩 (personally, that's not a company I want to work for)
During the algorithms call they either gave me false tips (leaning me into the wrong approach) or were too ambiguous with their words (I really really hope it's the latter)

Conclusion
They dropped me so I might be a bit bitter about it but: cracking long-solved, highly googleable problems or implementing existing algorithms is very far from the value I can bring to a product team. If that's the first thing they care about, then that's not a company for me.

Company 3️⃣

Size	~ 300
Domain	payments
Position	Senior front-end engineer
Process	Initial call with in-house recruiter (30 min) Technical talk with a FE developer (1 hr) FE system design w/ 2 devs (more in this below!) (1 hr) Values interview with an eng. manager and a non-technical teammate (1 hr) Meet the potential team (at my request) (45 min)
Experience	very good! ❤️

My take on it:

The good 😇

All kind and nice people, all around
The in-house recruiter took the time to speak with me after every interview, this built a friendly bond
(Almost) no live coding, no whiteboarding, no take home tests
Favorite interview (of them all!): FE system's design
- No whiteboarding
- Look at app screen designs, break them down, find problems, think of implementation, evaluate options and their pros and cons.
- 👆🏻 Literally one of the things you'll do the most while at the job (aside from writing/reviewing code).
- Finally, a small algorithms coding challenge (bit of a surprise :/ ) but I was already warmed up and confident and it went well :)

The bad 😈

The live coding part of that interview came as a surprise, which is usually seen as a bad practice. Candidates should know about every part of the interview right when it starts. It gives them the chance to manage time and energy accordingly.
I spoke to the team lead and a teammate of my potential team. They weren't ready to pitch an interesting challenge for my position, which in the end resulted in my loss of interest.

The ugly 👹

Managers need to be trained in diversity matters
- When I asked the manager I spoke to about how they were giving a voice to underrepresented people in the company he said "we have an open doors policy, anyone can talk to anyone, no matter their rank"
- For the record, "open doors" is not enough for underrepresented folks, as most of us won't feel entitled to speak our minds openly
- Humble advice: put underrepresented people in situations where they are expected to speak their minds

Conclusion
They made an offer which was tough to say no to (no pun 🐴). But I felt like the work I'd be doing wasn't very clear and the team lead fell really short in pitching the project, so with a heavy heart I went a different way.

Company 4️⃣

Size	< 20
Domain	logistics
Position	software engineer
Process	Initial call with third-party recruiter (30 min) Initial call with CTO (45 min) Take home test (~a week, took me about 6 hrs) Call to review take home test + add a feature (1 hr) Call with CEO / founder (45 min) Call with 2 team members (at my request) (30 min each)
Experience	regular 😕

My take on it:

The good 😇

They were very clear about their intention to make me an offer almost from the start

The bad 😈

The take home test was really low quality.
- They gave me a boilerplate project and some designs to implement. There were no specs or acceptance criteria, icons couldn't be exported, entities were inconsistently named, and it was hard to match the data coming back from the API with the designs.

The ugly 👹

Bad manners from a C-level interviewer
- During the review of my solution the CTO questioned the file structure of the project (wut?) and seemed to be trying to find things I "did wrong".
- Later on, when I was verbosely and carefuly refactoring my code to introduce a new feature he interrupted me because he didn't "understand what I was doing".
- After I was done with a working and clean implementation he said "there was an easier and faster way to get to the same result".
- All of this was inconsistent with the external recruiter's claims that they were incredibly excited for me to join.
In a later call with the CTO he asked me to name which other companies I was interviewing with and, even though this made me really uncomfortable, I told him. I wish I had stood my ground and refused to share that info.

Conclusion
They made a 3-folded offer (different distribution of salary and stock) which I declined.

Company 5️⃣

Size	~ 150
Domain	Finance
Position	Senior front-end engineer
Process	Initial call with third-party recruiter (30 min) Technical talk with 2 front-end devs (60 min) Live coding with 2 devs (they shared the tasks in advance) (90 min) Round table w/ people from different teams/areas (60 min)
Experience	great 1st impression, bad ending 💔

My take on it:

This was the company I was most excited about, and the one which broke my heart when they dropped me.

The good 😇

They have public salary bands and career paths
The process was short and focused
They shared a highly realistic project (with tickets) in advance, which I'd have to work on during the live coding

The bad 😈

We spent a lot of time during the live coding debugging accessory things which they suggested but then weren't sure how to implement.

The ugly 👹

2 weeks have past and they still haven't provided any feedback about what made them drop me after the live coding. I've requested it twice, no answer 🚩

Conclusion
No matter how cool a company can look, they need to walk the walk and treat their candidates with respect. I was sad they dropped me, but the fact that they've ghosted me for feedback makes me feel they weren't as cool as they presented themselves.

Company 6️⃣

Size	~ 150
Domain	Open source messaging
Position	Front-end engineer
Process	Initial call with third-party recruiter (30 min) Initial call with in-house HR person (to whom I was meant to ask the questions) (45 min) "Domain-agnostic" take home test (~a week, should take 3-4 hrs) Pair programming on a very basic (and legacy) react app (60 min) Prep call with HR people for the systems design interview (30 min) "Deceivingly simple" systems design discussion with the VP of Engineering and a team lead (60 min) Talk with a member of the front-end team (at my request) (30 min)
Experience	good! 👍🏼

My take on it:

The good 😇

All interesting, respectful, and kind people
Fun and simple take home test, actually doable in 2-3hs (although I spent more 'cause I wanted to get it just right, that's just me)
The pair progamming interview was actually a pair programming exercise (not live coding in disguise).

The bad 😈

A bit of a long process, too many technical tests for my taste. The one focused on React was very outdated (class components, no Typescript). It didn't reflect the actual state of the app I'd be working on.

The ugly 👹

The person to whom I spoke when I requested a talk with a team member wasn't really prepared to pitch the project and that had the biggest impact in my decision.

Conclusion
They made an offer, which I declined in favor of another one (read below!). But they said the terms of the offer would stand for about 6 months! How nice! 😍

Company 7️⃣

Size	~ 300
Domain	Payments
Position	Software engineer
Process	Initial call with third-party recruiter (30 min) Pair programming to which I had to bring the problem to work on (60 min) Technical / values talk with an engineering manager (90 min with a break half-way) Values talk with the in-house recruiter (45 min) Meet the team and the team lead (at my request) (30 min each)
Experience	good! 👍🏼

My take on it

The good 😇

Short and fast paced process
Every interviewer feedback at the end of each interview (including if I passed!)
Pair programming was actually pair programming (not live coding in disguise)
Bring-your-own coding challenge felt like I was in control of how I'd be evaluated
They arranged 2 calls to meet my potential team
All the talks gave me a clear sense of what it's like to work with them

The bad 😈

I was a bit confused / annoyed to have to "put in work" preparing a challenge to bring before I even spoke to anyone in the company. That might have been different if I had been contacted by an in-house recruiter and learned more about them first.

The ugly 👹

The person doing the pair programming with me had very little knowledge about React, this was beneficial to me because I love explaining React to people, but we might have gotten more done if they had been front-end focused.

Conclusion
They made an offer and I accepted it! 🎉

The biggest selling point for me was the ways of working (XP/Lean, pair programming by default) combined with the fact that I'd be way out of my comfort zone working a lot on backend projects and being the person-of-reference for front-end and React matters.

My overall learnings 🧠

For candidates 👩🏻‍💻

Show and tell interview

Bring something you're really excited or proud of
It can be something small, you can even build it specifically for the interview (that way it'll show your most up-to-date skills!)
Start with why you wanted to build that
Think in advance about how you're going to walk through it, the reasons for your decisions and things you'd like to add or improve on

Live coding

Make sure you know how many exercises you'll have to go through
You can even ask how much time they think they should take. That way you can adapt your rhythm.

Helping your decision

If you have doubts about joining a company, or if are trying to decide between competing offers, requesting a call with potential teammates can help a lot in picturing how the day-to-day work will feel like. To me that was a dealmaker because:
- I'll be working with a certain group of people
- In certain projects
- And with a certain dynamic
- 👆🏻 that should have more weight in my decision than anything else, since it'll have the most impact on you while at the job.
In my experience companies and recruiters will be more than happy to arrange a call with the team for you at a final stage of the process

Decide how much you want to share

You'll probably get asked about other processes you're taking part in.
Companies often ask this to make sure they're not lagging behind timewise.
They might ask you about "where they stand" in your preference list.
They might ask you for details of other companies, size, domain.
Be as honest or ellusive as you want. None of this should affect your chances of getting an offer. Just don't give them names

Ask questions, give feedback

Everyone knows you're supposed to bring questions to every interview. If you didn't, now you do!
Ask about things you care about, anything that'll help you picture yourself working with them or make up your mind about joining.
Take the opportunity to give feedback to companies and interviewers after each call.
- Include what you liked about it and what could be improved
- This, if done right, could make you stand out as a candidate!

For hiring teams 🏢

Show and tell interview

This is a great way of evaluating a candidate's experience and skill without putting them on the spot!
Instead, it puts them in control of the situation and you'll get to see a lot more of how it's like to work with them on a daily basis.
You won't see much of that 👆🏻 with a coding kata or an over-simplified feature development exercise.

Train people on how to interview candidates

Especially for bigger organizations: train your interviewers in conducting conversational and technical interviews. They're the face of the company to potential employees.

Live coding interviews

Especially for kata style ones, make sure the candidate is aware of how many problems they'll go through during the call and give them an estimate of time budget for each one.
Mention if they're going overtime with one problem and give the option to move one to the next or work on solving the current one.

Pitching the project

When reaching the final stages of interviewing, especially if you're a small/medium company, prepare your interviewers in pitching the team and the company to candidates
Those final conversations usually make or break the deal for people trying to decide between more than one offer.
If you have all positive feedback across the board about a candidate, make sure you can give them an offer that's interesting to them.
- By this I don't mean money: most experienced candidates will get similar offers and you can probably match whatever they're getting somewhere else.
- Pitch them a position and a project that they'll feel excited about, and it might even be worth not going for the highest paying offer!

Give feedback to candidates

This can be before the interview ends
It can be in "catch up" talks with the recruiter
It can be as a warm up before making an offer
And it should definitely be there if the company drops a candidate, especially after the candidate requests it.
Idea 💡: ask candidates for feedback of each interview!

That's it, thanks for reading this far, please leave comments about your own experiences interviewing and being interviewed.

I hope some of this is useful for you in 2022!

Hack The Weather: our NewRelic hackathon submission

anabella — Mon, 01 Mar 2021 07:58:44 +0000

Hack The Weather is an app that uses historical weather data to show today's average temperature in a city as well as what was the temperature on the same day 1, 2, 3, 4 and (almost) 5 decades ago (that's as far as the API's historical data goes).

To learn more about how we built it, how we integrated NewRelic into it and get a link to the live version so you can search for your city, visit our official hackathon submission at The Relicans.

We built it together with my friend and colleague Albarin

Leave us your comments!

First impressions of Epic React by Kent C. Dodds

anabella — Wed, 13 Jan 2021 19:01:12 +0000

This is my first post on a series the Epic React courses. This one is about my first impressions and opinions on the course in general (tl;dr I think it's great!), while the upcoming ones will focus on the content covered on each section. Stay tuned for more!

I purchased my subscription to Kent C. Dodds' Epic React course when it came out last year, but I hadn't been able to start it until yesterday. I knew from other courses by him that it would be great, so I wanted to make sure I had time in my schedule for it before I began using it.

Now that the new year is in, I decided it was about time I saw what it was all about. And so last night I watched the first chapter.

Welcome to Epic React 🚀

I was instantly surprised by this initial tour of the course. As first impressions go, this looks like way beyond any other online course I've ever done. More so, it feels like the best parts of every online course I've done, optimized to work together and cater to anyone's learning habits and preferences.

What do I mean?

E-learning, the good parts 👩🏻‍💻

What are those awesome parts that (I think) Kent noticed and put together in just the right combination?

Video tutorials 🍿

It's no secret that many people prefer watching a video course or tutorials over reading a book on a certain subject. There's so much more that you get from having someone just tell it to you instead of reading it yourself. To start with, listening to a real person speaking, using their voice and emphasizing on things, not just words on a page, really makes a difference. That sort of thing is usually really hard to convey in written word, especially in the formal writing often found in books. And in the end it really makes a difference in making the learning process feel more informal and relaxed.

But videos (or books) are never enough, if you can't get your hands dirty with the code. That's cool though, Epic React's got you covered:

Interactive tools 👾

The first thing that surprised me about Kent's course is that it's a full product and not just a library of video tutorials. The course comes with a dedicated application you can run locally and use to

read about the current exercise,
see the result of your code, and what the final result should look like
as well as using some handy tools to control network calls.

Similar to the classic Codecademy-style apps, this is your control panel for learning.

Ah, but I remember taking my first ever coding lessons in Codecademy (back in 2012 or so) and feeling like the learning was good but partial, because I had literally no idea how to create and run code that actually did something outside of the learning platform. And that's why many other types of courses give students:

Project Files 🗂

I remember first learning Javascript within a learning webapp, kind of intuitively knowing that "Javascript runs in the browser" but having no idea how to actually make a browser run my code, let alone make it interact with a page.

This is another ingredient in Epic React that contributes to enhancing your learning experience. You get to see your code run in a real environment, like it would if you were building an app and not just solving exercises.

The more the merrier 👯‍♀️

The courses also provides a detailed explanation of each exercise (to add to Kent's videos explaining the subject), together with links and references you're encouraged to consult in order to expand your understanding.

Solving the basic tasks seems to be more or less straight forward with the help of the courses cast of code comment emoji (most notably Kody the Koala 🐨) so that you don't spend much time trying to "please" the exercise checker into accepting your solution: I know I've been through that and it can be both frustrating and distracting from what you're trying to achieve.

But if you're into challenges you can take on the extra credit for a less hand-holdy experience. I believe solving problems on my own is one of the best ways to solidify new knowledge.

The cherry on top 🍒

To top it all Kent has created a Discord community for learners, and even a model for people to create their own learning clubs to stay motivated and learn from each other. This, I think, is the most innovative and generous thing added to this course. It really feels like it's providing every tool available for us to succeed.

Conclusion 😃

Without even starting any of the actual material I can tell that this is miles ahead of any other course out there. I can't wait to start watching the next chapter: React Fundamentals.

Well, thank you for reading this far! These were my first impressions on Kent C. Dodds' Epic React course and what it proposes as a learning platform. I hope you enjoyed it!

Emoji traffic jam generator!

anabella — Sat, 09 Jan 2021 18:33:34 +0000

What I built

I built an emoji traffic jam generator. It generates a 16x16 grid in which it draws a cross junction using ascii Box-drawing characters and then fills it up with (mostly) random emoji. The only fixed parts are the junction layout and the traffic lights (as they tend to not move much).

Category Submission:

Random Roulette

App Link

https://emoji-jam-rjlxe.ondigitalocean.app/

Screenshots

Description

I've been meaning to build some pattern generator using emoji for a long time. I've thought of an emoji forest, aquarium or sky (with birds, clouds, and flying things!). In the end I decided to try find beauty in something ugly: a traffic jam.

The hardest part was building the logic for the grid. I've never done anything like that and it felt like I was lacking some math skills. But anyway, I solved it the easy/brute-force way. I bet there's probably smarter ways of achieving the same. Luckily I can count on React for performance optimizations.

Link to Source Code

https://github.com/anabellaspinelli/emoji-jam

Permissive License

The MIT license

Background

I wanted to build something to generate art from random emojis for a long time. I will work on other emoji pattern generators in the future!

How I built it

The grid

At first I drew the thing I wanted to build in a Sublime Text notepad, to see how it could look and start to understand the challenges ahead:

Then I "normalized" it into a grid in a GSheets document:

This served as a very useful reference throughout the building of the whole project.

Trial and error

My first attempt was of generating "horizontal strings" that I would stack on top of each other, but I quickly found that this presented some issues in aligning the characters and that it would make it really hard to scale into something more advanced if I ever wanted to (animating it for example).

I quickly went for the grid option, creating an array of "rows" and flattening it at the time of render. Each row knows where to draw the street lines characters, and where to go fetch for some random emoji: sometimes it's sideways cars, sometimes it's frontal cars, and sometimes it's scenery (buildings, trees, pedestrians).

Style the tile

The last bit was fun too: using complex CSS selectors to paint different cells light or dark gray and transform them in order to flip the emoji. Thinking back I think I might refactor it into CSS classes, being that each cell "knows" what role it plays when it's filled. But hey, it's a hackathon after all!

Layout

Then came the final touches, creating a nice playful layout that would also work on mobile. Nothing too fancy.

Next steps

The next steps would be improving the hacky hackathony code into something more scalable, exporting as an image, and playing with adding some controls to the generator:

Sidewalks option (with pedestrians!)
Middle lane with plants option
Cars/trucks ratio
Some hidden easter eggs!

I hope you like it, let me know what you think in the comments! :D

The self-confidence toolbox for job interviews

anabella — Tue, 02 Jul 2019 13:09:56 +0000

One of the biggest challenges I faced when starting my career in software engineering was applying and interviewing for jobs.

I went through a ton of interviewing processes, and for most of them, I was unprepared and under-qualified. In spite of this, I realised that every not-so-good interview helped me improve my "technique" and become more confident.

Then, about a year ago, I started participating in the other side of interviews, that much more comfortable side of the conversation: interviewing candidates instead of being a candidate myself. This change in perspective allowed me to observe interviewing in more detail (and with less stress) and reflect on all the things that I've learned about it.

This post describes tactics that helped me reduce stress during those conversations, as well as some mental tools I used to frame the interviewing process and ultimately be more confident about my performance, whatever the outcome.

Getting an interview means you’re already 50% in 🌓

I know it doesn't feel like it, but it is often true. A friend of mine used to say this, and I didn't believe him. Years later, I realised that companies only spend time talking to candidates who they already suspect might be a good fit. If they asked you in for an interview, they want to learn more.

You're also interviewing them 👀

Yes, you're being evaluated during an interview. But it’s a two-way street: the interview is also your chance to evaluate the company as a potential employer and learn whether the company and team are a good fit for you. It's important (and empowering) to keep this in mind during the interview–you’re also trying to find out if you want to work there.

Tell your story 📜

This is an elevator pitch about yourself, and pitches need a good story. So, how can you describe your experience and objectives in a way that captivates others? Find that story you want to tell, and once you have it, keep working on that narrative to make it engaging.

You don’t have to recite your resumé by heart. Instead, fill in the gaps between every milestone, from your own human perspective. Think about the most relevant point in time to start from, then pick and choose the events you tell so that they follow a logical, purposeful path. You're not trying to prove anything–instead, focus on making them remember you.

In my case, my "story" changed every time I was looking for a new job: I would usually explain how each of my previous jobs contributed to my professional growth and what I was looking for next. I found that it would take me a couple of tries before I had my story clear enough in my mind to be able to transmit it to others.

Please don't lie! 🤥

Lying will just make you more nervous. I've done it, and it backfired. I still remember that interview as the worst in my life.

You can, however, frame the truth without lying. For example, instead of saying, "I don't know anything about React..." you could say, "I've heard about React and its popularity…although I haven't used it yet, I'm curious and would like to give it a try."

Ask questions 🗣

I used to get very nervous when interviewers asked me if I had any questions for them until I understood that I needed to think of some questions in advance and adapt those to the specific context of each conversation.

So, prepare some questions beforehand. Do a little research about the company and think about what you're looking for in a new job and what you care about (remember, you're also interviewing them).

Think about what you'd like to ask and what you want to communicate with your questions. The interviewer’s answers will give you a deeper understanding of the job and your questions will show them the things you care most about.

Trust them, they know 👥

This is one of my favourite tools in the self-confidence toolbox. There may be times when you feel you're not good enough for the job. Ye olde imposter syndrome, right?

Well my best tool against this is simply putting my trust in the people doing the interviews: telling myself, "They know."

Why? Because they have a lot more context about the company, the team, and the position, and they're more likely to assess the situation correctly. So if I'm feeling like I might not be up to challenge, I just tell myself: "You don't know that. They do." Remember my first point: companies spend time with candidates they already think might be a good fit.

There's no such thing as being too interested 🙇🏽‍♀️

It's totally OK to express your interest up front and ask for feedback or updates throughout the process. It's also a great strategy to go the extra mile to demonstrate it. If you really want to land a particular job, ask yourself, "What can I do to stand out from every other candidate?"

When I was interviewing for my current job, I decided I would go an extra 2 or 3 miles because I wanted the job so badly. Before my coding interview I researched the company's APIs and created a suite of acceptance tests for them. I wrote an email to HR, asking if they would be interested in reviewing the project during the upcoming interview. Even if my small project wasn't anything special, they were impressed with my commitment, and I think that played a great part in the outcome.

It's not you, it's them 💔

Rejection is gonna happen…and it's probably not about you. Many factors come into play during a hiring process, and the ones that are not related to you greatly outnumber the ones that are about you specifically. The best you can do is ask for feedback, reflect on what you've learned, and use it to feel more confident in your performance next time.

In the end, they want this as much as you do 👯‍♀️

The people interviewing you are spending time getting to know you because they think you might be a great fit. They're not looking to rule you out, but quite the opposite: they want you to succeed.

The hiring process can feel like a series of challenges to overcome to get a prize–challenges that the interviewers want most candidates to fail. This is not the case: they should want you to succeed and they should help you get there. But if it feels like the interviewers pressure you and want to see you at your limit, maybe it’s not the best place for you after all.

Also, if you’re working with a recruiter, remember that it's their job to get a hire. Don't forget to use this to your advantage, let them help you: listen to what they say, as they have a lot of useful insights that can help you perform better.

I once asked for 2 weeks of preparation for a coding interview, saying that I was a bit rusty with the subject we'd be covering in the test. Truth is I wasn't rusty, I had no experience with the subject at all. During the interview I asked to look at my own study files to recall something and it was fine. In the end it all went well and I passed the interview.

A final note about coding interviews 🖥

This article focuses mostly on the "talking" part of interviews, but I feel there are a couple things left to be said about live coding interviews.

It’s OK to say "I don't know" 🤷‍♀️

There's no shame in saying "I don't know that." Take it as another opportunity to evaluate them as an employer. They should be able to explain a task or concept to you and give you the opportunity to show how easily you can pick up something new and apply it right away.

This has happened to me twice, and it turned out to be a great learning experience. On one occasion, I got the chance to ask questions and demonstrate my learning process, and on the other I showed my Googling skills. In the end, I got both jobs!

It's not about the code 💫

While you're coding or white-boarding, think out loud as much as you can. Coding interviews aren't supposed to be about producing perfect code on the first try. They're about your thought process and your ability to think of solutions, debug problems, and communicate your ideas. Turn it into a conversation.

Easier said than done, right? I agree, but these strategies do make interviewing less stressful. They allow you to step back and approach interviewing not as a stress-filled contest to win a job but as a process that helps both sides evaluate whether the fit is right. Plus, the more you practice, the easier it gets.

Have you used anything similar to these tools before? Do you have others? Drop them in the comments! 😉 I'd love to read them!

I built a site for Pride month!

anabella — Thu, 27 Jun 2019 15:59:59 +0000

Cover Photo by Stavrialena Gontzou on Unsplash

Hey lovely DEV community!

I'm writing this short post to show you a small website that I built using just HTML and CSS 😁 Yay! Old times!

I always wanted to work on a project for Pride month but I could never think of something in time. Until this month I started seeing a lot of pride-themed brands using "the wrong colors" *gasp* 😱

So I did some research on the subject. And by "research" I mean that I read the Wikipedia article on Rainbow Flags and realised it's not really that easy.

Usually people think the LGBTQ+ Pride flag needs to have 7 colors: "the colors of the rainbow", but that's not really the case. When this happens they end up using the Cooperativism Movement flag, instead of the widely accepted (but not exclusively recognised) Pride flag.

What I found is that there's no final truth about what's the correct one, but after struggling a lot with myself thinking if it made sense to make this website or not I finally decided that it's just for fun and set out for it. And, a couple of days later, it's ready.

🥁 drumroll 🥁

Here it is: Pride or Coop?

I hope you like it and can use it as a reference when in doubt!

A junior, a mid and a senior dev walk into a bar

anabella — Sat, 29 Dec 2018 16:12:43 +0000

Gather 'round and let me tell you about that time my teammates and I took down one of the platform's most critical services.

For the sake of narrative, I’ll name my coworkers S (senior) and M (middle), although I changed the dates and some of the technical details in an effort to keep things as anonymous as possible.

T’was a lovely Thursday afternoon at the end of July. Weather was milder than the days before and my teammates and I had just moved into a new space in the office.

Life was mostly good.

The week before had passed without the presence of our most senior dev, S, but M and I had managed to complete some tasks on our own.

The changes we introduced had some pretty heavy stuff (new database fields, new endpoints) so we decided to wait for S's review before we merged them.

Database changes and migrations 📚

In the meantime another dev reviewed our changes and mentioned that the operations in our migration scripts could be a lot of work for the database server and could keep it locked for a while. So he suggested some alternatives.

If you don’t know what a database migration is, it’s a series of SQL scripts that — when executed sequentially — create the whole database schema from scratch (tables, columns, default values, constraints, etc.). Usually they run on every deployment, but only if there’s something new to apply––that is, a new migration script that has never been run.

We didn’t want to run our change as a migration because then it would be executed by our continuous integration system which would be completely out of our control if something went wrong.

We had to run it manually.

So, we sat down with a replica of the production database and started playing around with queries trying to find the most efficient alternative.

This was a fun while, the 3 of us trying to guess what would happen when we ran each script line separately. Would it take long? Or run instantly? And why? Where should we set the default value to prevent new entries from breaking it?

Showtime! 👯‍♀️

Now it was 5 PM and we were finally happy with our query. It did everything in the right order and didn’t really lock down for very long. We sent a ticket to the infrastructure team to run it directly on our servers, since obviously we didn't have credentials for that. You’ll see exactly why in just a moment.

Infra was really diligent about this. We know they’re a busy bunch, and it’s okay if they take a while to do stuff. But not this time, oh no, this time the ticket was closed before I could blink twice.

Everything seemed ok. It was almost the end of the day so we split into our own desks and finished some tasks.

Some minutes later, a member of another team came by and asked me if we were changing stuff on that feature because it was throwing some errors. This hit me like an ice-bucket-challenge:

Oh no, I mean, yes… we f***ed it up.

Can you guess what happened? I know it’s harder to find omissions than to find mistakes, but I think you could be able to know what we needed to do (and didn’t) without knowing the service, the feature, or the queries.

If you do, scroll to the bottom and comment it, I’ll trust you’re not peeping below this photo 👇

Alright, if you have no idea what could have happened, that’s OK too. I feel I should have known, because this happened locally during development like a million times. And I had been starting a very similar feature on my own that day and dealing with the same error.

Ready for it?

Reality hits hard 👊

We added the column in the database, but we never merged the code that handled this new data. This resulted in the application not knowing WTF to do with those fields, and throwing errors on all GET requests 😱

Now, this might not have happened in some languages, which probably would have discarded the extra, unparsed data and moved on. I shouldn't disclose any more information about this, but I’ll say that we were using a technology that’s not as chill about rogue database columns, it demands that you tell it how to handle everything it receives.

Not merging the code for the new fields wasn’t the problem though. Here’s where our little evil villain comes in: meet * 😈 malefic, echoing laughter

See, all of our retrieval queries were using the * (known as an asterisk or star), which means results will include every field on the table. This was the day I learned this is a very very very bad idea.

If we had had a list of the fields to retrieve instead of * nothing bad would have happened. But we didn't. And all 3 of us knew it. It just slipped our minds 😰

The real, real problem 🤦🏻‍♀️

OK but, we’re humans, right? We make mistakes. No-one can keep all of the codebases in a company in their working memory. This is why we have tests. Not because our code is fragile and error prone, but because our minds are. And it’s our minds that create the code.

So the problem wasn’t really that we broke it. The problem was that no alarms went off.

We had production tests, but they weren’t notifying anyone. We had error alarms in the logs, but they weren’t monitoring the thing that caused the most errors. We had end-to-end tests, but they were disabled and marked as “broken”. This is what was truly unacceptable 🍋

Epilogue 📜

Ultimately, though, it was a big opportunity for learning: you never learn as hard as when you f*** up. That’s a lesson that never leaves you.

So, for you children out there, here’s my list of learnings from that day:

NEVER, I MEAN NEVER use * in a query in your code. Even if you have to write one hundred column names, it's better like that.
Be scared of database changes, may fear guide you into caution.
Migrations should be decoupled from deploys, in order to provide better control over them.
When you introduce a database change, make sure all the code is already in place and that it can handle the previous db state, and the one after the change.
Have happy-path tests in place running on production for your critical features, working and notifying the right people.
Test database changes as soon as they are impacted and monitor the logs for a couple of minutes later (depending on the amount of traffic that you get).
Aaand brush your teeth before you go to sleep 😬

Disclaimer ⚠️

This is a story told by the less experienced and knowledgeable of its characters. If you have any input about it, to add to or correct what I say I would really enjoy reading it, but please be nice about it. 🙂

Credits

Cover Photo by Sebastian Fröhlich on Unsplash
Photo by 胡卓亨 on Unsplash

Thanks to Nicolas Grenié a.k.a. @picsoung and Eva Casado de Amezua for their reviews and input.
This story was originally published in HackerNoon.

A peep beneath the hood of PassportJS' OAuth flow

anabella — Mon, 03 Dec 2018 21:50:36 +0000

Libraries are great. They provide standardized, widely compatible and clean way of doing common tasks, abstracting away the details we usually don't care about. They help us not to worry about the specifics of authentication, database handling or form validation and just write the code for that thing we have in mind.

But then, what happens when something doesn't work as expected? How do you know what went wrong if you're just pushing buttons on a black box?

Sooner or later it's necessary to understand how our borrowed libraries do that little thing they do 🎶 to figure out where we (or them) took a wrong turn and be able to correct it.

This was the case for me when I decided to learn about PassportJS for a personal project. And in this article I intend to dig into what I found most elusive about handling an OAuth flow with PassportJS.

If you need a full tutorial on how to implement PassportJS for OAuth, as always, I recommend the one by the wonderful Net Ninja on YouTube. Or if you just want a refresher about how to dance the OAuth, you can visit my previous article on the subject.

Index

Basic PassportJS setup
Calling authenticate
Road to the verify callback
WTF is serialize and deserialize
The complete login flow
The authenticated request flow

Basic PassportJS setup

These are the only things we need to get started: a passport strategy that's properly configured and 2 endpoints (one for authorizing, the other for redirecting) .

Calling authenticate

The great thing about Passport is that you can register any number of strategies with it and then tell it which one to use according to the route that's being called, using the authenticate method, like so:

passport.authenticate('github');

When you configure one of the strategies you'll have to define some parameters and also a verify callback function that will handle the user data it gets back from the provider.

The weird thing, at least for me, was the reason behind having to call passport.authenticate() in two different routes.

But here's the trick:

The first time authenticate() is called passport will try to find if it has a strategy by the name of the string you pass to the function previously registered. If it does, it'll start the OAuth dance by hitting the provider's authorize endpoint. If it doesn't find it, it'll just throw an error saying that strategy is unknown.

Now, the second time it's called is within a callback from the provider's OAuth server, in the redirect route. This time, though it looks exactly the same, Passport will detect that it's on the second stage of the OAuth flow and tell the strategy to use the temporary code it just got to ask for an OAuth token. The strategy knows exactly how and where to ask for that.

What happens after this?

Road to the verify callback

Have a look at my latest hand drawn creation, a diagram about the OAuth flow in PassportJS. At this point we're reaching that red bubble that says getProfile():

If this makes you more confused than before, read on; I promise it gets better!

The first thing that happens after we get the OAuth token is that the strategy fetches that user's profile. This is an internal mechanism of the strategy that knows where to ask for it on that specific provider.

Right after that, the strategy will try to parse the profile into a model it has defined internally for that provider, and then pass it with all the other data it has (accessToken, refreshToken and profile) to our verify callback.

Remember we defined the verify callback when we configured the strategy? Now is the first time our custom code in there gets executed by the strategy. In this instance we could check the database for that user, create a record for it if necessary and verify anything else that's needed.

Once we've checked all that we needed, we'll call done (or the callback of the verify callback) which is its fourth and last function argument. We'll pass it null (for no errors) and the user with all the information we find relevant.

(accessToken, refreshToken, profile, done) => {
  // verify things here and then...
  done(null, {accessToken, profile})
}

And finally, Passport will execute its very own req.login() which will save that user into req.user for further use.

Check that diagram up there again, you should understand it much better now.

Up next comes serializeUser 👇

WTF is serialize and deserialize

Serialization is the process of translating data structures or object state into a format that can be stored or transmitted and reconstructed later.
––Wikipedia's Serialization Article

In our case, "the data" is that user we've been tossing around. Our own custom code in Passport's serializeUser method should define what pieces of information we need to persist into the session in order to be able to retrieve the full user later by passing it to serializeUser's done callback.

This is Passport's serialize user method in a very simple form:

passport.serializeUser((user, done) => done(null, {
  id: user.profile.id,
  accessToken: user.access_token
}))

☝️this object will end up in req.user and req.session.passport.user for subsequent requests to use.

Now for deserializeUser, this function will receive the user data present in the session and use it to get all of the user's data from our DB. For example:

passport.deserialize((user, done) => {
  dbHelper.getUser(user.id)
    .then(profile => done(profile))
})

Whatever gets passed to done here will be available in req.user.

The complete login flow

Let's do a zoom-in of the previous diagram, specifically after the OAuth dance is over. I wanted to dig deeper into that because I remember it being particularly mysterious when I was starting to use PassportJS for OAuth.

So this is what happens after the user says "yes, allow" and our app gets their access token:

Passport receives an OAuth token from the provider
It uses it to fetch the user's profile information
The verifyCallback runs, and when it's done it passes the user object to its own done callback
Passport calls its own method req.login() which then calls serializeUser(). serializeUser extracts some user info to save in the session and then continues with the following handlers of the redirect route.

The authenticated request flow

Now, this is all very nice, but how does our app know that the user is still authenticated on further requests and that it can provide private information safely?

This is not a full tutorial, but if you've been following one, you probably have something like this in your server code:

server.use(passport.initialize())
server.use(passport.session())

These lines configure two middlewares that will run on every request that our server gets.

When an authenticated request is made, Express will load the session into the req, making our serialized user data available at req.session.passport.user.

Then, the first middleware, initialize(), will try to find that user in the request, or create it as an empty object if it doesn't exist (which would mean the user is not authenticated).

And then, session() will kick in which to determine if the request is authenticated by trying to find a serialized object in it.

When it finds it, it'll pass it to deserializeUser which will use it to get the whole user data (maybe from the DB) and add it to req.user where we can use it to create other requests.

So, even though serializeUser is only called on log in, deserializeUser is a global middleware that'll get executed on every single request to make the full user object available for authenticated requests.

This concludes my deep dive into the OAuth flow which I hope has helped you to understand what is going on behind the scenes of PassportJS at least a bit better. It surely helped me clear some doubts to write it. Thanks for reading!

While I was researching for this article I came across this wonderful unofficial documentation for PassportJS by J. Walton's which will surely help you in any other doubts you might have.

Figuring out CSS floats with two sushi recipes

anabella — Thu, 11 Oct 2018 16:37:33 +0000

This article was originally published in freeCodeCamp.

A few weeks ago I decided I should admit to all the things I’ve never understood about basic CSS. I would try to do a deep and conscious dive into them and finally get them. It seemed that now, more than a couple years after learning about CSS for the first time, I could use all the experience I’ve gathered to my advantage. This time it should be easier and clearer.

In August, I kicked it off with an intro to the mysterious pairings of the position property. Here’s my second stop in the journey:

The float property, in the form of cooking recipes.

Recipes Index

Sushi rows — make elements cover a full row in an even manner
Clearing broth — make content found below the floats act normally

Sushi rows 🥢

We'll use floats and percentage values to distribute elements evenly in the full (container) width. Just like sushi rows in a plate.

Ingredients:

1 container or board
Some sushi pieces you need to distribute side-by-side.
The % sign
1 float: left;

Instructions:

Prepare your sushi pieces, that is, the elements you want to be displayed in a row. They could be makis, item cards, nigiris, icons, whatever suits your taste.

You can also add any non-positioning styling to them: colors, text-alignment, fonts or soy sauce.

Put them inside a block container, like a board. In its most basic form, this should be a div (but you can use any other HTML5 semantic elements such as header, footer, section, article, main). Add a descriptive class for them. I’ll be using nigiri.

<html>
  <body>
    <div class="board">
        <div class="nigiri">
          <h1>/ / / / /</h1>
        </div>
        <div class="nigiri">
          <h1>/ / / / /</h1>
        </div>
        <div class="nigiri">
          <h1>/ / / / /</h1>
        </div>
    </div>
  </body>
</html>

<!-- Don't mind the `/`s, they're for the salmon's stripy effect. -->

Now, on class nigiri we'll apply some styles, including our float: left;. Take a moment and read through them:

.nigiri {
  margin: 0 10px;  /* fixed 10px margin and padding... for now! */
  padding: 0 10px;
  float: left;

/*  Extra things to makit look nice  */
  background-color: #fff;
  border-radius: 100px;
  box-shadow: inset -3px -6px 0 0 #ece0cd;
}

.nigiri > h1 {
  background-color: #fca35d;
  color: #fce2da;
  border-radius: 100px;
  font-weight: 100;
}

.board {
  width: 500px;
  height: 200px; /* we need this because floated elements don't occupy real Document Flow space, try removing it! */
  margin: 20px auto;
  padding: 10px;
  background: #CBAD8C;
  border-radius: 8px;
  box-shadow: 12px 8px 0 rgba(#000, 0.1);
}

What float: left; does is tell every element to stick to one side — in this case, left — and stand next to each other in a left-to-right row.

Note that we're adding height to the board. Normally we wouldn’t need this: the board would expand to fit whatever is in it. But floating elements, like our nigiris, are different: they don’t occupy real Document space and don’t affect other, non-floating elements. That’s why we’re using a fixed, pixel-sized height for the board.

Now, you should see all your elements on a single row. But something’s not quite right. They’re all piling up on the left and you probably have a lot of empty space on the right side of your board.

We need to space them evenly.

We can do that by setting the nigiri's width to be relative to their container (the board in this case) using a percentage value. But, for 3 elements, is it just 33.33%? Well, it's not that simple...

Now this is the tricky part: the % you need to set will depend on 3 things

how many items you have
how they’re structured inwardly (padding)
and how much space you want between them.

Do you want them to stick to each other side by side or do they need some margin in between them? If the sushi pieces have rice padding, that will cause them to be bigger than their content. You’ll have to compensate that by decreasing their width. For this reason, it’s also advisable to use % in the padding values.

I know al this can be confusing. Here’s a handmade single-press illustration that I hope can... well, illustrate it clearly.

Each nigiri is 33.33% of the board’s full width:

2% for margin on each side,
2% for padding on each side
and then 29.33% of their actual width.

But this is a recipe, not a math lesson. To make it easier for you, dear readers, here are some common combinations for shoulder-to-shoulder and margin-spaced elements, all with 1% rice padding:

/* Two elements in the row */

.two.shoulder {
  width: 48%;
  padding: 1%;
}

.two.spaced {
  width: 46%;
  padding: 1%;
  margin: 1%;
}


/* Three elements in the row */

.three.shoulder {
  width: 31.33%;
  padding: 1%;
}

.three.spaced {
  width: 29.33%;
  padding: 1%;
  margin: 1%;
}


/* Four elements in the row */

.four.shoulder {
  width: 23%;
  padding: 1%;
}

.four.spaced {
  width: 21%;
  padding: 1%;
  margin: 1%;
}


/* Five elements in the row */

.five.shoulder {
  width: 18%;
  padding: 1%;
}

.five.spaced {
  width: 16%;
  padding: 1%;
  margin: 1%;
}

Feel free to take as many as you want.

You may have noticed the pattern here: we’re assuming elements come with 1% of padding. They need to compensate that by subtracting 2% (1% for each side) from the element’s percentage width. Same goes for our 1% margin breather. Now it makes more sense to not use 33.33% width for 3 elements in a row. Instead set it to 29.33% after leaving 2% the padding and 2% for the margin on each.

Sigh… that was a lot of math. Ok so now, no matter how many pieces your sushi roll gets chopped in, you know how to present them nicely in a board.

If you want to play around with this setup, here's a CodePen specially made for that.

And if you like CSS sushi, don't miss Sasha Tran's very inspiring CSS Sushi Board.

Clearing broth 🍲

The perfect soup to have with some floating sushi, while making sure your portions don’t end up swimming in it.

Ingredients:

One container or board with floating sushi
A soup or broth to follow after it.
One clear: broth;

Instructions:

Once you have your row of floating sushi pieces ready, place your soup container below them in the html.

Our sushi is meant to gracefully float "above" the Document flow and not affect other elements. If we’re not careful they might just end up floating in soup and sushi-ramen is not something the world is ready for.

Remember that floating elements don’t have real Document height. This also means that they don’t “push” the soup down. Now look at this horrific mess:

To prevent this atrocity, we need to add our clear: broth;… I mean both;!

We have two options here:

We can simply put the soup in a bowl or container and give the bowl a style of clear: both;. This will sort of get the job done, but it will result in things like margin-top not working at all on the bowl.

So if we want the sushi pieces to be completely protected from soup flooding — and not lose any features in the way — we need them to be contained in a plate with a high edge. To achieve that we’ll add an :after pseudo-element to the sushi plate (that is, the container of our little nigiri floaters):


.nigiri-plate {
  background-color: #223;
  box-shadow: inset -8px -8px 0 0 #558;
  border-radius: 20px;
  height: 105px;
}

.nigiri-plate:after {
  content: "";
  clear: both;
  display: block;
}

The pseudo-element needs an empty content to even exist. Then "clear:both" and "display:block" are there for the purposes of this technique.

Below there's another example for you play around with. I’ve made the plate visible using height and background color. Even though that’s not necessary for the soup to be well placed, it just makes it look fancier 🎩

I've also front-and-centered the soup bowl with the classic margin: anything, auto; technique.

Think of this strategy as making the sushi dish have a very high southern wall in order to prevent any soup from flooding in. But… like… a nice wall.

All right, I’m super glad that you made it this far and I hope this tiny recipe book helped you get a better idea on how floats work… and how we can work with floats. Stay tuned for more deep-dive-into-basic-but-elusive-things like this 😉

Understanding the different pairings of CSS Position flavours

anabella — Mon, 27 Aug 2018 07:57:37 +0000

This story was originally published on freeCodeCamp.
Cover photo by Tom Hermans on Unsplash

The position property can be a mysterious thing to run into when you’re starting to learn about CSS. It’s like being given a set of unknown spices that look similar, but have very different flavours and the combinations between them don't always work like expected.

This article is an attempt to describe the best and most common pairings between them so that you can easily apply them in your first web cooking steps. Just like we learn in the kitchen — parsley goes well with garlic, but not that much with cinnamon.

Getting to know the properties

First of all, let’s define what each of the position variants tastes like:

Static

This is what every HTML element has by default. It means the element will be positioned according to the normal document flow. Block elements with full width, inline elements lining up. It’s basically the salt of them all.

Relative

Elements with relative position can be placed relatively to the space they would occupy in the normal document flow. They still occupy that space only, but support top, right, bottom and left properties.
Whatever values you assign to those properties will be used to calculate its displayed position using its real position boundaries. Like adding some pepper, it usually doesn’t do much harm.

Absolute

This one’s tricky — it’s sort of like cumin, it can be a very good addition, but you have to use it carefully. Absolute elements are removed from the normal document flow. This means they don’t affect and aren’t affected by other elements in the page. However, they will be placed relatively (yes, I know, bear with me) to their nearest positioned ancestor. This means whichever parent element that has its position explicitly set. It can be fine tuned using top, right, bottom and left too. So it’s similar to relative positioning, but, since it’s no longer part of the document flow, it uses a parent as the reference.

Fixed

Ah, this one’s easy. Fixed elements are not part of the document flow at all and their position is based on the whole window, sometimes referred to as viewport. Also, they’re not affected by scrolling.

Quick tip before we start cookin'

It's not advisable to use margin and/or padding when you're using top, right, bottom and left. While the latter will offset the element's visible position the first will offset its real and document-affecting position.

Things can get confusing if you're using both on the same element so best keep 'em separated.

So, how can we mix them?

Use position: relative; whenever you want to offset an element a little bit from where it would normally be, but you don't want everything else to move with it. Remember that all other elements will behave as if it hasn’t moved. Use top, right, bottom and left to adjust it relatively to what would have been its natural position.

Use position: absolute; when you care about where the element is in relation to its first parent or wrapper with an explicit (usually relative) position. Note for this that the position property does not cascade, so that's why this will use the nearest parent with an explicit position declaration, if there's none, then it will be the <body>. If you want to force cascading of the position property, you can declare it as position: inherit;.

Keep in mind that this element’s position is defined by the size and shape of its closest positioned parent, so if you change that, this element might be affected too.

Finally, position: fixed; is a funny thing to play around with. Normal usages include sticky navbars, footers, or side menus. Remember it’s out of the normal document flow, so this means:

you can place it wherever you want and nothing else will break
it also means that it won’t do anything else you don’t explicitly tell it to do, so you need to set its 2 coordinates for it to show up at all.

These 2 coordinates (namely, top or bottom, plus left or right) will be measured from the edge of the window.

(tip: scroll this up and down 👇)

Sticky Disclaimer

There is another option I didn’t cover and that is position: sticky;. It makes elements behave and scroll normally but then stick to a certain position while the rest of the content keeps on scrolling. I decided to leave it out, because it’s still experimental and exceeds the understand-the-basics scope of this article. But, if you’re curious, here’s an article showing what it’s all about.

I plan to address many of these basic things that I never fully understood about web development by researching them and then putting my new knowledge to the test by writing articles about it. So expect more in depth takes on basic stuff from me in the future!

Why do great developers love writing tests?

anabella — Mon, 06 Aug 2018 14:06:38 +0000

This article was originally published in Typeform's Engineering Blog

Part one: OMG I'm totally buggin!

I’ve been hearing about the importance of writing tests for years. No wonder, since during all that time I was working as a QA Engineer within a team of developers. I’ve heard about how important unit and integration testing is, the wonders of TDD, code coverage, you name it.

Agile teams and organisations kept talking about it, and for a long time I assumed it wasn’t related to my job. Even though it had the word “test” in it, it wasn’t the kind of testing I was involved with. So I just wrote it down in my mental “Book of Things That Are Good Things” and hoped that one day I’d grasp the reasons why it belonged there. I was clueless.

In the meantime, all those years ago, I was learning to code. I wanted to switch my career to development, or at least test automation. Sites like Codecademy were just getting started back then and I was going crazy with their free courses. Somehow it never caught my attention how the exercises knew when my code was incorrect, how come they usually had a pretty good idea of what part of it was off target.

After that, I did some more intense “classroom coding-courses”. There, I learned a little bit about the purpose of unit tests. They test every functional cell (or unit) of the code to make sure it does all that it is suppose to. Now, after letting this new definition sit in my head for years without giving it a second thought, I realised something new:

Unit tests don’t test outward facing features –like a login form or an endpoint– they test the inward facing functionality, making sure a piece of code can be properly used by other pieces of code.

Since I was learning some new tricks I was also starting to create small pet projects, either to apply what I learned or to challenge it by building something fun that I came up with. There were a lot of tedious sides to this: obsessively googling for solutions, not using git, figuring out what CORS is… you know how it is. But one of the worst things about my process (or lack thereof) was having to test every single use and edge case on every single change that I made.

If you’ve read this far, you probably know what I’m talking about. Either you’re experiencing it right now, or you remember it from when you were starting to develop real, working things. There’s no way of forgetting that tedious feeling of having to manually test every single flow variant each time you introduced a change in the logic. Or, worse, discovering a broken flow after a 3-hour-long refactor and not having a clue of when it had stopped working.

Now imagine a situation where all of that is covered by just running a command on the terminal, and watching a sea of green (and occasionally red) text unfold. Wouldn’t that be lovely? It definitely would, but somehow it still escaped my understanding. My projects are not “real applications”, I thought, they don’t need tests.

Part two: The end of my bone-as-a-weapon days

I’ve been working at Typeform for a about 6 months now. I’m part of a team that is very self-sufficient testing-wise and they don’t really need me to keep the QA hat on at all times. We do a lot of mob and pair programming and I get to take part in the development of features, changes, and fixes. I’m learning a lot with this experiences, but there’s one thing that always surprises me: when we finish a task, my teammates immediately want to write tests for it. It feels almost as if it were an impulse or an unconscious reflex, not something they remember they have to do. And somehow they always catch me off guard.

At those moments, I’m inclined to feel happy and relaxed. The fact is we’re done understanding the problem, discussing approaches and sorting obstacles, and finally got the thing working. I just wanna take a quick coffee break, but all they want to do is make sure everything is covered with tests.

And it’s only today, after almost 9 years working in the software industry, that I understood why:

These people care about code, and not only the code they write themselves. They care that it’s readable and maintainable, that it follows good standards, that it’s efficient and that it does everything it’s supposed to do, both inwards and outwards.

But, they work on real-world codebases, which tend to have a lot of code, in a lot of files, for a lot of features. And there’s only 24 hours in a day. They need a reliable and fast way to ensure that their change works and — most importantly — that everything else still works too.

Great developers love writing tests because they care about the code, and they know that (well-written) tests are the only reliable way they can feel more confident that it works.

They also know that if it doesn’t get tested when it’s fresh out of the dev oven, it probably never will. This is also why things like Test Driven Development (TDD) exist.

When you use a TDD approach, you start by writing tests for everything that you need to add or change. Yes, I’m serious. Write the test before you write the actual code. All the new tests will fail, of course, but then you write your code so that they all pass. You start by having coverage, then build the thing that you need to cover.

TDD has an additional value: focus. Only code that makes the tests go green should get written.

Epilogue: I hope the tests are as green as they have been in my dreams

My final point here is not to brag about getting to work side-by-side with great devs, but rather encouraging you to get acquainted with testing your own code sooner rather than later. Make it a necessary thing in your process. Not because it’s an industry standard, a good practice, or because somebody said you had to. Simply because it will no doubt make your life as a developer easier and happier.

An please don’t be like me, some things are too obvious to take years to put together 😉

Dancing with OAuth: a step by step guide

anabella — Wed, 04 Jul 2018 17:14:12 +0000

Dancing with OAuth: a step by step lesson

Most of the times I try to learn something new and put it into practice, I quickly start to feel like I’m lost in a myriad of dance moves. I’m desperately trying to find the right way to do things, while not really understanding what’s going on or how I ended up on the wrong side of the room…

Just trying things out until something works.

Maybe it’s because of the way my learning process works, or maybe guides and tutorials are targeted at more experienced or technical people. But, after I’m done wrapping my head around the subject, I always feel like there should be an easy guide for understanding the key concepts and making it easier to apply them in a project.

So this time, I’ve decided to stop wishing for it and make it myself, using the last thing that I learned.

And that thing was OAuth 2.0.

What is OAuth?

Let’s start with the basics: OAuth stands for Open Authorization. It’s a process through which an application or website can access private user data from another website.

This other website usually works only as a trusted identity provider. It gives the requesting app some basic information about you so that the app can create a profile. This way, you don’t have to fill in a boring sign-up form and deal with yet another password 📋

You’ve already used this at least a gazillion times, in fact you used it every time you clicked on “Log in with Facebook / Google / GitHub / …”. Next, you were shown a consent screen that displayed which information from your (let’s say) Facebook profile you’re allowing that-hot-new-app.com to read (and sometimes, write). After that, since that-hot-new-app.com trusts the identity provided by Facebook, they can create a profile for you on their database using the data that they received.

The communication between that-hot-new-app.com and Facebook usually ends here. This is why your profile picture won’t change all across the Internet if you change it on Facebook. They just never go back to Facebook and ask for updated data.

When marimba rhythms start to play…

There’s another purpose for building this kind of mechanism, one with way more potential: using the identity provider as a service provider (in an ongoing manner). This means communicating with it regularly to supply enhanced features for your users.

A nice example of this is Relive, a service that connects with different sports tracking apps to create Earth view videos of your run or ride. Every time you finish an activity, Relive prompts you offering to create a video from it. If you say yes, they’ll process it, and notify you when it’s ready for social media bragging… I mean sharing 🏅

There’s really no technical difference between these two usages. That’s why you should be cautious about where you log in with your social media or Google/Gmail account.

It might sound scary, but there's really nothing to fear. Just bear in mind that you’re authorizing that-hot-new-app.com to access that information about you that’s detailed in the consent screen, potentially on a recurrent basis. Be aware of the permissions you grant, and make sure you know how to disable them whenever you don’t feel trusting anymore.

For instance, if you are using your Google account for accessing that-hot-new-app.com but don’t want to allow that anymore, just go to your Google account settings and disable their access.

All the main identity providers offer control over this.

Grooming it up before you hit the streets

Before you land on that-hot-new-app.com and even click on “Log in with YourFavoriteIdentityProvider”, someone — probably a developer — has to create an application on the provider’s site.

This is a way of registering that-hot-new-app.com so that, later, the provider knows who’s asking for private data.

In this step, the developer will set up some information about the application, like the app's name or website and — most importantly — a redirect URI. The provider (like Google or Facebook) will use this to contact the requesting app and tell them that the user said yes 💍

Once the app is registered, the provider will give that-hot-new-app.com a clientId and a clientSecret which will be used in the communications between them. They work sort of like a username and password for the registered application.

It's very important that you keep your application information (redirect URIS, clientId, an especially clientSecret) in a secure location and don't share it with strangers. If someone gets access to them, they could request private user data from the provider on your behalf, and then use it for evil!

We don't want that.

Hands on waists or shoulders

Apart from setting up all those things, our developer has to find out what kind of data the provider gives access to, and how it’s segmented.

These “segments” are known as scopes and they define access rights, usually separated in read/write categories.

So, for example, that-hot-new-app.com can request for profile:read and contacts:read scopes. This means they can read whatever information the provider assigns to the “profile” and “contacts” segments, but they cannot change it. Other things won’t be accessible, for example your posts or what content you like.

Well, just to make things simple for now on, let’s say that that-hot-new-app.com is a website that integrates with Typeform, a service for creating beautiful and smart forms and also the company I work for 🤷. You definitely want in on the hottest thing right now, and quick, so on their website you click on “Log in with Typeform” to get right into the action. What’s next?

Here’s a home-made, organic, and cholesterol-free diagram to use as a map for the whole thing. It may look a bit complicated but don’t worry, we’ll examine each step up next.

Authorize: the first step in the OAuth dance

So, you take the initiative and click on “Connect with Typeform”. Here, that-hot-new-app.com (THNA from now on, ’cause I’m getting tired of writing dash-separated words) will send you to Typeform’s authorize endpoint (/oauth/authorize) and provide:

their clientId (remember, that’s THNA’s username)
their desired scopes (or access rights)
and their redirect URI again (Typeform already knows it from when we set up the whole thing, but we send it again as an extra layer of security)

That URL will look something like this:

https://api.typeform.com/oauth/authorize?client_id=yourClientId&scope=accounts:read+forms:read+results:read

Typeform will use this information to generate a consent screen where you can review what sort of things you’re authorizing THNA to see and do.

Once you have thoroughly read what you’re consenting to and happily click on “Allow”, Typeform will send you to the redirect URI with a temporary, like so:

https://that-hot-new-app.com/auth/redirect?code=xxxXXXxxxXXXxxx

Token: it takes 2 to tangOAuth 💃

All this back and forth feels like someone’s taking you for a tango spin, right?

The second step of the OAuth dance is when THNA receives that code, and exchanges it for an OAuth Token.

So at this stage THNA has a temporary code that represents everything they're asking for, think of it as an encrypted way of saying:

"Hey, remember me? I'm THNA, This user said I can look at their forms and themes. When you're ready, please send me a token for that to this redirect URI."

As reward for knowing all the steps and not stepping on anyone's toes, THNA will get a shiny OAuth Token ✨ which it can use to interact with Typeform on behalf of the user (that's you!) and ask for the authorized data whenever they need it.

Stay with me, sway with me

From now on, in every request THNA makes to Typeform on your behalf, they’ll have to include an Authorization header with that access token. With it, Typeform (or any other provider) can identify:

who’s asking for the data (in this case, THNA)
who’s the data about (you!)
and also make sure they have the correct authorization to access that data (only what you consented to).

Ready for the dance floor 👯

So now that you know all the steps and spins of the OAuth dancing technique you should be ready to create your own choreographies, I mean, integrations, and make the Internet an even greater place.

*Drawings by yours truly

If you're looking for a deeper, more hands on experience with OAuth 2.0 I strongly recommend The Net Ninja's PassportJS tutorial. It covers all the basics you need to know to set this up (in a NodeJS app), in a very well balanced theory/practice proportion. It was the turning point for my process in understanding all of this.