DEV Community: Daniel Bean

A front-ender's stumble into hybrid mobile apps

Daniel Bean — Mon, 25 Jan 2021 21:58:15 +0000

This article first appeared on the Triplebyte blog and was written by Aphinya Dechalert. Aphinya is an Angular-heavy, full-stack developer embarking on a series of learning projects with defined outcomes, documented through Medium and LinkedIn.

Once upon a time, I was part of a software development project that had an Angular-based front-end connected to a Java-based API. The decoupled layer made it possible to reuse the back-end in other spaces, and our Java dev did that cleanly for our mobile Android app ... until that person left the team.

What happened next was, in perfect timing, our boss decided we needed to add on iOS app to our suite – one that would launch alongside a refresh of our Android app. Since everyone remaining on our team was Angular-based, the way to get this done would obviously be to hire a couple of new native app developers, right? Wrong. The task fell to us. And though we all knew how to read and write Java, jumping into an Android development environment when we’ve been working on the front-end for so long seemed like it would have been a potential recipe for spaghetti code. Never the less, the team and I had to buckle down and make these new mobile apps a reality – and in a reasonable timeframe.

Hybrid apps became our solution.

Related: When task automation is worth your time

Hybrid apps in a nutshell

For the uninitiated, a hybrid app is a mobile app that is installed natively on a mobile device. However, rather than being developed specifically for Android or iOS, it's created on a different platform that compiles to be compatible with the native and operating system.

These hybrid apps often come with wrappers that allow them to be installed on the device, but under the hood, it is actually something else. For example, Ionic and React Native are JavaScript-based frameworks that have the ability to create cross-platform native mobile apps without the need to code in Java or Swift.

The idea behind hybrid apps is that they are coded once and deployable across different platforms. It is often used to cut down costs and development time required to create and deploy a feature or change. Parts of this code-once, deploy everywhere setup can also be extended to other platforms such as web and wearables.

While all this sounds great, how does it really stack up in real life? Back to my story...

Getting up and running

In our hybrid app scenario, we already had the Angular modules and a fully functioning suite of APIs. This meant that all we had to do was put our elements into Ionic, our platform of choice.

What did it look like in code?

Structurally, every layer of the Angular app that was available on the web application was good to go in the Ionic app. To do this, we installed and ran Ionic's tooling, which allowed us to tap into Ionic's CLI.

 npm install -g @ionic/cli native-run cordova-res

We then created a blank Ionic Angular app using the --type=angular flag. For example, starting up a hypothetical shopping Ionic app would look something like this:

ionic start shopping --type=angular

This will generate the scaffold files required to get you started. Once this is done, the Angular app sits inside the src folder. This allowed us to leverage our Angular knowledge and continue with the code as per usual.

So rather than building everything up from scratch, we just transposed all the other layers – the component, the factory, and service layers – over and created a new interface that was more geared for a mobile experience.

The good news: With only minimal bits of new Angular code needed to polish things off, we delivered on time.

It worked well and not so well

Now, despite this easy, breezy experience, I'd never go so far as to claim that native app development (and native app developers) don't have their merits. For one, the ease and accessibility of a native mobile app provides additional business opportunities, like simple push notifications.

The biggest issue that we had was keeping the desktop web version in sync with the native mobile code.

This is because we ran two different repositories and changes in one didn't always translate that well to the other. Over time, the team got split into two groups and new members came on board. Trying to keep the common parts between both repositories in sync became a mission that everyone eventually slacked off on.

After the team split and a few sprint cycles, the repositories moved so far away from each other that trying to swap code could potentially induce unnecessary bugs. This came up due to the lack of structural understanding from new developers who later joined the team. Each had their own idea on how to create modularity inside Angular but failed to consider the wider context of its usage between the two apps.

Even still, there were definitely things specific to the hybrid app approach we loved. For example, the ability to rapidly develop for both Android and iOS by using a hybrid app platform let us easily experiment and create A/B testing campaigns for visuals through external connections and configurations that didn't require any code updates. When data is king, testability is the queen.

Final thoughts

All in all, as the project veered off into its own spaces and the common code lost touch with one another, it begs the question: Was it worth it?

The answer is yes.

We had an objective with clear time constraints. Putting Angular into Ionic gave us breathing room when our team was understaffed and lacked the time to properly pick up a new skill. It also allowed a predominantly web-based team to quickly foray into the native mobile space and produce a robust application that everyone understood. It worked well when we translated existing code to Ionic.

The messiness only began when we started becoming too relaxed with ourselves and disregarded the long-term relationship required between the two applications to maintain the common code.

The speed of the sprints and the divergent trajectories eventually broke the general gains on the mobile app and its ability to share code with the web version. Trying to refactor one app to be like the other over time lost us the edge we originally had. As a result, the speed of development for both applications slowed as refactoring took over.

Despite all this, the hybridization provided a learning experience into how to deal with mobile apps – and the skills picked up from it were transferrable when we switched over to a Flutter and Kotlin stack.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

A guide to sensible composition in SwiftUI

Daniel Bean — Mon, 25 Jan 2021 21:48:42 +0000

This article first appeared on the Triplebyte blog and was written by Joseph Pacheco. Joseph is a software engineer who has conducted over 1,400 technical interviews for everything from back-end, to mobile, to low-level systems, and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.

The ease with which you can compose views in SwiftUI is a literal miracle. While composition is still doable (and valuable) in UIKit, the level of flexibility is at least an order of magnitude more rich.

But all this freedom brings some tough choices. How often should we be composing views? How many files is too many? Should we throw a component in a variable or an entirely separate named struct?

Here's a few thoughts to guide your choices.

Clarity is your sun

The single most important principle when deciding how to compose your views is clarity. It might seem that goes without saying, but it's easy to get your wires crossed.

There's a difference between optimizing for clarity and adding an explicit category to every possible grouping of views. The former makes your view hierarchy easier to reason about, while the latter just adds noise.

I'll dive into examples below, but if you find yourself feeling a compulsive itch to label stuff, take a step back and think again!

Reuse is your moon

The other reason we employ composition in SwiftUI is to avoid unnecessary duplication of code. In other words, reuse your views.

This can add to the clarity of your view hierarchy but it's also a distinct concern. Not reusing code has additional trade-offs beyond making your code less clear. It can also make it a nightmare to update, while also introducing bugs that come with forgetting to change all places in which a piece of view code has been copied and pasted.

Because of SwiftUI, composition on Apple platforms is easier than it ever has been before. So when you're tempted to copy/paste, remember it might be almost trivial to architect things in a way that your future self won't be cursing your name.

Variables (and functions) are your first line of defense

When _compo_sing our views (e.g. breaking them down into digestible _compo_nents) our first line of defense is variables. This means taking chunks of functionality out of your view's body and moving them elsewhere in the view's overall definition.

Variables are wonderful and definitely have their place, but they can also be misused.

For example, consider Apple's Reminders app. In particular, take a look at the view that displays a list of reminders:

If I were to implement this view myself, it might look something like this:

/// A view that displays a list of reminders
struct RemindersList: View {

    /// The reminders belonging to this list
    @Binding var reminders: [Reminder]

    /// The body of the view
    var body: some View {
        NavigationView {
            List {
                ForEach(reminders) { reminder in
                    HStack {
                        Button(action: {
                            if let index = reminders.firstIndex(of: reminder) {
                                reminders[index].isComplete.toggle()
                            }
                        }, label: {
                            Image(systemName: reminder.isComplete ? "largecircle.fill.circle" : "circle")
                                .imageScale(.large)
                        })
                        VStack {
                            Text(reminder.title)
                        }
                    }
                    .buttonStyle(PlainButtonStyle())
                }
                Button(action: {
                    // TODO: Add a new reminder
                }, label: {
                    HStack {
                        Image(systemName: "plus.circle.fill")
                        Text("New Reminder")
                    }
                })
            }
            .listStyle(PlainListStyle())
            .navigationTitle("My Reminders")
        }
    }
}

While this technically does the trick, it's also a nasty mess. It takes work to reason through, and the view isn't even that long or complicated. In order to see which views belong to what component, you have to look at each line of code and think. For example, does that HStack do something for the overall list, or is that associated with a reminder within the list? Is the second Button part of each reminder?

This is pretty bad, so we turn to some simple variables to clean things up:

/// A view that displays a list of reminders
struct RemindersList: View {

    /// The reminders belonging to this list
    @Binding var reminders: [Reminder]

    /// The body of the view
    var body: some View {
        NavigationView {
            List {
                reminderListItems
                newReminderButton
            }
            .listStyle(PlainListStyle())
            .navigationTitle("My Reminders")
        }
    }

    /// The views representing each reminder in the list
    private var reminderListItems: some View {
        ForEach(reminders) { reminder in
            HStack {
                Button(action: {
                    if let index = reminders.firstIndex(of: reminder) {
                        reminders[index].isComplete.toggle()
                    }
                }, label: {
                    Image(systemName: reminder.isComplete ? "largecircle.fill.circle" : "circle")
                        .imageScale(.large)
                })
                VStack {
                    Text(reminder.title)
                }
            }
            .buttonStyle(PlainButtonStyle())
        }
    }

    /// A button that adds a new reminder to the bottom of the list
    private var newReminderButton: some View {
        Button(action: {
            // TODO: Add a new reminder
        }, label: {
            HStack {
                Image(systemName: "plus.circle.fill")
                Text("New Reminder")
            }
        })
    }
}

Already, the body of the view is vastly easier to reason about. It's now clear that the list has two bunches of things in it: the existing reminders and the button to add a new reminder at the bottom. Even if you stopped your improvements here, it would be way better than before.

That said, these new variables themselves are still begging to be broken down further, especially the ForEach that holds the existing items. The layout for each individual item really should be its own thing. The problem is that each row relies on the current reminder to work, so we need a function rather than a simple variable:

/// A view that displays a list of reminders
struct RemindersList: View {

    /// The reminders belonging to this list
    @Binding var reminders: [Reminder]

    /// The body of the view
    var body: some View {
        NavigationView {
            List {
                reminderListItems
                newReminderButton
            }
            .listStyle(PlainListStyle())
            .navigationTitle("My Reminders")
        }
    }

    /// The views representing each reminder in the list
    private var reminderListItems: some View {
        ForEach(reminders) { reminder in
            view(for: reminder) {
                if let index = reminders.firstIndex(of: reminder) {
                    reminders[index].isComplete.toggle()
                }
            }
        }
    }

    /// Return a view for the given reminder
    private func view(for reminder: Reminder, _ didTapButton: @escaping () -> Void) -> some View {
        HStack {
            Button(action: {
                didTapButton()
            }, label: {
                Image(systemName: reminder.isComplete ? "largecircle.fill.circle" : "circle")
                    .imageScale(.large)
            })
            VStack {
                Text(reminder.title)
            }
        }
        .buttonStyle(PlainButtonStyle())
    }

    /// A button that adds a new reminder to the bottom of the list
    private var newReminderButton: some View {
        Button(action: {
            // TODO: Add a new reminder
        }, label: {
            HStack {
                Image(systemName: "plus.circle.fill")
                Text("New Reminder")
            }
        })
    }
}

In this iteration, we've created a function that returns the view for a particular reminder and used that within the remindersListItems variable. While this does add clarity, we're starting to run up against the limitations of functions and variables.

First of all, the code in this file is starting to get awfully long. While we've clustered things more effectively, we still haven't done a great job of making the file's scope easier to reason about.

Likewise, there's something that's not quite right about the function that returns a reminder view. In particular, the closure at the end and function syntax when using it within reminderListItems just don't feel so natural.

We need additional techniques.

Define separate structs as complexity demands

The obvious solution to address the awkwardness of the function in the example we’re working with is to turn each item into its own view. This both allows us to move a nice chunk of code outside of the list view while also making the API a bit clearer.

First, it allows me to keep the number of variables in my RemindersList to one per top level component in the body, which feels natural and clean:

/// A view that displays a list of reminders
struct RemindersList: View {

    /// The reminders belonging to this list
    @Binding var reminders: [Reminder]

    /// The body of the view
    var body: some View {
        NavigationView {
            List {
                reminderListItems
                newReminderButton
            }
            .listStyle(PlainListStyle())
            .navigationTitle("My Reminders")
        }
    }

    /// The views representing each reminder in the list
    private var reminderListItems: some View {
        ForEach(reminders) { reminder in
            ReminderListItem(reminder: reminder) {
                if let index = reminders.firstIndex(of: reminder) {
                    reminders[index].isComplete.toggle()
                }
            }
        }
    }

    /// A button that adds a new reminder to the bottom of the list
    private var newReminderButton: some View {
        Button(action: {
            // TODO: Add a new reminder
        }, label: {
            HStack {
                Image(systemName: "plus.circle.fill")
                Text("New Reminder")
            }
        })
    }
}

Second, it allows me to more meaningfully compose each item in the list into an API with its own component variables:

/// A view that displays a reminder in the context of a list of reminders
struct ReminderListItem: View {

    /// A closure trigger when the status button has been tapped
    typealias DidTapStatusButtonClosure = () -> Void

    /// The reminder displayed
    let reminder: Reminder

    /// The closure trigger when the status button has been tapped
    let didTapStatusButton: DidTapStatusButtonClosure

    /// The body of the view
    var body: some View {
        HStack {
            statusButton
            titleView
        }
        .buttonStyle(PlainButtonStyle())
    }

    /// The button that determines the reminder's status
    private var statusButton: some View {
        Button(action: {
            didTapStatusButton()
        }, label: {
            Image(systemName: reminder.isComplete ? "largecircle.fill.circle" : "circle")
                .imageScale(.large)
        })
    }

    /// The view displaying the reminder's title
    private var titleView: some View {
        Text(reminder.title)
    }

}

The question remains, should we continue to break this down further? And the answer would be no.

If you look at the ReminderListItem, the body is very straight-forwardly clear. It's an HStack with two logical components: the button and the title. A quick glance tells us all we need to know.

On top of that, moving the button out into it's own struct doesn't really add much value. Declaring it within the variable isn't very long, and using the variable "statusButton" in the view's body is logical and natural. In fact, creating a separate view would just add more complexity and work for us, so we skip it.

Finally, we could have put Text(reminder.title) right in the body, but adding it to a variable of the same form as the button creates nice consistency and better glance effect. And since in a real app that title would almost certainly have view modifiers attached, it gets that noise out of the body.

Eliminate noise beyond the scope of your views

There is, however, another thing we should do to clean up our RemindersList that's not necessarily obvious: Get rid of that NavigationView.

Why? The NavigationView is not really a part of the reminders list. It's a top-level controller that handles navigation from view to view. It's best defined in the parent of our RemindersList so we don't put ourselves in a situation where we declare more than one.

Besides, we want to keep our view definitions limited to the level of abstraction that naturally follows from their name. Navigating between views is not inherent in the meaning of a list of reminders. Likewise, we earlier removed a function returning each reminder view so all component variables could be more naturally tied directly to something declared in the body. The variables and functions you use should be limited in number and not nested in scope. Your variables should be flat.

Don't over compose

Finally, there's one more consideration to keep in mind: Don't over compose. The body of your views should always be a clear snapshot of the views hierarchy, and it should not be needlessly broken down. For example, you would never want to see a body with just one variable.

Now, go forward and create cleaner and more sensible SwiftUI compositions!

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

How to avoid looking junior in an iOS coding interview

Daniel Bean — Thu, 10 Dec 2020 00:58:03 +0000

iOS coding interviews can take a number of forms, including your typical algorithms assessments that aren't even done in Xcode.

In this blog, I won’t be talking about those. I'll be talking about the kinds where you're asked to build some actual app functionality (typically with an emphasis on UI) using the iOS SDK.

I've given hundreds of these interviews, and I've noticed certain behaviors that tend to correlate with a lack of experience with the native tools and frameworks.

Don't get me wrong. No single item here is necessarily definitive. The pressure of interviews can (and does) make even the most experienced iOS engineers forget their good habits. On top of that, this list isn't exhaustive. Interviewers will be looking for other skills, depending on the role, that aren't covered here.

Rather, these mistakes tend to be fairly common for one reason or another. And if you make enough of them, your interviewer is likely going to at least question your relationship to the platform.

Here's what they are, how to avoid them, and how to give yourself a leg up – especially if you're applying for a junior role but don't want to look junior.

Don't rely too much on SwiftUI

Your goal in a native iOS coding interview is to demonstrate strength with the platform. And not infrequently, interviewers will let you choose exactly which tools you use without much guidance, in order to gain insight into your go-to choices and habits.

Unless you're applying for a role where SwiftUI has been called out as the tool of choice, you probably shouldn't rely on it too much in your implementation.

It's not that SwiftUI is inherently bad. It's just new, and, in a not insignificant number of cases, not yet suited for production development. As such, most iOS roles will still primarily or entirely be relying on UIKit to build out their user experiences, so you'll really need to know its ins and outs for at least several years to come.

Besides, I've found that those who have chosen SwiftUI in my interviews tend to be candidates who are just learning iOS development, which makes sense. Certain basics, like throwing together a list of items on screen, is trivial to implement in SwiftUI compared to UIKit, so they choose the path with which they are most comfortable.

All that said, there are still two big things to consider about your use of SwiftUI:

If you are in fact new to iOS, and are only experience with SwiftUI, then an interview should not be the place where you're newly grappling with UIKit and you should definitely choose SwiftUI. Just start learning UIKit asap so you're ready when your next round of interviews comes in a few months time.
If you're experience with UIKit but just want to signal that you're tech-forward, use UIKit as your foundation and implement one or two component views in SwiftUI and bridge to UIKit. Just make sure you're extremely familiar with UIHostingController so you don't find yourself burning precious minutes wrapping your head around the nuances. If you're not there already, verbally mentioning you might consider doing x or y in SwiftUI and proceeding in UIKit is better than risking getting derailed.

Fully understand delegation (and data sources)

The use of delegates and data sources is a cornerstone design pattern in iOS. They're everywhere, and not fully and intuitively understanding how and why they work they way they do can lead to train wreck's in an iOS coding interview.

For example, I've had candidates spend nearly an entire hour session struggling to make sense of how to use the delegate and data source of a table view to properly display sections and headers, ultimately getting some really wonky results finally displaying on screen.

Even if you agree with this WWDC video that says classic data sources and performing batch updates "are old and dead," you should still understand these concepts in case you’re asked to fix broken code or build your UI without the new and improved diffable data sources. That said, you should definitely start learning how UITableViewDiffableDataSource and UICollectionViewDiffableDataSource work since they're far and beyond the better way to feed table views and collection views in 2020.

Utilize platform-specific helpers

Few things scream "amateur" more than trying to reinvent the wheel when you don't have to. And that of course goes for all of software engineering, not just iOS. It's a waste of precious (and expensive) dev time, not to mention typically introduces bugs.

In iOS interviews, this usually manifests as not utilizing some extremely well-developed and feature-rich API Apple provides in favor of rolling one's own naive solution, one of the most common examples of which is formatting data.

In iOS, we have these magical Formatter objects that give a million options for formatting numbers, dates, masses, lengths, energy and more — all in a way that adjusts based on the user's international locale settings. Yet, candidates will often attempt to format dates manually as if they're learning about strings in an undergrad CS class. And some who know to use these formatters might still struggle to use them correctly, reasoning through the basics of these classes during the interview.

It's best to familiarize yourself with basics like this prior to the day of. They're not that hard to understand, but the pressure of the interview makes everything harder. Take a little time to refresh your memory on helpful tools like this, and you'll find yourself coasting and signaling a solid embrace of the tools at your disposal.

Don't ignore cost and performance

iPhones and iPads just keep getting faster, with the line between mobile devices and the Mac diminishing with each release and custom silicon improvements. On top of that, many iOS apps only deal with a limited amount of data on device at any point in time, so iOS engineers aren't always thinking about asymptotic performance as a front and center concern like other kinds of engineers may be.

But as iOS engineers get more experienced, they start to pickup on a variety of performance concerns and quirks specific to mobile development that novice engineers tend to ignore.

For example, let’s imagine we decided to use a date formatter to display a string in one of our table view cells. This happens a lot:

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {

        /// Dequeue the cell
        let cell = tableView.dequeueReusableCell(withIdentifier: "reuseIdentifier", for: indexPath)

        /// Format the date
        let formatter = DateFormatter()
        let today = Date()
        formatter.dateStyle = .short
        let dateString = formatter.string(from: today)

        /// Apply to the cell
        cell.textLabel?.text = dateString

        return cell
}

While this works, it's a bad look, and many of you know why.

Formatters are expensive. All that magical, internationally-compatible functionality means there's a lot going on internally. And in this code, we have a new one being created every single time a cell is being configured! Instead, you want to create the date formatter once and store it somewhere it can be merely accessed repeatedly. Like so:

private static let dateFormatter: DateFormatter = {
        let formatter = DateFormatter()
        formatter.dateStyle = .short
        return formatter
}()

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {

        /// Dequeue the cell
        let cell = tableView.dequeueReusableCell(withIdentifier: "reuseIdentifier", for: indexPath)

        /// Format the date
        let today = Date()
        let dateString = Self.dateFormatter.string(from: today)

        /// Apply to the cell
        cell.textLabel?.text = dateString

        return cell
}

Ignoring details like this can signal one of two things: Either you're too inexperienced to know that there's a problem or you're experienced but careless. And while you may be trying to save time in the context of the interview, your interviewer may or may not give the benefit of the doubt.

It generally benefits you to not gloss over details like this in your implementation, unless you at least verbally explain that you are doing so to save time.

But if you happen to be on the junior side, that's ok. Interviewers don't necessarily expect perfection, particularly if you're applying for a more junior role. That said, if you're junior and able to demonstrate awareness and effort around at least some of these nuances, that can help you stand out as a generally thoughtful engineer who's ripe for growth. Do some research, talk to senior engineers about common junior mistakes, and you'll pickup most quicker than you think.

Know the quirks of your UI paradigm

If you're asked to build some native iOS UI, there's five ways you can do so at this point:

Purely in code using UIKit
A combination of code and nib files
A combination of code and storyboard files
SwiftUI
A mix and match of any of the above

Whichever you choose for the interview should be very familiar to you, including all of its little quirks and gotchas.

For example, I've interviewed candidates who were most familiar with building UI in code with UIKit but wanted to use storyboards for the interview to "save time." Seems like a reasonable idea, right? Not necessarily. Those same candidates ended up running into unexpected (and really basic) hiccups that actually burned more time than they otherwise would have, while also making them appear weak with the tools.

Consider the differences in the way you register cells with a table view:

If you're using only code, you'll call tableView.register(CustomTableViewCell.self, forCellReuseIdentifier: "customCell") to register your custom cell class with the table view.
But if you've laid out your cell in a nib, you'll need to register the nib instead with tableView.register(UINib(nibName: "CustomCell", bundle: nil), forCellReuseIdentifier: "customCell").
And further, if your cell is laid out in the storyboard, the reuse identifier needs to be defined there.

If you misuse any of the above, your cells are not going to show up in the table view. And if your interviewer is not allowed to give hints, it could take you the entire coding session to notice a really sneaky issue like this that you may or may not have ever run into in the past because you don't have experience with the allegedly "faster" paradigm.

Here's the thing. Since I've interviewed hundreds of candidates, I knew stuff like this happens, and I was sure not to give it too much weight. But you're more likely to have an interviewer whose performed an order of magnitude fewer interviews, and you could find yourself being harshly judged for what is ultimately a total fluke.

In short, don't make last minute decisions about UI paradigms based on erroneous data about what's "faster" or "better for interviews." If you choose a paradigm, get fully up to speed before using it in an interview or go with what you know.

Make some effort to separate concerns

Coding interviews can be contrived, and it can be confusing how much effort you should expend applying best practices, especially when there are significant time constraints.

While you should definitely check your perfectionism at the door, you shouldn't go to the opposite extreme.

That is, some candidates think it’s a good idea to completely disregard any semblance of project structor or organization in favor of shoving everything in a single file to save time.

This is usually not the way to go.

On one hand, I'm a big proponent of taking shortcuts to be strategic about time so long as you verbalize your rationale. For example, it's totally reasonable (from my perspective at least) to tell your interviewer that you'd normally have a separate view model for your view controller but that for now you're going to lean on a simpler MVC pattern to save time.

On the other hand, there’s entirely forgoing model classes, creating massive view controllers, and declaring every class in a single file borders on chaotic. Even if you give your interviewer a heads up about what you're doing, too many verbal exceptions makes it hard to follow your code and make a positive holistic evaluation. It might also backfire in terms of saving you time as well. It actually requires effort and conscious thought to go from writing readable code to rushed- through slop.

The idea is to strike a balance. And if you can, use a combination of verbal comments and actual code to communicate to your interviewer that you understand and appreciate foundational architectural patterns like MVC, MVVM, or whatever flavor you think is appropriate for the problem. Disregarding this completely can give the impression your production code might also be like the wild west, which is not something you want to be aiming for.

Next steps

The above examples are just some of the things that can give the impression that candidates lack experience with the native iOS tools and lead interviewers to question your performance and ability in production. That said, I want to emphasize that these are just signals that may or may not ultimately lead to giving such an impression. I've had candidates do things like this while also blazing super fast and revealing other advanced techniques, making it obvious they were competent and merely optimizing for speed. On the other hand, I've docked candidates points early in an interview for getting stuck on something insanely basic for a large chunk of time and make little progress only to discover they're great at later parts in the interview. The goal with these tips is to simply help tip the scales in your favor and avoid giving negative signals that are fairly avoidable with a little prep. You shouldn't obsess about being perfect, but a little awareness (and prep if you're junior) can go a long way to getting the interview results you want.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

Does your app need a prediction model or an inference model?

Daniel Bean — Fri, 04 Dec 2020 23:27:05 +0000

This article first appeared on the Triplebyte blog and was written by Coleman Harris. Coleman is a data scientist and current biostatistics PhD candidate at Vanderbilt University.

There are two major ways to handle the “data science” problems that arise at the end of an engineering pipeline – inference and prediction. The models, or ways that we handle these problems, appear similar but handle the assumptions we make about the data in very different ways.

First, let’s define what we mean by inference and prediction:

Inference: Using a model to understand the relationship of your data to some target feature.
Prediction: Using a model to best utilize your data to guess some future set of values for your target feature.

The contrast here is that in prediction, we are focused on best guessing the outcome, and in the inferential case, we are much more focused on understanding our data’s connection to the outcome itself. Take, for example, a streaming service predicting the next movie you will watch compared to it understanding what makes different ad channels funnel the most customers to the service.

In this case, we split up the data differently, we measure how “good” our model is differently, and we communicate the end result differently. And this difference is important – understanding why customers follow your ads is a separate problem from predicting a current customer’s preference to the next movie.

In short terms, the ultimate goal of data science, as well as engineering, is to make a decision, to solve a problem, and (maybe not as fun but ultimately important) to generate profit. Let’s discuss the ways each method is different and how to utilize it in your daily work.

Related: Tries, dictionaries, and queues: Applying data structure knowledge on the job

Feature selection

This graphic describes the different partitions of a dataset for a data science model.

In a prediction scenario, we often split the data into different “sets” that we utilize for different purposes. This typically is represented as a training dataset, used to train your prediction model, and a testing dataset that you then use to measure prediction accuracy.

Data scientists may also “hold out” an additional dataset for another measure of prediction accuracy, or iteratively split the dataset in a method called cross-validation. So in our streaming service example, we train a model on all of your streaming choices, except for the last 10 movies you watched. Then we test our model on those 10 movies to see how accurate it is at guessing your preferences. We want to avoid recommending Midsommar to someone who hasn’t even watched Casper the Friendly Ghost.

In contrast, scenarios focused on inference typically utilize the maximum amount of data available to build a model. Inference questions are generated in order to understand the impact or relationship of some feature to the target itself, rather than obtaining some reasonable measure of accuracy. So in this case, we would create a model on all of the advertising data we have to understand where new customers come from. Then we can ask interesting questions, like, "Is our social media advertising effective? What about the billboards we put up in Nashville? Do ads with white text on a dark background correlate with more customers?"

Since prediction scenarios are concerned with how accurate your predictions are, there is an added consideration of overfitting. There is a tendency to use as much data as possible in a modeling scenario to achieve only small gains in the measure of accuracy, whereas inference questions are focused on the interpretable, or practical, question of if a feature is relevant.

As should be evident by now, there isn’t a “better” way of approaching your modeling problems in terms of feature selection, rather the more "appropriate" way based on the questions you are asking. You should be willing to trade off a detailed understanding of how your streaming choices relate to new movies coming out for more accurate predictions, or be willing to sacrifice your accuracy to best understand the advertising streams bringing in new customers.

The different kinds of models (and measuring them)

Statistician Leo Breiman lays out the two different cultures of modeling eloquently in one of his seminal papers. He first argues for data models, which place an assumption that the target is drawn from some function of the features of interest. He contrasts this with algorithmic models which place no assumption on the data-generating mechanism itself, rather suppose that some function of the features can reasonably explain the outcome.

Data models tend to be most useful in questions interested in inference. Stronger assumptions on the way the data is generated allow for a more robust description of how the data impact the outcome. A data model is explicit about the impact of, say, whether an ad on social media affects the number of new customer sign-ups generated. These models, like a logistic or linear regression and elastic nets, can certainly be used in the predictive case.

However, as Breiman argues, we can sacrifice some of what makes “algorithmic models” useful when their focus is on using our data to reasonably predict the outcome, rather than explain some philosophical justification of the model itself. Like in predicting the next movie you watch: The data is not necessarily just the content you stream, but the things you search, the trailers you watch, the content you interact with. And an algorithmic approach doesn’t seek to understand why you clicked on Gossip Girl ten times last week, it just predicts One Tree Hill next.

Algorithmic methods like neural networks and random forests are widely used for their predictive ability – at the tradeoff of less interpretability. These methods combine complex “layers” of modeling to best predict the outcome, sometimes even learning information about the datasets that are difficult to identify as a data scientist. Because of the complexity of a component like a “node” in a neural network, it is difficult to describe the direct impact of the data on the outcome itself.

Hence modeling for prediction and inference is again about tradeoffs – do we want to optimize accuracy of the next movie choice or practical interpretability of where ad revenue is generated? We can utilize a logistic regression model for prediction or a neural network for inference, but the ultimate question is how we intend to use our model. As Breiman himself says, “The emphasis needs to be on the problem and on the data.”

Related: The hottest language Go-ing needs more engineers

What you need to know about implementation

Imagine a streaming service that has a dataset on 1,000 of its customers, with the following features: customer gender, signup source, signup interests, number of streaming minutes, and number of movies watched with Kevin Bacon. While Kevin Bacon is a token (albeit well-connected) example, a real dataset may include all of the actors and actresses available to the streaming service.

As a data scientist for this streaming service, you are tasked with two projects using this dataset: (1) informing the Marketing department of what drives new customer growth and (2) improving the recommendation algorithm built into the streaming service. Using the above graphic, let’s describe the different ways of setting up and implementing these projects.

Your company needs to understand how customer gender, where a customer signed up, and their initial interests all relate to attracting new customers. So, you build a logistic regression model using Python’s scikit-learn package, using all 1,000 data points to produce the most meaningful understanding of customer interests. This model yields ratios, or coefficients, for how related each feature is to becoming a new customer. Since the ultimate goal is to drive customer growth, understanding why new customers joined informs the Marketing department of better ways to place ads, and in turn generates more customers.

In contrast, you also need to build a recommendation algorithm for customers to use on your streaming service. Taking the customer gender, number of streaming minutes, and number of movies with Kevin Bacon, you dust off scikit-learn again and build a linear support vector machine algorithm to predict another movie. Since this is a prediction project, you split the data points into different “chunks” to approximate how good the predictions are. Once you decide on the best model, you can then deploy this into your streaming service, providing a better recommendation algorithm to customers.

Although the examples here are using Python, there are plenty of other meaningful ways to integrate inference and prediction into your projects, whether you are writing models in R or implementing an AutoML solution.

Communicating results

When focusing on inference, or interpretability, you will communicate results like, “Ads found on Twitter have a positive impact on ad revenue,” or “The way we engineered our ad revenue dataset to include features like text color and word count is a good way to understand ad revenue generation.”

And when interested in prediction, or accuracy, you will communicate results such as, “Using customer streaming data, we were able to predict the customer’s next movie choice with 75% accuracy,” or “Only using the last 25 streaming choices best predicts the customer’s next choice of streaming content.”

This shows further that the real choice of prediction vs inference in engineering is always going to be tied to what data problem you are trying to solve or question you are trying to answer. Once you identify your aim, your model of choice should be clear.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

Crush these metrics to become a more efficient engineer

Daniel Bean — Fri, 04 Dec 2020 19:52:34 +0000

This article first appeared on the Triplebyte blog and was written by Kattie Thorndyke. Kattie is a professional engineer who worked exclusively in motorsport and automotive engineering utilizing OpenFOAM open source CFD software to optimize full-vehicle aerodynamics.

If you were to ask a fellow programmer or software engineer: “How can I be sure that I’m being productive enough at work each day?”

You’d likely get an answer that’s as annoyingly unhelpful as this: “Well, it depends. It all hinges on what you’re trying to accomplish, how long you have each day to work on it, and what success looks like for that project.”

Don’t worry, I’m not going to leave you hanging. I’m going to give you actual tips, strategies, and examples of metrics that can be used to measure your productivity.

As engineers, we thrive on data. We need to see progress, improvement, and positive outcomes. Our brains are wired a little differently than the rest of the population, but we too fall prey to the anxiety of “not enough” — not enough lines of code, not enough hours of work, not enough to show for our efforts. It’s time to change that by harnessing a some key metrics to put things into perspective.

Related: When task automation is worth your time

Cycle times

When you’re working on a sizable project, it’s easy to leave the bulk of the work until you're closer to the deadline. I’ve been known to dawdle at the beginning of a large project only to then panic towards the end when the deadline is closing in. To prevent this, we need to set more reasonable cycle times, or the block of work that requires raw coding or dev work, to get through the workload.

For programmers, this is a common practice within teams that embrace agile methods. Two-week work sprints are often used to break down the project into manageable pieces and set a reasonable goal for the end of each sprint. In this way, we avoid procrastination and have to show progress by the end of the sprint.

If you’re working on a project yourself, you can break your program down into pieces that will logically build on one another, setting yourself a deadline every two weeks. What that management of yourself essentially amounts to is "definition" planning or lead time work. It can be a great idea to invest in this kind kind of work (which can include developing automations) if the result winds up being more efficient cycle times (coding/programming time) to come.

Of course, all of this structure and measurement allows you to document your progress and show your results to any superiors asking where things are at. If you can hit your two-week goals each time, you know you’re being productive enough.

Positive acceleration

Now, improving your work speed is an obvious plus, but in the engineering world, it's important to communicate things (and brag) with the proper metrics and language. Shortening dev work cycles is referred to as positive acceleration. For example, if it took you exactly two weeks to create and test a use case for your program in cycle one and a second attempt took you 1.75 weeks after automating a few features, you're showing improved work speed or clear positive acceleration.

In programming, the options for getting to positive acceleration are endless. You can monitor different aspects of your project that should accelerate over time, such as test case creation, simulation run time, documentation, and debugging. Even a very small positive acceleration is a step in the right direction.

Code efficiency and the metrics specific to your role

Zooming in on the work a bit more, it's true that every programming project, industry, and role will be different. But no matter where you’re working, ramping up your code accuracy and efficiency as high as you can will improve your overall effectiveness. A few main metrics here to keep an eye on are code complexity (how few lines of code can you use to accomplish a task), code coverage (how much of your code can reasonably test and review in a cycle), and code churn (how much of your work gets modified in review).

(Image: Pluralsight)

Beyond these, it is also important to define the metrics specific to your role that you should be monitoring for productivity.

To give you an example from my past work experience as a CFD engineer, I monitored a few key productivity metrics that I knew mattered to my organization. First, I monitored cluster idle time, which is a clear representation of how I was using the compute resources to their fullest potential. Over-provisioning of on-prem or cloud compute resources is a common cost overrun for companies. So, by showing that I was able to feed the cluster and keep it working 98% of the time, including evenings and weekends, I proved that I was productive enough.

I also measured a few metrics specific to the accuracy and efficiency of the code I was using. I measured the residuals of velocity components and turbulence characteristics so I could report on how confident I was in the results. I also measured how long it took simulations to converge and how that related to the accuracy of the results when compared to specific correlation cases. This allowed me to tell the story behind why I chose certain simulation techniques, and how I was able to maximize the number of simulations on the cluster without sacrificing accuracy.

Depending on your project and management team, you’ll adjust the metrics you monitor so you can communicate how productive you’re being. If you’re unsure, have a conversation with your team to confirm that your definitions of productivity match. These metrics aren’t just great data for your next performance review either; it helps to keep you constantly questioning your workflows and processes so that you're pushing the envelope and improving. And that is really the epitome of programming productivity.

Related: What the wrong side of agile looks like – and how you can avoid it

Simple tips to move your metrics in the right direction

Now, addressing the nitty-gritty of tools and procedures to improve the exact metrics you're targeting will certainly vary. But there are some simple things that really make a difference to your overall daily engineering output, and inevitably improve things like cycle times and acceleration. I, myself, have rolled my eyes at these suggestions in the past. That is until I spent time instituting them and realized how crucial they are to my success.

One of the biggest killers of productivity is multitasking, or task-switching. Whichever term you choose, it’s stealing your time. The more you try to do all at once, the less actually gets done over the course of the day. But what does this mean for a programmer?

When you’ve got a specific goal, task, or piece of code you’re working on, you need to have all other distractions strategically turned off. I mean your email, browser, cell phone, and social media must all be out of your sight, with notifications off. I actually tether my phone to the wall in another room. It’s just too tempting to interrupt your workflow when distractions are aplenty.

Next, consider how long it takes you to get down to work when you sit at your desk. Do you spend time trying to remember where you left off the night before? Do you get sidetracked by conversations happening around you? Take some time to be critical of your current work setup, and ask if you can do a few simple things to set yourself up for a productive day, like:

Set your to-do list for tomorrow when you shut down for the day.
Write yourself a comment or note to explain what you were coding before you take a break.
Put in your earplugs or earbuds before you start to work to block out any competing noise.
Set a Pomodoro timer for 25 minutes of work, and then allow a five-minute break to look at your email, phone, or to go for a coffee break. (Or if you are looking for a time blocking Pomodoro alternative, check out this blog from my colleague.)

I've found that applying these day-to-day strategies in your workflow can help you both hone in on improving the metrics specific to your role and shrinking the general lackadaisical drag that can gum up any meticulous engineering workflow.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

Getting noticed as a remote engineer – and why it matters

Daniel Bean — Sat, 21 Nov 2020 08:09:31 +0000

When you're a remote engineer, it's extremely easy to recede into the background. You don't share an office with your co-workers, so you can't rely on lunches and water-cooler chats to build relationships as normal.

And this can have serious consequences. Among them: It can lead to others seeing you as a cog in the machine — an avatar that spits out code — which isn't great for developing healthy working relationships.

Lucky for you, it doesn't have to be this way. There are tactics you can employ that will allow you to regularly reinforce your value, develop meaningful relationships, and gently remind everyone there's a human behind your Slack photo.

And this goes way beyond being more responsive to your email, from advanced social techniques to those specific to your role as an engineer. Take a look.

Related: How engineering salaries could get dinged by the remote work trend

Why 'getting noticed' matters‍

Experts say that the simplest forms of digital communication often lack the kind of empathy more prevalent in human, face-to-face interactions. (We’ve all seen this play out in contentious social media threads.) Unfortunately, this applies to remote work, as well: You’re just not going to be considered or treated the same as you would in person — which means you need to do actual work to mitigate your risks.

I’m not saying your coworkers are suddenly going to be nasty to you because you’re no longer in the office. I’m just saying it’s going to be harder for them to experience your full humanity if all they see of you is your deliverables and an occasional neutral comment represented by an avatar. Without an emoting face and personality attached, people tend to be more critical, less forgiving, and generally less human toward other humans whether they realize or not — and that’s not great for team cohesion (and your job security/advancement in particular).

On top of that, remote workers get lost in the shuffle all the time. They’re frequently passed up for promotions, judged as being less productive, and unfairly overlooked for high profile assignments simply because they’re out of their boss’s “line-of-sight." Fair? Nope. True? You bet.

“Getting noticed” is not about being an opportunistic attention seeker. It’s about putting yourself in the line of sight in circumstances that would otherwise be done for you if you weren’t remote. It’s about helping your team remember, despite the less savory aspects of human nature, that you’re a real person who’s regularly contributing meaningfully to the common good. And luckily, it’s easier to do than you might think.

Code your way to popularity

Beautiful code is important in any engineering setting, but it can really do wonders for your reputation as a remote engineer.

Imagine working on a tough problem. You come across some code that you need to rely on to get the job done. And. It's. Gorgeous. Methods are clearly named, comments are just long enough to be helpful but still concise, class hierarchy is nuanced but not over complicated. All in all, it's a joy to use, and most importantly, it makes your job materially easier.

You're going to notice the engineer who wrote that code. You might even develop a little "tech crush" or feel the slightest tinge of envy.

//
//  AClassThatWillGetYouNoticed.swift
//  TeamProject
//
//  Created by Engineer Worth Noticing  on 9/28/20.
//  Copyright © 2020 Your Company. All rights reserved.
//

/// A pithy yet enlightening class description
class AClassThatWillGetYouNoticed {

    /// A pithy yet enlightening bit of documentation
    func clearlyDefinedAction() -> EvenClearerOutput {
        /// Short yet readable implementation
                logicallyAbstractedHelper()
        ...
    }

    /// Feel free to git blame me for this!
    func logicallyAbstractedHelper() {
        let descriptiveVariableName: MostAppropriateType
        ...
    }
}

Now imagine you are the engineer who wrote that code and someone else is working on that tough feature. Maybe it's a colleague at your same level, or a more senior engineer, or your boss! The pleasure of engaging with your code is going to make an impression. And the more clear code you write, the more these one-off impressions will turn into a reputation.

It's a way of getting noticed without directly saying a word to anyone, so crack out your clean code books and start taking this more seriously than ever!

Be a ticket master

Likewise, you can also make an indirect impact by being a master of your tickets. That is, every ticket on JIRA/Asana/Notion is an opportunity to add value to the rest of your team in a way that simply can't go unnoticed.

When assigned new tickets, many engineers do the bare minimum necessary to keep them up to date. They'll eventually change the status when they're ready, maybe add a comment on occasion, but there's so much potential that goes completely to waste.

Each ticket can be a powerful source of truth for every task. And not infrequently, having transparency into your tickets will benefit other engineers on your team. Maybe a colleague can't get started on one of his tasks until you finish some aspect of yours. Maybe your boss is trying to re-evaluate the timelines due to some newly introduced business pressure. The more clarity you add to your tickets as you go, the more you are empowering your team to make better decisions.

As such, it's valuable to think of your tickets as scratch paper. Include checklists that account for all the steps you need to take until it's complete. Use the notes section to list your assumptions and strategy for implementation.

This way, your tickets are valuable in a similar way as your code. If your boss needs to get a better sense of how things are going, they can do so without even interrupting your flow and have confidence that the ticket is up to date and reliable. Likewise, your co-worker might be evaluating whether it's worth the effort to tweak the performance of their ticket, which depends on how performant your work is expected to be, and being able to check that reliably transfers that sense of confidence onto you.

In other words, by having exquisite tickets, you gain a reputation for someone others want on their team, because your tickets alone make everyone's lives easier.

Use Slack as your water cooler

When you're remote, it's easy for your humanity to get lost behind your avatar on Slack (or MS Teams or whatever you use). That is, you risk feeling more like a robot to your coworkers than a real person.

But if you're proactive about sharing content that's actually meaningful to humans, you might just pass the Turing test.

One way to do this remotely is to drive into your head that Slack is your office’s virtual water cooler (inside the appropriate or designated channels, of course).

You know how work chatter operates: Did you recently read an interesting article about how ML could solve the pandemic? Are you working on a side project wherein you just discovered an obscure but super interesting feature of a popular web framework? Are you pissed AF about App Store rules and penned a blog post yourself? Though you’d ordinarily bring this stuff up to your desk neighbor or to a co-worker in the office kitchen, you now have to remember to:

👏Share 👏This 👏Stuff 👏On 👏Slack 👏

And this will not only remind people that you exist, but that there's a real human behind that tiny photo who has interesting thoughts and opinions.

Don't get me wrong. I'm not encouraging you to be a show-off or to artificially come up with things to share for the sake of unbridled attention-seeking. That would be gross. I'm merely pointing out that, since you're not in an office, you need to be more proactive in your sharing in order for synergies with your coworkers to manifest organically.

So when you do genuinely find something interesting, and you think it would interest others on your team, put in that little added effort and share it. And make that into a habit that arises from time to time. And of course, engage naturally in any proceeding discussion that takes place. Put yourself out there!

Go the extra step through DMs and virtual coffees

Now, sharing your interests might convince your coworkers you're human, but you need more to establish yourself as a complex being they can see themselves having a deeper professional relationship with.

And for this, there are a few tactics.

First, periodically and privately ping your co-workers with a non-business-related, "How's it going?" For me, if I find I haven't connected one-on-one with a team member in a while, I'll just reach out on Slack and take a few minutes to get up to date. If they need help with something I can help with, I may offer my support if I can. If they mention an accomplishment, I'll offer my genuine congratulations. I may even complement someone on something awesome they did for the team. Anything is on the table so long as it comes from a place that's sincerely anchored in a desire for genuine human connection.

Further, you can schedule real social time with select co-workers. That is, for those you think you might get along with, schedule a 30-minute Zoom, Teams, or Slack coffee (call or video chat) to get to know them a bit better. You can discuss your journey as engineers, your hobbies and other interests, or anything else that pops up especially if this is a co-worker on another team. This gives you both the opportunity to see each other through different lenses, which will lead to discovering healthier ways to actually get work done together and beyond.

Cron job your check-ins

Along similar lines, having regular, one-on-one work check-ins with the right people is critical for deepening your most important professional relationships and keeping you at the top of their minds as a reliable contributor who knows how to set expectations.

As an engineer, your check-in with your boss and/or team lead is the most important, and should ideally happen for an hour or so once per week. This is an opportunity to talk through some of your challenges honestly, share progress updates, ask questions, and bubble up technical discoveries and obstacles that might impact timelines and delivery. It's also an opportunity to self-advocate for your accomplishments (which we'll get to later).

But your boss is not the only party you would benefit from having scheduled check-ins. Setting expectations with others who are impacted by your work can also add mutual value, and a face-to-face call is a great way to do that. For example, you might want to check in with your design lead every two weeks to get constructive feedback on how well you've implemented their designs. This allows them to give nuanced feedback that might not come up in bug reports while also establishing yourself as someone who cares about the product holistically. You might also be working with another team within engineering that your work directly impacts. Getting regular feedback from them on the clarity of your APIs and whether you're work fully meets their expectations will give strong team player vibes while also potentially avoiding sneaky setbacks that often come from missed opportunities for communication.

The point here is not to flood your calendar with meetings. It's to identify a very small number of key players and use short meetings to repeatedly reinforce your relationship by gathering data, providing data, setting expectations, and simply being human together. Doing so makes it possible for others to advocate for you because every meeting is an opportunity to reinforce your humanity and contributions in a way that would otherwise happen naturally in an office.

Embrace technical mentorship (in both directions)

Technical mentorship is also a great way to allow work relationships to flourish remotely, whether you're the mentor or a mentee. It adds a layer of agreed upon purpose and structure to a handful of your relationships that provides mutual value — and gives you a distinct presence on your team.

Now, you may be wondering how anyone can mentor anyone else when everyone has their own work to do. But this is not as incompatible with your responsibilities as it may seem.

That is, when a junior engineer comes to you for help, you don't need to stop what you're doing and spend hours working through problems with them. But you can take 10 minutes, hear them out, and see if you can nudge them in the right direction. Perhaps you know something off the top of your head that they don't, or see they are falling into a common pitfall that is common for engineers with their level of experience. Ten or 20 minutes of your time could save hours of theirs.

On the flip side, seeking out mentorship and asking questions is a great way to grow as an engineer while also demonstrating to a more senior team member your particular style of and thirst for growth. It can reveal inherent strengths that others might talk about as well as ideas for addressing weakness that will increase your overall performance in the long term.

Regardless of which side you're on, your presence will grow in the consciousness of your team members and actually add business value to your team in terms of actually helping others succeed. It's a win win.

Be vocal during group meetings (or follow up after)

A lot of us engineers are not exactly charismatic extroverts that garner lots of attention during meetings. There are exceptions, of course, but we generally have other strengths that tend to correlate with less vocal personalities in these kinds of settings.

Sadly, this can put us at a disadvantage — especially when working remotely.

The problem is that lack of engagement in meetings is often interpreted as apathy or a general lack of engagement in your work, even in cases where that's the furthest thing from the truth.

The good news is you don't have to be Steve Jobs to get noticed in meetings. You just need to regularly give signals that you're engaged. All you have to do is ask a few questions and perhaps share thoughts and opinions relevant to the topic at hand. Perhaps you need clarity from product about the business requirements for a ticket. Perhaps you want to alert your boss of an unexpected rate limit for an API your team is depending on. You don't need to put on a show, and you don't need say anything clever or especially interesting, you're just better served resisting the urge to be silent and say nothing at all — as can be so tempting to do especially in large, awkward meetings.

With that said, however, you might just not be the type of person who's comfortable being vocal, and that's totally OK. The next best option is to follow up with your team after the meeting is over. Add your questions and thoughts to a note, then ping the relevant parties on Slack right after. While you may not contact every meeting participant in every meeting, you may eventually become known as a person who prefers to follow-up later.

Self-advocate across the board

Regardless of which of the above tactics you choose to implement, something you should do across the board might take some getting used to: self-advocacy.

To be an advocate for yourself means to actively communicate the value you are adding at strategic times — without even the slightest hint of arrogance or entitlement. This might not seem easy, and many of us are pretty uncomfortable receiving compliments, let alone pointing out value we've created. But it's actually a lot less painful than it seems.

Let's say you're in a weekly check-in with your boss. They ask for an update on some mobile UI you're building. You could say something like this:

It's going well and should be done on time. No issues so far.

That would technically address her query, and it's generally positive so why bother saying anything else? Because it leaves out a whole bunch of detail that's relevant to her evaluation of your performance. So instead you might say:

It's going well and should be done on time. I was actually able to finish on-device search sooner than expected which allowed me to more thoroughly test my logic. I also used the new diffable data source API which simplified my implementation for updating the list UI dramatically, which allowed me to add some gorgeous animations that feel really fluid and natural. It looks delicious!

This is better for a million reasons. Not only does it communicate that you're ahead of schedule, but also that you used your extra time to refine your work both reducing QA time and showing care in your work. It also communicates that you were forward-thinking enough to experiment with the latest technologies but in a way that actually led somewhere. That is, your choice of using diffable data sources rather than the traditional approach simplified your logic which allowed you to add even more polish by way of sexy animations. And to top that all off, you punctuated your update with an enthusiastic account of how delicious the end result works, which further communicates you have pride in your work.

In other words, by providing transparency and relevant detail, you were able to tell a much more nuanced story about the level of value you actually offered while demonstrating even a bit of passion. It gives your boss a thorough account of how you're spending your time, eliminating mystery and open questions about whether your time was well spent. And you did all of this in a way that is completely absent of bragging. It's simply business factual.

The goal, therefore, is to use this level of nuance when communicating about your work in general. Of course, with each opportunity you should personally evaluate whether a given piece of detail is relevant, but if you determine it is, don't hesitate to go the extra mile and explain yourself. Once you get in the habit of doing so, you'll be self-advocating without even thinking about it and reap the benefits of radical transparency.
When you're a remote engineer, it's extremely easy to recede into the background. You don't share an office with your co-workers, so you can't rely on lunches and water-cooler chats to build relationships as normal.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

6 technical interview woes solved entirely by practice — not genius

Daniel Bean — Wed, 23 Sep 2020 01:08:29 +0000

Technical interviews are not just about your knowledge and experience. They're about demonstrating specific pieces of your skillset in really suboptimal circumstances.

Related: The best, worst, and most interesting moments from my marathon month of technical interviews

That is, technical interviewing itself involves a whole set of skills needed to pass. Candidates often focus heavily on specific knowledge gaps when preparing, while some don't prepare at all if they feel confident in their knowledge. What they don't realize is candidates fail just as often for lack of practice as they do for actually lacking the engineering skills required. Here are six features of technical interviews that are addressed mostly, if not entirely, by practice – experience and knowledge aside.

1. Artificial time pressure

The flavor of time pressure you experience in interviews is very different from the kind you experience on the job. Sure, you may be used to tight deadlines or putting out multiple fires over the course of a day. But rarely (if ever) is there a circumstance where you are asked to solve a problem over the course of exactly thirty or forty-five minutes. That is, the problem starts at a planned time, before which you know little or nothing about the details. Then a timer begins and you're given a document to read describing this brand new problem. From that point, you're expected to rapidly digest all the implications and solve it before an abrupt stop when the time runs out. That's not like anything I've ever done in the real world, and I suspect that's the same for most of us.

If you dive-in to this kind of situation with no prior experience, you're probably going to choke. The process is going to feel jarring and disorienting, even if the problem itself is well within your wheelhouse. But if you expose yourself to situations like this repeatedly, certain key habits start to sink-in. Eventually you'll find yourself snapping into action as soon as the timer begins, taking advantage of strategies that allow for the efficient digestion of the problem, and taking handy shortcuts that adapt to the limited timeframe. These are not things you want to work through for the first time during the interview, and being ready is simply a function of repeated exposure.

2. Contrived problems

Relatedly, the kinds of problems you're asked to solve in technical interviews are often very different from those you tackle on the job. That's because these problems are invented for the sole purpose of testing some set of skills some company happens to value for some reason at some point in time. As a result, the premise of the problem often smacks as contrived, the requirements can seem arbitrary, and the scope tends to be awkward in order to fit within the artificial time constraints.

For example, imagine being asked to create a word processor in a terminal with so few features that the end result would be completely useless to anyone who attempted to use it. Likewise, imagine implementing an oversimplified game nobody would ever want to play. Just the sheer pointlessness of problems like this can sometimes throw us for a loop in a way that a real-world problem with real meaning just wouldn’t.

Similarly, you’re often given problems that are so academic and abstract they can feel contrived even though they technically have real-world application. Here's an example from one of the most popular technical interview prep resources out there, Cracking the Coding Interview, by Gayle Laakmann McDowell:

Implement an algorithm to determine if a string has all unique characters. What if you can not use additional data structures?

Now, this might be a thing someone would want to do in some real-world context. The problem is that nobody mentioned that context when they presented the problem, so you have to just snap into the abstraction and move on. That can take some getting used to.

See, in the real world, problems have meaning. They are tackled in order to address actual business concerns and happen in the context of real world users with real world needs. And their scope is meaningfully nested within a coherent big picture of value creation. All of these things give them life that interview problems often just lack.

You may be a wizard at solving real problems, but totally flail on interview-style problems. I remember my first time in an interview. My mind protested for several minutes before I was even able to make sense of why the hell anyone would ask me to solve such a problem. But by that time, my chances of finishing the problem plummeted. The only way to avoid this is to expose yourself to a sufficient number of these problems so they become second-nature. They have a very specific style and structure that once you understand, will serve as the basis for quickly working through what is being asked in what is usually a contrived context.

3. Awkward coding environments

Have you ever started an email on a mobile device only to give up in frustration and pick back up on your laptop? Theoretically, as a writer of English, you should be able to express yourself equally well so long as you can type words, right? Wrong. If you're accustomed to doing all of your long-form communicating on a full-size keyboard, you have a whole career of habituated muscle-memory that allows thoughts to flow without friction.

The same principle, obviously, applies to code. If you're accustomed to a specific environment, it's going to be hard to code in another one. Yet some interviews not only require different devices and IDEs, they make you write your code in a way that basically zero engineers every write code: with a marker on a whiteboard. Again, you may have mastery over the content of what you're coding, but you are definitely going to run into friction if you've never felt through a new environment, and it could throw you entirely off your game. You need to get to know new environments before taking the interview – which, again, is simply a matter of practice.

4. Thinking in a new language

The programming language you use most often will not necessarily be the one you get to use in interviews. Some interviews give a finite set of options for candidates to choose from, or no choice at all. I've even seen interviews where the company required candidates to use a language other than the ones they'd frequently use on the job to confirm they are polyglots. And even if you can choose any language, a lot of engineers who frequently code in C++ for example will interview exclusively in a more flexible and expressive language like Python.

public void load_data() throws IOException {
    let url = URL(string: "...");
    File file = new File("...")
    std::*cout* << "This code is an abomination." << std::endl'
    ...
}

If there is any chance you will need to use a language other than the one you currently use every day, you need to practice heavily in that language before the interview. It doesn't matter if it's your favorite language that you used to use all the time. I've seen engineers who last used Python only a few months prior confuse it with their current language and forget how to do very basic things. If you don't get yourself in the mindset of the language you will use before the interview through significant practice, you're may to run into some serious hiccups.

5. Verbalizing technical concepts

Applying technical knowledge in code is not the same as being able to articulate it. Even though we use language to learn new technical concepts, they have all sorts of ways they finally sink-in to make up a working understanding to the point of being useful. As such, candidates who are legit experts in some topic or another find themselves tongue-tied in interviews (entirely aside from being nervous). It's because they've never had to find the words to comprehensively explain one topic or another (or at least it's been a very long time since they last did so). So, with limited time and judging eyes, they compulsively misuse technical vocabulary, present concepts in a disorganized manner, and appear way less knowledgeable than they may actually be.

The solution is to find another engineer you can practice speaking with. Attempt to explain technical concepts with complete, coherent narratives. Then give them permission to give feedback on whether it made sense and whether you covered all your bases.

6. Performing for an audience

Perhaps the single most trippy feature of technical interviews is trying to think, write code, and answer questions with one or more others scrutinizing your every move. At best, this can be distracting, and at worst it can be intensely anxiety provoking. Candidates who have little practice interviewing often cite this as one of the biggest factors that throw them off their game. Now while it may be hard to ever fully move past the awkwardness, practice does lessen the impact, at least subtly. You may feel anxious, but at least you're used to it somewhat. You may be a little distracted, but at least you're not also feeling that particular kind of distraction for the very first time. The more we do anything, the more it becomes expected and normal, even if it's unpleasant. So trying to do this as often as you can — either by recreating the interview environment with colleagues or taking real interviews when you don't necessarily need to — will slowly chip away at the adverse effects this factor has on your results.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

How full-stack are you? Here's how to chart it out

Daniel Bean — Tue, 25 Aug 2020 19:09:37 +0000

10 years ago, the software development landscape looked very different. The way it mostly went was front-end was front-end, back-end was back-end. There were clear lines and expectations for development.

Back then, being a full-stack developer made you a mythical unicorn.

Nowadays, everyone is at least a little full-stack.

We've all done it — tinkering with interfaces, interacting with APIs, writing our own rules and logic, and even a bit of booting things up into the cloud on the side. If you've been around long enough, there's a high chance that you've traversed through the different layers of “the stack.” If not out of necessity, then it's out of curiosity on the side.

On a technicality, this makes us full-stack — and that's what we tell the world, especially for job-hunting, where postings these days can have myriad of technical requirements. But how full-stack are you? Where on the spectrum of fullstackedness (if there is such a word to describe it) do you really sit?

Related: How to Choose Your Engineering Specialization

The Multi-Dimensional Developer

It's easy to become a “technical” full-stack, where you check all the boxes of having “some” experience with various layers of development but lack understanding and depth of knowledge in them.

As developers, we often start off as natives to one layer. Whether it be front-end, back-end, data, or infrastructure, we all begin somewhere first. To become proficient in that layer, we need to have a level of competency towards the five facets of development work: language knowledge, platform knowledge, logical thinking, architectural knowledge, and creativity.

How the Five Facets Work

Code is a language, which means it's a method of communication. It's easy to learn the syntax. But to apply it meaningfully — that's where many new developers, and developers moving to other layers for the first time, struggle. The five facets capture the other parts required towards mastering layer competency.

Here's a breakdown of what each of the five facets represents.

Language Knowledge

This is where most of us begin. We learn the language of a layer. We figure out how and when it's appropriate to place our {} , how to create classes and functions. We learn all about scopes, chains, arrays, and data structures. Language knowledge allows us to translate our thoughts into a format that computers can understand.

Platform Knowledge

Every platform has its own set of special requirements. Mobile web development differs from native mobile application development. Amazon's AWS differs from Google Cloud and Microsoft Azure. Back-end development in Node.js with graphQL is an alternative to Java RESTful APIs. Depending on the layer, each platform can break into smaller sub platforms.

Architectural Knowledge

How do you construct something that's robust and flexible but strong enough not to turn into a flop? Architectural knowledge often comes in the form of patterns. These patterns act as struts and beams to how things are done.

Logical Thinking

How good are you at modularizing ideas into concise parts that generate a particular expected outcome? How small can you make a problem and fit all the pieces together in a way that is mentally digestible? Logical thinking in code is the ability to create structures and relationships that are easily understood by others.

Creativity

As developers, we will always be limited by what we know, the constraints of our environments, and requirements. How good are you at working within these limitations and constraints? How far can you stretch the boundaries? That's basically creativity in a nutshell.

Related: The AI Skills That Generalist Engineers Should Consider Learning

When we call ourselves "full-stack," it can come across as being rounded in these five facets across the different layers. However, that is rarely the case.

A dev may have the technical knowledge to launch an application, but their lack of experience may hamper their ability to think creatively and architecture solutions based on platform-specific knowledge. This means that logical thinking is limited and synthesis of the five facets results in a sub-optimal solution.

A developer that's an expert in their layer often sits closer towards the edge of the five facets. The spectrum of a full-stack developer is much more complex because each layer has its own set of requirements.

Where on the Spectrum of Full-Stack Do You Sit?

If we were to put labels on the types of full-stack out there, we would have three types: the technical, the layer-heavy, and the transferable.

Here's an overview of what each type looks like.

The Technical Full-Stack

The technical full-stack is the developer that's done everything — on a technicality. They might have figured out how to launch a ToDo list into an app with the help of a tutorial. Their five facets on each layer is surface-level, putting them as the beginner of everything.

The Layer-Heavy Full-Stack

The layer-heavy full-stack is an expert in a particular layer. They are a native in either front-end, back-end, data or infrastructure. However, they may have moved between the layer, doing bits here and there until it results in a fully functional app. The other layers may be basic or minimal — but it's a workable solution.

The Transferable Full-Stack

This developer might be someone who is a layer or two heavy. They've got an advantage over others because they can see the patterns of their layer in others — that's why they're a transferable full stack. They're able to move between the different layers in a team setting and can produce something that's above the complete beginner level.

Next Steps

Using these archetypes as guides, you can figure out where you are on the full-stack spectrum.

Since the level of competency across the layers increases based on the types listed above, you might view technical, layer-heavy, and transferable as junior, intermediate, and senior levels of full-stack. But what we need to acknowledge is that we're all junior and intermediate developers at something. The strength of a full-stack developer depends on the cumulative experience levels across all layers, with each layer assessable through the five facets of developer competency.

To be sure, there’s nothing wrong with being a really competent layer-heavy full-stack dev, especially if that’s what your dream gig calls for. But if you have your heart set on being as full-stack as you can be, chart out your weak points and stretch your expertise in those layers in order to work toward achieving the distinction of transferable full-stack.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

Tricks for working asynchronously on an engineering team

Daniel Bean — Mon, 17 Aug 2020 22:50:31 +0000

Changing the way you manage your time is one of the biggest challenges when you start working remotely as a software engineer. When you're in an office, things have a way of working themselves out. When you're distributed, it's a whole different ball game.

You see, onsite work is to remote work as synchronous programming is to asynchronous programming. If you're used to the former, the latter requires a paradigm shift in the way you think about the basics.

But once you make the transition, your day goes from reactive chaos to predictable smooth sailing. Here’s what you need to know.

Related: In This Economy: Get Hirable Before You Need to (and Come Out Stronger)

Onsite Work Has Hidden Advantages

Think about what it's like to be in an office. Not only is everyone occupying the same physical space, but they are also sharing, for the most part, the same working hours. This is something most of us take for granted because we've never known anything else. And it has a bunch of nifty advantages — which we also take for granted.

For example, if you run into a problem while coding, there's nothing stopping you from popping over to someone's desk to get questions answered. You don't need to wait on Slack wondering if they saw your message, and you can physically see whether it's an appropriate enough time to politely interrupt for a quick question.

Remote Work Requires Planning

When you're remote, you simply cannot rely on such conveniences. You have no control over when your co-workers see your messages or choose to respond, and you usually don't have fail-safe ways of getting their attention. You have to proactively plan ahead for situations so your productivity doesn't get derailed when you're blocked. Software doesn't stop running when it's waiting on some thread to complete, and neither should you.

‘Strategic Multi-Threading’ to the Rescue

One of the most important techniques you have at your disposal is what I call "strategic multi-threading" (SMT). It's multi-threading because it involves multiple streams of work done in parallel (just like modern computer architecture), and it's strategic because it takes into account the limitations of the human mind.

That is, computers can task-switch arbitrarily without loss of productivity. Humans cannot. Every time a human task-switches, there is significant cost of mental energy and time to ramp up and down. So we need to be thoughtful about how and when we do it. Here's the process:

When you find yourself blocked, give yourself a reasonable amount of time to get unblocked. Task-switching is mentally taxing enough that you should give yourself at least half an hour before attempting to focus on anything else. You don't want to be waiting hours-on-end doing nothing, but you also don't want to spend energy starting something only to have your original problem resolved ten minutes later. It's ok to take a breather, and it's better for your productivity and the company. Contact who you need. Be resourceful about how else you might be able to get your questions answered sooner than later. Then relax and wait.
After half-an-hour, re-evaluate your situation and consider other tasks based on your circumstances. You should always keep a backlog or menu of light-weight things you can do that add business value but don't require deep thinking (and therefore high task-switching cost). Respond to emails, update your tickets on JIRA, get unrelated questions answered, make notes for tomorrow's standup, etc. If a co-worker said they'll be available in an hour, do a number of these lightweight tasks that are appropriate for an hour. If no one has responded, just start ticking off some items and re-evaluate again in an hour's time (or whatever makes sense based on the data you have).
If at some point it starts to seem like you might be waiting a few hours (or days) to get unblocked, it's time to dive into something more substantial. You may want to switch branches and work on some bugs. Perhaps there's a ticket that is smaller in scope than the rest. Ideally, you should choose something that you have a decent chance of finishing before you have to switch back to the original task you were focusing on. Deadlines are deadlines, so you will have to use your judgement. But if you can get away with finishing the new task before you switch back to the original one (even if you get unblocked before you're finished), then that's worth doing. And even if you only have large, sprawling tickets on your backlog, choose something that can be broken into smaller parts and complete one of those components. The idea is to reduce task-switching as much as you can while negotiating with the realities of your particular circumstances.

Pre-Thinking Reduces Need for SMT

SMT is great when you need it, but ideally you'd like to avoid task-switching as much as you can. One way of doing so is taking a little time to think about blockers before they arise. You can't plan for everything, and you certainly don't want to burn time chasing a hyperbolic number of imaginary problems. But you'd be surprised how useful a short pre-gander at your tickets can be.

That is, at the start of each sprint, take an hour or two to go through all of your assigned tickets. For each, do some light thinking. Read through the requirements to see if anything stands out as unclear or ambiguous. Think a smidge about how you might approach the task, so the more obvious problems present themselves. Your goal is not to avoid 100% of blockers, it's to quickly gather the low-hanging fruit.

As you go, write down any questions that come to mind. Then fire them off to all parties involved. Often, by the time you start a ticket, you'll have your answers so you can work with minimal interruption to your flow. Race condition avoided!

Pro-Active Communication Is Even Better

Pre-thinking is just one way to identify blockers before they are a problem. The way you communicate to your team during check-ins and meetings can also be invaluable.

For example, let's say you're working on some feature, and it's time for daily standup. Of course, be sure to include what you accomplished yesterday and what you plan to accomplish today. But it would also be valuable to state any assumptions you're making as you implement the feature. Perhaps you'd like to clarify the way you're interpreting one of the requirements so the product team has an opportunity to voice any objections. You may also want to state your assumptions about other technical components or APIs you're using, so other members of the engineering team can offer clarification if needed.

The idea is not to rattle off every detail you can think of. The idea is to be thoughtful of details relevant to other co-workers in a given meeting. The meeting is a shared space for collaborative thinking. If you share the most relevant details in your head, it will trigger others to contribute additional relevant details which will avoid blockers in the future.

Next Steps

Adapting to the asynchronous nature of working remotely is just one piece of the puzzle when it comes to managing your time effectively. There is also the problem of going from an office (which subtly structures your entire day for you) to an environment with no social cues and vastly more autonomy over your time. Stay tuned to the “wfh://engineering” series on Triplebtye for tips on that and more!

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

The hottest language Go-ing needs more engineers

Daniel Bean — Sat, 15 Aug 2020 16:06:44 +0000

This article first appeared on the Triplebyte blog.

Go skills are a hot commodity on the engineering job market. Right now on Triplebyte, the newcomer back-end-oriented programming language is the fifth most popular kind of tech stack experience that recruiters filter candidates by. In total, Go has been included in over 21% of all such searches on the platform since the beginning of the year.

But even though engineers themselves display as much of an interest in Go’s simplicity and power as tech companies, they aren’t running out to learn it. The language is merely ranked 20th for skills listed by candidates on Triplebyte (with only ~4% claiming experience with it). And this is while roughly half of engineers on the platform claim some experience with back-end development.

So how are companies who want to “Go” all in dealing with this seemingly problematic shortage of skilled-up engineers? And if you’re a back-end dev reading this now who doesn’t know Go, should you run out and learn it immediately? I spoke to several engineering managers hiring for Go engineers right now to find out.

Related: How to Choose Your Engineering Specialization

What’s Behind the Go Engineer Shortage?

Go was developed by Google, with its first full version getting a public release in 2012. In the following few years, the language started making its way beyond the search giant’s services and into the tech stacks of other trendy Silicon Valley companies.

Early adopters like Uber praised Go’s speed, simplicity, reliability, and its static typing. It wasn’t long after the good word on Go got out that companies of all shapes and sizes started wanting in.

“Go ticks all the boxes,” software engineering manager Stephen Pittman told me. His company, Merit, is in the process of converting from Scala to Go.

“In some ways it's the polar opposite of Scala,” he said. “It's a simple language, where there’s generally one way to do things. It’s fast. And it's kind of cool, right?”

Mind you, this mass adoption of Go on the company side is happening early in the language’s life, before it’s had a chance to gather many on-the-job learners and well ahead of it becoming a standard in engineering education. (For context, Python’s boom began in the middle of the 2010s, when the language was already over 20 years old.)

All of this is why (or at least why it feels like) there are more job postings today for Go engineers than experienced Go engineers available to fill them.

The Back-End Language You Can Easily Learn on the Job

Luckily, the whole part about Go being a “simple” language makes it a great fit for engineers to learn it at work quickly. Good hiring teams know this, Mixpanel director of engineering Aniruddha Laud told me.

“I would say 90% of the people that we’ve hired did not have prior [Go] experience,” he said. “And every one of them was able to pick up Go within a few months and become very proficient in the language.”

Even’s director of engineering, Aseem Kishore, told me that his company doesn’t necessarily seek out candidates with Go skills, either, despite Even being a full “Go shop,” as he put it.

This is an important difference with Go hiring. Because though companies commonly avoid hiring engineers based on specific languages or frameworks, it can often be necessary to get language-specific for hiring back-end roles.

“If you've used any language, Go is probably easier than that language that you've used. That’s not true for, you know, Clojure,” Laud said. “If you're an online shop who uses Clojure heavily, bringing someone along to train them to be a good Clojure developer is going to be a long path. With Go, that's not true.”

He added that Scala and Haskell are two other languages that can require costly ramp-up time for new hires if they don’t already have prior experience with them.

A snippet from gobyexample.com. Go can be a more verbose language, but its “one way to do things” method makes it easier to learn and code-review.

Laud’s takeaway advice for back-end engineers without Go experience: Don’t shy away from applying to Go jobs.

“Experience building performant back-end systems and infrastructure and distributed systems – that is the main thing we look for in hiring,” he said. “If you have experience using Java, or a bit of Scala, C#, C++, it means there’s a very good chance that you can easily understand how Go works.”

But Demand Remains For ‘Gopher’ Experts

Though some companies are happy to teach Go to new hires, there are still big (and profitable) opportunities out there for Go experts, or “Gopher.” as the language’s budding dev community has dubbed them.

“We're looking for someone who knows and has used Go, who can train the entire engineering team on standards and how to best use Go according to its strengths and weaknesses,” Merit’s Pittman said. He admits finding the right person could take a little time.

“We think that hiring people for a specific language is not the way to go in general. But, given this major strategic shift [toward this young language], we're breaking that rule.”

The numbers show that there is no shortage of companies who at least aim to hire for Go engineers this way. Hired’s most recent developer survey reported that experience with the language got candidates an average of 9.2 interviews in their engineering job search last year – the highest of any language skillset.

Related: The AI Skills That Generalist Engineers Should Consider Learning

And don’t think for a second that companies who are willing to hire Go engineers without Go experience wouldn’t still jump at the chance to bring in someone more familiar with the language if possible. Even’s Kishore admits prior experience is definitely still “a bonus” for a candidate in their Go hiring process.

And to be clear, being as competitive as possible for one of these jobs means a better chance at putting yourself in one of the highest salary tears in the industry. Stack Overflow’s 2020 developer survey reports Go engineers grab an average of $140K a year, taking a backseat only to Scala engineers, who make an average of $150K a year (but who also have to program in Scala, so meh).

Where Do We Go From Here?

It’s true that programming language fads come and … go. But since Go can bring a lot upside to varieties of tech stacks _and _it’s simple to learn, that gives it staying power and growing power.

"We're betting on the language," said Pittman. "That's a good way to put it."

If you’re interested in finally getting in on the Go wave but haven’t yet, don’t be bashful about applying to a Go engineering job and showing why your background makes you a great candidate for ramping up with the language quickly. On the other hand, if you want to be as competitive as po$$ible on the Go market, it’s not a bad idea to get started on learning it yourself and contributing to some open-source Go projects. Sure, learning new languages for free isn't everybody’s cup of tea, but something tells me the supply and demand condition ballooning Go salaries today won’t be around forever.

You're doing rubber duck debugging all wrong

Daniel Bean — Tue, 11 Aug 2020 18:07:38 +0000

Would you believe it if I told you that something called "rubber ducking" is actually one of the most insightful debugging techniques ever suggested? When you run into a programming snag you can't figure out, just find a rubber duck and start talking to it about your problems. Sold, right? Me neither.

I actually love rubber duck debugging, but not in the way it's usually explained. Turns out, it's hard for adults to take seriously the idea of talking to a literal rubber duck on their desk. And even if you guessed the duck is not really the point, you'd be surprised by how many engineers miss the point entirely. In this article, I'm going to explain what rubber ducking is, why it does actually work, and provide a step-by-step process for the way I do it that I think can change your debugging chops for good.

Related: Git Should Rename the Blame Command

History of the Technique

First, a little history. The Pragmatic Programmer is one of the most legendary programming guides out there, so it's no surprise that the idea of rubber duck debugging was first introduced in its pages. For something so popular, the only mention of it takes up three small paragraphs in a section entitled "Rubber Ducking." Thomas and Hunt explain:

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and nod his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself. [...] It sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through the code yourself. By having to verbalize some of these assumptions, you may suddenly gain new insight into the problem.

Every single word of this is true for about a million reasons, but we'll get to why later. Notice, however, exactly what they say. Find a person and explain the problem. A human. Not a rubber duck. The only reason they call it "rubber ducking" is because they knew another developer who placed a rubber duck on his desk while programming, and they only imply, tongue-in-cheek, that he used it for this purpose. At no point do they actually recommend you attempt to apply the idea by using an actual rubber duck.

Rubber Ducks Are Not for Talking

Now, it’s not always easy to find a coworker who can spare time to listen to your coding problems, and that’s a big reason why we’ve seen engineers over the years take this described “rubber duck” debugging technique literally. But even though these imaginative thinkers swear by their problem-solving process (and bravo to them!), it turns out that most engineers actually either don't feel comfortable explaining code to a toy or report back that it doesn't help them at all. I'm in the camp of believing that talking to an inanimate object is the dictionary definition of "meaningless." But that doesn't mean I think you need a human at your desk to play out The Pragmatic Programmer's debugging process.

**How Talking Out a Problem Actually Works**

I think the rubber ducking method hits on the great idea that communicating your problems can help you work them. When you force yourself to verbalize something, you take poorly formed mind-stuff and slot it into discretely packaged concepts (words) whose meanings are agreed upon by other humans. This alone adds an important layer of organization to your thinking by taking non-verbal soup and giving it shape.

Related: How I Learned Algorithms – Against All Odds

But there's another, even more important layer: your audience. When you have an actual audience, your mind snaps into this special mode of operation. Suddenly, everything is oriented around the goal of successfully communicating. Your mind no longer takes shortcuts based on things you already know. Rather, when it comes across those shortcuts during the communication process, it notices them, and attempts to verbalize them in addition to everything else. This is where the magic really happens. The onus of having to make someone else understand forces all of your assumptions to the surface and then further into words so they can be communicated. It's usually then that you have an aha moment and notice some basic thing that has been hiding formless under the surface and leads you to solve the problem yourself.

This typically does not work with a rubber duck. At the very least, you need to imagine a real audience. Again, this might work for the more creative-minded among us, but it doesn’t for me.

The Best Way to Rubber Duck (Without the Duck)

As if by some miracle, there's this thing we have where engineers can talk to a real audience about real programming problems. They can do it as themselves or anonymously. And they can expect to get real answers that may actually help them solve said problems — thereby setting the perfect stage for meaningfully verbalizing the question to begin with. This thing is called Stack Overflow.

Folks... the day rubber duck debugging clicked for me is the day I solve my first serious Stack Overflow question. It was a real beast. I was a junior developer, and I was stuck for days on my own, not secure in myself enough yet to ask for help from those I knew. So I put a lot of work into formulating this question. I maybe spent an hour or more. I wrote several lengthy paragraphs explaining all the details. Then it happened: the answer "leapt off the screen and announced itself." I started giggling to myself like a weirdo. My coworkers noticed but I didn't care. I had solved the problem before even posting the question. It felt so so sooooooo good.

Alas, folks. The best way to do rubber duck debugging is to find a real audience and rigorously ask your question. Stack Overflow is not the only option, but it's incredible because you can do it privately, on your own schedule, and get feedback on how well you asked the question — further pushing you to clarify your thinking! Here's the step-by-step process:

Anchor on a Meaningful Audience: Imagine you're explaining the problem to someone who might actually be able to help you. As you're writing, assume you're talking to this person or group of people. Doing so will help frame your question in a way that is more meaningful to your goal and allow the words to flow.
Let Go of Assumptions: On top of that, assume your audience knows little to nothing about your specific situation. While they may be capable of helping, you don't actually know the way in which they will turn out to be helpful. They might know nothing about the specific tool or framework you're using, but point out something way more fundamental that you would never have thought of (like some OS or network issue). Internalizing this reality will help you avoid glossing over important details that need to be verbalized, organized, and checked.
Explain Everything: Give the full context and background of the problem. Force yourself to articulate all of your assumptions, and explain why you believe each assumption to be the case. Explain everything you've attempted so far. Explain what you expected to happen, and why you expected it to happen. Then explain what's actually happened, and why you think it might be happening. Follow this up with other rabbit holes you might consider going down, and why you think they're worth exploring. Then explain anything else you think is relevant. And why. This might be messy at first. You might be overly verbose or disorganized, but it will get better and easier the more you do it. And if you use Stack Overflow, you will probably get feedback on how to be more clear, which will help you along even further.

The more rigorous you are, the more likely you are to have a eureka moment. And a bonus that you don’t get with the duck: You might actually get a real person (albeit on the other end of the internet) to chime in with extra helpful info about your problem!

Final Thoughts

It's ok if you want to have a rubber duck on your desk. The truth is, having it there is a great reminder to take this improved approach. The idea behind rubber duck debugging works. It speaks to something fundamental to the way human minds work that transcends programming entirely. Ever heard of the Socratic method? That's rubber duck debugging in philosophy. How about talk therapy (aka psychotherapy)? That's rubber duck debugging for your mental health. The point is, the principle behind this technique is everywhere. Slow down your thinking, verbalize it, ask probing questions about assumptions, then reveal reality. Then like magic, problems get solved.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.

What kind of programmer are you: Startup or Big Tech?

Daniel Bean — Tue, 04 Aug 2020 18:12:38 +0000

This article first appeared on the Triplebyte blog and was written by Stephan Miller. Stephan has been a full-stack, mobile, and machine learning developer for two decades and has written code for companies both big and small, both startups and established businesses.

Just about any company you can imagine is in the software industry. If they don't build their own software, they buy it and, in some cases, provide support for it. Considering all the potential technologies, languages, and frameworks that are used by businesses today, there is a seemingly endless choice of jobs for modern software engineers, and each requires a unique skill set.

In my experience as a full-stack developer across quite a few companies, one of the most effective ways to simplify the complexity of the software engineering landscape is to separate companies into startups and Big Tech, with a small middle ground that includes companies that are a mix of both. The environments and cultures of each group are different, as are the skills that engineers are required to use.

The Startup Scene

Shows like “Silicon Valley” and movies like “The Social Network” dramatize life while working at a startup, and they definitely got some of it right. (Though fortunately or unfortunately it's not often as hilarious or dramatic.) There can be a mix of pure chaos, long but flexible hours, and pivots to new business models on the fly. A startup has to hit the ground running and prove it can attract enough users to make a profit. This key dynamic dictates the work environment and the skills we all need.

Full-Stack Development: In my experience, at all the startups I have worked at, employees wear many development hats. At one startup, I started working on middleware, databases, and deployments because we needed those first. After the company hired more people, I worked on the front-end for the rest of the project. I still helped with the other parts of the system as needed.
Cutting-Edge Technologies: Most of us in the business will find the newest and latest technologies at a startup. At one startup, I learned machine learning, WebGL, and graph databases for the first time. You might end up spending a lot of your free time learning these new technologies because the deadlines are still tight.
Open Source: Startups love open source code because it's free. I’m more used to seeing JavaScript, Python, Java, and MySQL at startups, as opposed to Oracle Database or C#.
More Flexibility and Responsibility: At a startup, job requirements and parameters may be less defined. I’ve had designers on my team who were just as busy as I was juggling multiple projects. Sometimes, engineers just have to use their best judgment to finish a task.
Technical Debt Buildup: At a startup, we’re required to get things done fast. Changes in design often happen on the fly, so the nice, tight structure of the codebase you started with can turn into a mess pretty quickly and need to be refactored. It takes time to write good code, and there’s rarely an abundance of time at a startup.
Less Testing and No QA: I have yet to write genuine unit tests at any startup I worked for. They were often mentioned as a good thing to have, but we just never seemed to get around to writing them. And you may not have QA, either. Engineers have to test their own code thoroughly, or we end up pushing hotfixes in the middle of the night.
Heavy Workload: I’ve never been bored at a startup. There are always fires to put out and technical debt left over from late-night coding sessions.
Less Infrastructure: At a startup, some things may not work quite as expected. Deployment procedures may not run smoothly, or an engineer might have to log in to Linux servers at midnight to see why the new version of code is not live.

The Silos of Big Tech

Large companies have more structure. They burn the midnight oil less often, but employees most likely will have to be at your desk during business hours. There will be a clear hierarchy of authority and rank at the office, and staffers are likely to have a static job description. So how does this environment affect the skills you need for the job?

One Technology: You won't need to be a full-stack developer at a large company. If you are a database developer, you will only work on databases. If you are a web developer, you won't have to deploy your code. Just write it and commit it.
Legacy Code: You will find a lot of legacy code at most well-established companies. The company has been around for years and the code base will build up over time. If the old code works, there is no reason to change it — until it doesn't, and some engineer is tasked with updating Perl code or outdated ASP pages that haven't been touched in years. I have been that guy. It’s not fun.
Proprietary Software: Historically, Big Tech tends to trust well-established companies for their software. This has changed a little, and you will find more open-source code in enterprise codebases, but chances are you will find technologies like SQL Server, Oracle Database, and C#.
Strict Requirements: In a Big Tech company, the requirements for a task are usually detailed. There will be very little "winging it".
More Standards: At a Big Tech company, software engineers have plenty of time to refactor their code. It may have to meet coding standards and style requirements before it can be merged. It will also have to pass peer reviews to catch any issues missed by the automated tools.
Testing and QA: Engineers at big companies often have to write unit tests, integration tests, and UI tests along with the code they write to finish a ticket. There will also be a QA department that will send a ticket back for rework if it doesn't fit the detailed requirements.
More Downtime: With all the processes and procedures in enterprise development, I always think I’m going to have less free time at a big software company, but the opposite is typically true. You will have plenty of time to clean your desk and maintain inbox zero.
A Well-Oiled Machine: While some parts of a big company's technology stack may be old, it will be dependable. When you commit code, you can forget about anything that happens afterward. It went through linting and code review. Automation will take it from there.

The New Engineering Department

Not every engineering department in a large company runs like an engineering department in a large company. Right now, I work at a 20-year-old company with more than 1,000 employees. Three years ago, they got tired of dealing with software vendors, so they bought the vendor and started their own engineering department.

In my experience, writing code in a new engineering department is kind of a sweet spot for a developer who doesn't want all the chaos of a startup but is not yet ready to settle down at a large company, either. Your team will start the department from scratch, just like with a startup, but the pressure will be on to create structure and procedures for how the department will run. In this scenario, engineers actually have a say in what these processes and procedures will be.

The Spinoff

And then we have the spinoffs. Sometimes an established company will launch a whole new company under its umbrella. These types of companies also run like a startup, but since there’s a parent company, there are some distinct differences.

In my experience as a developer at one spinoff, this is another hybrid environment. Software engineers don't see the long hours of a standard startup because they tend to follow the parent company policies. They tend to have more input on what their technology stack will look like, but there may also be tools that the parent company insists that they use because they’re already bought and paid for.

What This Means for Software Engineering Jobseekers

At a startup, engineers write more code. They will require you to push it out faster, and chances are you will work on the front-end, back-end, middleware, and database. They might even do some DevOps work.

In a larger, more established company, engineers will write less code in one part of the application, but they’ll still be required to comply with more standards, follow more processes and procedures, and write more tests. You should choose a path based on what type of experience you’re looking for, where you are in your career, and the skills you want to put into practice.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.