Torc blog

The second in our series of spotlight interviews with members of the Torc team, I spoke with Torc CTO and Co-founder David Messinger about his time before Torc, his thoughts on the changes in remote working over the last two decades, the Torc community’s impact and influence on its platform, and more.

‍

Q: So the first question is, can you please tell me a bit about your background pre-Torc? 

A: I was originally a computer science major. I later worked primarily as a back-end developer. I found myself in the right place at the right time, working with some of the cutting-edge tech of the era on some of the first e-commerce sites, such as priceline.com and Best Buy. After that, I left and went to Topcoder, which was one of the earliest gig economy remote worker platforms out there. We were at the forefront of using developers from around the world before it was really popular.

After that, I went to a company called Appirio, where we started another crowdsourcing company called Cloudspokes, which was built inside Appirio. Appirio was the first true cloud SI. We did Salesforce, Google, and Workday, and we were ahead of the curve on cloud computing at that point…it was very early on when cloud and Salesforce first started.

So, I’ve been around for some good times, and I’m excited again right now with Torc and seeing AI be the next big wave. Being involved in that is another really important moment in my career and in tech as a whole.

Q: I saw on your bio page on the ‘about Torc’ section of the site that you've been working with remote developers for 25-plus years. What initially attracted you to that? 

A: If you think about it, being on the internet was kind of the great equalizer. For example, when I was in high school, and later in college, I was a pretty decent poker player. But that was when I was playing against people in my college, or in my dorm room. Then, once I went online, I played against people that were 100 times better than I was.

Yeah, I’ve had the exact same experience.

I think everyone has. And not just with poker, even something like playing Madden football for example. Same situation.

When we started Topcoder early on, it grew quickly, very organically, and went international. And when you see the talent of some of these people…it’s amazing to see another person you’re working with who lives halfway around the world is 8x better than you. It's a humbling experience. I always like to work with the best people possible. It makes you learn and creates a more fun environment.

Absolutely. I mean, talent can come from anywhere. And having access to that is a great thing for everyone. Plus, some people don't have the opportunity to work for companies like Torc in their home countries, remote working opportunities have changed that.

Yeah, and I think if you think about it, Salesforce was one of the first platforms where it’s irrelevant if you're a billion-dollar company, or you're a three-person mom-and-pop shop. Either way, you get access to the same high-quality software. And SaaS and cloud became a great democratization of giving anyone access to the same resources. So have advancements in global internet speed.

I think a company like Torc, where we give these same opportunities to people regardless of their location or any other demographic metric, in combination with giving them the same power of being able to work online with the best cloud tools available – like AI tools – is pretty amazing. It’s proof you can have, basically, the same working experience that you may have with your best friend who lives down the street, that you go grab a bite with after work, as you can with someone that's on the other side of the world. Such as us right now, since we’re conducting this interview from different continents! That's a great thing. 

Q: And how do you feel remote working has changed over the last two decades?

A: I think, going back two decades ago, if you walked into a CTO’s office and pitched the idea of hiring a remote developer, they're thinking, “Wait…You're going to give my code to someone who’s halfway around the world and they’re going to work on their personal computer, and they need to get access to my network and to my computers?” 

They’d look at you like you were crazy.

Things have changed, and I think Uber was the first example where people realized, ok, these people have cars, access is easier. The overall quality and experience is better, and people just enjoy it a lot more than the old-fashioned way. That made it a lot more exciting, and a lot more simple when you go into an office to pitch, and you say, hey, we have an Uber version of this or an Uber version of that.

The industry is moving that way with offshoring. People have become more and more open to it. With the cloud, and SaaS, the ability to spin up developer environments becomes easier. And then the pandemic hit and everybody was forced to work from home, forced to work remotely. At that point, people realized, ok, if I'm already working remotely with ‘Debbie Developer’ and ‘John Java,’ why can’t I work with a person based in Argentina. It's the same time zone, and it’s still the same working experience, more or less. So I think the pandemic multiplied the ability to go more permanently remote tenfold.

Q: Can you share how community feedback has influenced Torc’s product development and innovation?

A: It drives the vast majority of what we're trying to do. Our profiles for example. We're trying to build the best profiles out there and get feedback from the community on what people think should go on the profile. Our goal is to make a developer’s Torc profile exportable, so they can even apply for a job that is not supplied by Torc if they want. We are a developer first type company.

We recently started giving developers access to Google certifications, because we were hearing how freelancers don’t have access to educational options. So, we deliver educational options right to our developer community. We just launched a store, which came after we received feedback that people wanted some more Torc swag. For Torc employees, they get free licenses to AI and productivity tools.

The other important piece that we're trying to work on is the interview process. When we first started, we talked to people and the feedback we got was, “OK, I'm interviewing for five or six jobs. Each of these jobs has five or six different interview processes. Each one wants me to do a take-home test.”

That’s a lot! When you think about that, if you put yourself in the developer’s shoes, they have to do four or five interviews, an hour and a half each, plus two two-hour take-home tests, but they’re also applying for five or six jobs. So that's taking almost two weeks of their time, they’re essentially working the hours of a full-time job just to do those applications.

That's something we try to focus on…doing assessments that can be used at multiple interviews. In fact, we have a client for whom we've now staffed, I think, nine people. When they came to us, they gave us an example of the standard interview process they were using, which they had used with other partners. It was a seven-step interview process. It included a two-and-a-half-hour take-home test, plus an hour-and-a-half programming test, plus an hour-long technical interview test, plus a half-hour culture interview.

And when you added it all up, those seven interviews were close to 11 hours worth of work, for both the client and the developer. And what we were able to do was say, “Look at our profiles. Look at our assessments. Look at how we have the GitHub stats.” With all this info, we can say that this developer is a fit. We were able to get them to shrink their process down to get it done in one interview. One culture interview for an hour and a half. That’s it.

So developers in the Torc Community skip a good 10 or so hours of interviews. And that client is having a success rate right now where they're hiring probably one out of every three people they're talking to, which is a better ratio than they had before. But even with that ratio, what now becomes maybe a five-hour commitment, was in the past for them a full work week, it was 35 plus hours.

A starting point for us was always to ask, “What makes the developer experience that much better?” And then, we push that to the clients. We say, “Hey, you want the best developers? Well, developers don't want to put up with this stuff, they want things streamlined. And here's how we're going to structure the platform to make their lives better.” 

That was also where I came in. You know the traditional resume matching where it's keywords and that stuff? You tend to miss great talent. We have some AI tools that are more unique in how we match people, but even still we're always keeping the human element in the loop with white glove treatment. The community model where we're meeting and learning the likes and needs of these community members so that we can still scale, but still give more of that white glove treatment to the developers, is proving successful – and a differentiator for Torc from other talent platforms. If the developers are happy, it makes clients happy. 

As for the roadmap and platform, anytime anyone wants to have their say, feel free to send a message to dave@torc.dev. I’m always willing to listen to our community for ideas on improvements. We're here to exist for the community. So the more feedback the better.

Q: Speaking of AI, how do you see AI and emerging technologies shaping the future of the industry and the Torc community?

A: I think there are very few points in your career where you’re at the start of really, truly revolutionary things. I am an AI optimist. I think it's just going to get better and better and better. And I don't think AI is going to replace anyone's jobs per se. But rather, people who know how to use AI will replace people in jobs that don't use AI. I’ve been in the industry for over two decades now, and I think every time a new technology comes out, even back when it was a horse and buggy, there are always some old guys sitting there saying, “This will never be better than what we had before.” Or, “This is all there is, and it will never change or improve.” And I think that's something we always need to be cognizant of. When there’s a big new tech, what we need to do is find the best ways to use it and apply it. 

ChatGPT for example, I've used it in situations where I've said, “OK, here's a data set. Visualize the trend line on this, or show me all this data on a map.” And it will generate Python code for me. I get an image. I can put that in a Python notebook. And that's almost instantaneous. I can get that stuff done and move on to the next thing rapidly. I've used various tools to know about running bedding on my code and to be able to go back and say, “Hey, where in the code does this feature occur?” And it's been able to say, “Look at this file, look at that file, look at those files.” It would previously take me hours or even days to comb through a code base I wasn't familiar with. Now I can do it right away.

Now, the tricky part with that is always being aware of what is allowed legally to share. So I think that's one thing that we're trying to be very clear about. How do we empower our developers to use the right tool at the right time with the right permissions? And that's something people do have to worry about. But then again, it's also super fun.

Q: How does Torc ensure that its technological advancements are in line with the needs and values of its community?

A: I think that's largely based on dialogue. The way we keep emerging technologies in line with our community is just by speaking with them every day. What we're trying to do is provide talent success, which is having the staff and employees talk to the talent as frequently as possible. We have our Slack and Discord where we interact with the community. We're going to start hosting more community webinars. 

I think the other piece of the puzzle is trying to stay in touch with not only our end clients who are hiring developers but also the technology companies. We're talking to Amazon, we're talking to Google, and we have contacts at AI companies as well. We ask them what they're looking for in developers. Where they think the industry is moving so that we can help drive our community to make sure that we’re moving in the same direction. 

We also ask ourselves questions. With the platform, “How do we make the best developer experience? What does that look like moving forward?” Some things we've looked at are verified credentials and universal background checks, so that if you get a background check at Torc, but get another job someplace else, you could take that background check with your data and re-use it. The fact that the Torc profile is portable, you can export it, and you can use it elsewhere, is valuable.

Q: What advice would you give to tech leaders looking to build a strong community or innovate in their product space?

 A: The key to building a good community is honesty. Being open and transparent, explaining what you're trying to do. If you have some sort of hidden agenda, people will figure it out. I think you see that now, even with some of the bigger open source companies, the idea of this bait and switch or switching of license models and things like that, you really can do yourself a lot of damage. If the community trusts in you, and you give that trust back to them, I think that's pretty helpful when it goes in both directions. You can give the developers more access, and more ability to do things in their own way with less oversight.

I also think rewards are important. Now, the reward doesn't necessarily have to be just monetary. It could be recognition, to be rewarded and recognized for what they're doing. And, you know, you can't, as a community or as a product or something like that, try to take all the glory onto yourself. How do you share in that? And that's how I think you get the community to share things because it's mutually beneficial. So I think that a big part of it is making sure when you look at things you’re mindful of that win-win situation, and ensuring that it's not only a win for you, but it's a win for the community. That's extremely important.

Q:  What has been your biggest hurdle so far? 

A: I think the hard part is just starting from zero. Getting the name there, building trust and building relationships. I think the other hard part is making sure that your eyes aren’t too big for your stomach, so to speak. We’ve got 10,000 things we want to do. And we're a pretty small and nimble team, so we need to keep focusing on execution, and ensuring that we're doing the right things to move the ball forward. And I think, the space of recruiting, hiring, and consultancy, is ripe for some change. It's been kind of the same way for a long time. If we do it right, we can be very impactful. So just making sure that we don't try to tackle too many things at once and keep making those innovations is always a challenge.

Q: Can you tell me about some of the future plans that you have for the company?

A: I think if you looked at Torc, when we launched two years ago, really what we tried to do is be the first developer-focused talent marketplace. Myself, Mike Morris, and some others on the team have been in talent marketplaces and done some other interesting models in the past.

I think in the long term for Torc, we want to build a platform where we focus on how developers get compensated. Not just for their hourly work, but for the value that they bring to an organization. If you worked on a project, and you developed a piece of code, the monetary value might be, say, $5,000. But instead of you working 50 hours and getting paid $100 an hour, if you did that in 20 hours or 25 hours, you would have got paid twice as much. The value and the price point stay the same because the client agrees that the value is worth that much, and the developer says they can deliver that value. So why do the hours that you work for it matter? I think that's a good way to bring more equity and more value to the community. 

The other piece of this I would love is for clients to say, “OK, I'm coming to Torc because I want an on-demand AI developer.” So the client can come and almost instantaneously, identify and hire a developer that knows what they're doing, super-powered by AI, and can start contributing to your business right away.

At the moment, we're doing a match and staffing people within less than a week on average. I would like to get to a spot where it's almost instantaneous. Maybe there are occasions where developers could have an online status and a client says to us, “I want a developer for something right now.” Then they could talk right away and the developer starts immediately. Part of that is that we tell the client that if they want to have this spot filled and talk to the developer, they need to make a decision ASAP, it can't be like you chat for an hour, you go back and schedule three more interviews. We want to remove the friction and get that connection as quickly as possible. And get rid of all that wasted time and effort.

‍

I’ve been working closely with David since my time at Torc began. I’ve found him to be a highly invested and willing collaborator, a terrific source of wisdom and inspiration, and a caring employer who values the work his people put in. As an interview subject, he’s an enthusiastic talker and has a deep passion for the tech field and the amazing developers driving our industry.

‍

This week's Codealike Achiever is Adam Ross DeStafeno, our Codealike Code Maestro (which is the award based on total Coding Hours) winner for January! Adam is a gifted coder from the United States who has been programming for just a year and a half! Winning this award is a sign of impressive progress for someone so new to coding. For his achievement, we spoke about his background and his experience with Torc and Codealike.

‍

Tell me about your background before Torc.

 Well, I've not been in the computer programming world for too long, it’s been about a year and a half since I started coding. My father works as a cybersecurity professional and had been telling me for years I’d enjoy coding, but at the time it didn’t seem like something I would be into. Finally he was able to get me to try my hand at making a hello world program and that’s how it all started. At first, I mainly just started dabbling with it and it turned out to be something that I really liked. Shortly after, I ended up enrolling in a Java master course from Karpado to learn the basics and have since been practicing and continuing to learn by developing utilities to solve my personal computing problems and further researching related interests, such as working with LLMs, checking out and learning about unique libraries, new frameworks, new languages, ect. I ended up enjoying coding so much that now, a year and a half later, I’ve decided I want to turn my hobby into my profession and am trying to find my way into the field. 

How does Torc’s platform and community differ from other remote work opportunities you've experienced?

To be honest, I haven't had much experience in using other remote work opportunities or services. In my head my goal was to refine my skills to a respectable and competitive level before I started entering the job market, and after finally feeling that I had met that goal, made the first step towards turning my hobby into a profession by creating my Torc account.

For someone who’s only been coding for a year and a half, it’s quite impressive that you’ve won this award, it’s a good sign of progress!

Thanks, I appreciate that! It’s amazing that Torc is here to acknowledge and try to promote those who are striving to improve their skills. It's been a journey of personal perseverance, maintaining focus, and embracing the reality that there's always more to learn. I’m enthusiastic for the future and the opportunities it may bring.

 What future initiatives or features are you most excited about within the Torc ecosystem? 

Definitely the refined job searches, the specialized feed of what would be relevant for the roles, and maybe deeper interaction between the talent and employer entities.

Can you discuss a time when Torc’s resources or community helped you overcome a professional challenge?

 Not yet. But, you know, I'm sure before too long, I'll be able to.

How has Codealike impacted your daily coding routine?

Codealike has significantly impacted my daily coding routine by providing me with valuable insights into how I spend my time while coding. By tracking my time spent on various activities such as coding, debugging, and web surfing, Codealike helps me to identify areas where I can improve my productivity.

Prior to using Codealike, I pretty much just coded whenever without much thought as to when or for how long; I wasn’t very mindful of how I was spending my time or the amount of coding I was doing per day/week/month. Once I started using Codealike it immediately brought to my attention the flaws in my coding routines and that I was not coding nearly as much as I thought I was in the grand scheme of things. Being able to visually model how I was spending my time allowed me to start creating a defined regime to start balancing the excessive time spent web browsing or being “sudo-productive” off with the lack of time spent coding.

For instance, one of the biggest examples is if I notice that I've been spending an excessive amount of time researching a related topic during a coding session, I'll make a conscious effort to minimize the time spent researching and focus more on coding. This has helped me see through my “sudo-productive” time to be more productive and efficient in my coding workflow and output.

‍Can you share a specific feature or a specific feature of Codealike that significantly improved your productivity?

The Codealike web extension has given me insights on how I spend my time on the web. I have been using Hyperskill to learn and practice coding quite frequently here recently. Without the web extension (or if I was using another time keeping service) the time spent on Hyperskill would blend in with the time spent on the web and would appear as wasteful time. Luckily, Codealike’s web extension recognizes the website and is able to separate the session in Hyperskill from the non productive web time, allowing me to more accurately assess my sessions.

How did tracking your coding activity with Codealike help you identify areas for improvements?

I needed to code a little bit more on the weekends. It is nice having that spread of information in front of you because it helps you to keep up with whether you're doing the amount that you should be doing, no matter how it's spread.

Why would you recommend code like to other developers?

The fact that it's integrated with Torc is like a win-win, two birds one stone situation. And again, the metrics are great. The interface itself just feels a lot more complete and robust than some of the other software that’s out there. I can’t say I’ve found myself needing a feature from Codealike that it doesn’t already offer.

How do you plan to leverage the insights gained from code like for future projects?

I plan on using it to ensure that I’m not spending too much time on one project or falling into a time-sink trying one file to make one thing perfect, just being mindful of how time is being spent and making sure the right amount of time is being spent on each task.

 How has Codealike influenced your approach to time management and focus while coding?

Again, it always helps to keep something in the back of your mind, that what you're doing needs to be on task, or oriented, and get some type of progress in some way. It keeps me mindful that the time I spend on my computer should be ordered and has developed an internal sense of keeping track of my coding subconsciously. I know sometimes I'll be getting into coding and come across a new framework or methodology that interests me and then get lost in researching it, it’s definitely helpful with minimizing that.  

Adam was a great interview subject and a good contrast to our previous two interviewees, Mariusz and Andres, as he has been working as a coder for a much shorter amount of time. It’s great to see Codealike having such a positive impact on the work of both experienced coders as well those newer to the industry. Adam has achieved a lot in a relatively short space of time and we look forward to seeing what he’ll achieve next!

‍

The MEAN stack and MERN stack are widely used by enterprises and startups alike. Both stacks employ MongoDB, Express, and Node.js, but differ in that MEAN utilizes Angular and MERN React.

With just this single difference, you’d expect them to have little to separate them. But the shift from Angular to React makes the stacks in terms of markup, event handling, and component lifecycles. Here we want to show you how they differ, and how they are the same, so you can understand the technology and the key differences between a mean stack developer vs mern stack developer.

Background of the MEAN and MERN stacks

The MEAN stack was coined in 2013 by Valeri Karpov, an engineer at MongoDB. It describes a modern JavaScript-oriented stack where you use Node.js on the backend, with Express as an HTTP server and MongoDB as a database, and use Angular as a frontend UI framework. It became synonymous with modern JavaScript-focused web development, and is still very popular for new projects that want a simple and powerful development stack.

However, React, a UI framework released in 2016 by Facebook, has recently taken the limelight away from Angular. This is usually attributed to React being easier to pick up and having a simpler syntax. Due to React’s growing popularity, a new stack gained prominence, MERN.

Now, let’s take a look at the features of Angular vs React, the primary difference, and then we will look at how they integrate with the rest of the stack.

Comparison of MEAN and MERN stacks

Markup Language

React and Angular both have markup languages that are based on HTML, but they are a bit different.

React

React uses JSX, which is a markup language designed to add the dynamic features of JavaScript to HTML. For example, JSX allows you to embed functions that return markup:

In the example above, if items = [{name: "Test", description: "testing 1 2"}], the JSX above would render as:

If you want to use other components in your JSX, you simply need to write an HTML tag with the name like you would with a normal HTML tag. However, make sure you have capitalized the component to help React distinguish it from an HTML element.

React JSX was originally created for React, but due to its popularity, UI frameworks like Vue and Solid adopted it. Learn more about hiring a react developer.

Angular

On the other hand, Angular offers its own HTML templating language. In general, Angular uses more specific element attributes to add functionality to the templates, rather than just allowing you to insert any functions. Additionally, Angular uses TypeScript exclusively and relies heavily on features like TypeScript decorators. For example, here is the markup above, but implemented in Angular.

Once again, this is functionally equivalent to the example in React above. Learn more about hiring an angular developer.

To use other components in your code, add the HTML tag equivalent of the component based on the selector property of the component. For example, an element with a selector of items-list (like above) would be used as <items-list></items-list>. You will also have to add the component to the imports property on the parent component and set standalone: true on the child component or manage the child component through a module.

Event handling

React

React event handling is quite simple. It is very similar to HTML attribute-based event handling (as opposed to addEventListener()), but you need to use camelCase instead of lowercase for event attribute names, and you pass a function surrounded by brackets rather than a string.

Angular

Once again, listening to an event in Angular is similar to HTML, except you must wrap the event name in parentheses instead of adding on as a prefix.

Component attributes & state

React

In React, component attributes are referred to as props. Both props and state are very simple to implement. For props, you simply pass it like an HTML attribute and the component will receive it as the first argument to the component function.

To implement state, you need to use the useState() hook, passing the initial value as the only argument.

Note: Hooks are functions you call in your React components that add behavior traditionally implemented by class methods, like state and lifecycle.

The useState hook returns two items in an array. The first is the value of the state, which is automatically updated when the component rerenders, and the second is the function you use to update the state, which triggers a component update. Make sure you do not change the state variable and instead call the set state function with the new variable. Otherwise, the component will not rerender to reflect the new changes.

‍

Angular

In Angular, component attributes are referred to as inputs or props. To declare a prop, you have to use the @Input decorator inside the component class. After the declaration, you pass the name of the attribute. Then, you set the attribute just like you would with a React or HTML component.

As for state, you have to add a property to the component class like this:

Component lifecycle

React

When using React hooks, useEffect() fills almost all of the functionality you need from lifecycle methods while being simpler. The useEffect() allows you to specify side effects that will run when the component mounts and updates. This is somewhat of a combined lifecycle hook, meaning you can implement it with one hook and know that it will always stay up to date, even as the props or state change.

If you want a cleanup function to run when a component unmounts, you can return a function in the effect. For example, if we were trying to implement a timer, this is how we would do it:

Notice the empty array at the end of the useEffect() call? That specifies that we only want the effect to run when the component mounts and unmounts. The array at the end specifies what state or prop updates would trigger the function for example, if you passed time, if time changed, the function to create the interval would run again. However, we left the array empty, which means that no prop or state updates will update the component.

Angular

Angular uses more standard lifecycle methods. There are quite a few, so we will just cover the most important: ngOnChanges(), ngOnInit(), and ngOnDestroy(). As their names imply, ngOnChanges() runs the function when an input changes, ngOnInit() runs the function when the component is created, and ngOnDestroy() runs the function when the component is destroyed.

To implement Angular lifecycle functions, you must insert them as methods in the class for the component you want the function to run on. For example, if you wanted to implement a timer similar to the one in the React example, you would write something like this:

Property binding

React

Property binding is not built into React. However, using event handling combined with state setting functions, you can create your own property binding system. For example, if you wanted to include state that automatically updated to match the value of a text input, you would write something like this:

If you want the property binding to be only one-way, simply remove value={value}.

Angular

Luckily, Angular offers built-in one way and two-way property binding. To use one-way property binding, simply add an attribute to the input element that starts with a hash:

Then, you can access the value using input.value, and it will automatically update like any other property.

For two-way property binding, you need to wrap the attribute in [()] and set it equal to the name of the property you want it to be bound to like this:

Now, when the input value updates, inputValue updates with it, and vice-versa.

Integration

MongoDB

You can build an application that does not have any database access on the client, therefore making React and Angular never have to interact with MongoDB. Instead, you create a REST API on the server that the client can access, which will interface with the database directly. This is often the better approach, as it is more secure and easier to port to new platforms.

However, if you are creating a prototype and want a quick way to develop, making the database access client-side might be the best option. If you are using MongoDB Atlas, you can use the Atlas Data API or MongoDB Realm. However, even then, you will only use MongoDB through your scripts. It never actually integrates into your Angular or JSX markup. Learn more about hiring a MongoDB developer.

ExpressJS

At the most basic level, you could simply generate static files for your markup and serve it using the static file server built into Express. However, there are limitations to this, like not being able to have the server send custom HTML based on the page data. Luckily, these limitations can be removed using Server Side Rendering (SSR). Server side rendering is how servers render HTML dynamically.

In order to use SSR in React, you must use ReactDOMServer.renderToString(), which will output a string of HTML for the React element specified. Then, you can use ReactDOM.hydrateRoot() to hydrate the React code on the client.

In Angular, you must use Angular Universal, which is Angular’s isomorphic rendering technology. The renderModule() function returns a string of the rendered HTML exactly like renderToString() for React.

You can integrate these into the Express server when you return HTML to the client. Learn more about hiring an ExpressJS developer.

NodeJS

The only thing you need to use in Node is the server side rendering. If you ever wanted to server side render code beyond the Express server, you can do it directly in Node. You use the same API for React and Angular, just integrate it with the rest of the code differently, changing how the input is found and the output is used. Learn more about hiring a NodeJS developer.

MEAN vs MERN which is better? 

Now we have gone over the major differences in how Angular and React work, as well as how they integrate with the other parts of the MEAN and MERN stack. As you might be able to tell, React is generally a little simpler, due to its more minimal API, but Angular could also be easier depending on the person.

If you want to learn more about each, the documentation for React and Angular are great places to start. I hope this helped you, and thanks for reading.

How to navigate the software job search?

Embarking on a job search in the programming world can be likened to a three-part journey:

1. The boring part:

• This involves scouring job boards, diligently sending out numerous CVs, and the anticipation of a response from a prospective employer. It's a repetitive process that requires patience and persistence.

2. The stressful part:

• The thrill of receiving a response! This stage encompasses an introductory discussion and, often, the nerve-wracking technical interview.

3. The happy part:

• Receiving the good news, you’re hired! All that time and effort and patience has been rewarded and you’ve secured the job. Congratulations!

‍

Well, there is of course another outcome, one that you want to avoid entirely. A fork in the road that occurs in part 3 of the process. I am of course referring to ‘The sad part’. The “unfortunately, we have decided to move on with the hiring process, and your application was not selected at this time” part. We’d all like to skip this part entirely, wouldn’t we? Well, this article is intended to help you bypass any sad parts in the process. 

That's where Torc comes in handy. With Torc, job applications are streamlined – a simple click is all it takes. If your profile aligns with what we're seeking, we'll forward an assessment. Our dedicated team works relentlessly behind the scenes to match you with the perfect opportunity.

If you’re reading this article, you’re likely in one of either two camps:

‍

1. First-time Interviewees:

• You're a newcomer to the tech industry, and you've secured an interview. Naturally, you aspire to excel on your first attempt.

2. Seeking Redemption:

• You’ve come to that fork in the road and have walked the sad pathway. You don’t want it to happen again. You want to nail the next one.

Either way, the same logic applies to both camps. The main piece of advice that we can give is this:

‍

PREPARATION

Be prepared! Programming interviews can be tough. They will test your knowledge to its fullest extent. Remember, from an employer's perspective, this is about finding the right fit, so you’ll be competing against other developers!

However, while knowledge is paramount, it's not the only key to success during the interview. Think of it like this: just as a well-written code requires an efficient compiler, your knowledge needs composure to shine. Knowledge equips you with answers, but composure allows you to articulate them confidently. Even if you're well-prepared, succumbing to nerves can hinder your performance. Remember, the brain, though powerful, performs best when focused. Don't divert its energy to anxiety or self-doubt. Stay calm, trust your preparation, and let your knowledge guide you.

‍

How do we prepare for a programming interview?

1. Understand the Format: Firstly, understand the format of the interview. Is it going to be a coding interview? System design? Behavioral? Perhaps, a mix? Knowing the format will help you tailor your preparation effectively.

2. Review Your Fundamentals: Refresh your knowledge in algorithms, data structures, and complexity analysis. Make sure you understand the basics like arrays, strings, linked lists, trees, graphs, stacks, queues, sorting algorithms, and search algorithms. Websites like LeetCode, HackerRank, and GeeksforGeeks provide plenty of practice problems.

3. Practice Coding: Write code on paper or a whiteboard to simulate the interview environment. This helps you get used to not having a code editor's help during the actual interview. Solve problems from different categories and with varying difficulty levels.

4. Mock Interviews: Practice with peers or use platforms like Pramp or Interviewing.io for mock interviews. This can help you get comfortable speaking out loud as you code and explaining your thought process.

4. System Design: If your interview includes system design questions, prepare by understanding how to approach designing large systems. Learn about common architectures, scalability, data modeling, and API design. Websites and resources like "System Design Primer" on GitHub can be useful.

6. Behavioral Questions: Prepare for behavioral questions by reflecting on past experiences. Be prepared to discuss challenges you've faced, how you've worked with a team, and what you've accomplished.

7. Technical Preparation: If the job involves specific languages or technologies, make sure you're familiar with them. Review their documentation and practice writing code using them.

8. Study the Company and Its Products: Understand the company’s products, services, culture, and the role you're interviewing for. This will help you tailor your answers and show your interest in the position.

9. Rest and Relax: Before the interview, make sure to rest and relax. A clear mind will help you think better during the interview.

10. Prepare Your Questions: Have a list of questions to ask the interviewer. This could be about the company culture, team, or specifics about the role you're applying for. It shows you're interested and have done your homework.

Remember, consistent practice and review are key to success in programming interviews. Also, after each practice session or mock interview, take time to reflect on what went well and what could be improved.

‍

Going back to point 9, composure is a necessary component of any interview process. You have to keep cool and focused.‍

How do we keep our composure?

1. Embrace the worst-case:

• Look, nobody wants to bomb an interview. You’ve taken out much of your valuable time on this earth to apply for the job, remain in contact with the recruitment team, prepare for the interview, and proceed with the interview itself. It’s a painful feeling to miss out on a job, especially one you really want. But at the end of the day, there’s plenty of opportunity out there. Where one door closes, another may open.
•  Don’t put so much pressure on yourself to land a specific job that you buckle under the pressure and lose out on it. Sometimes you will miss out because another candidate is more qualified, or someone in the company wanted to hire their nephew for the role, or some other outcome that’s ultimately out of your control occurs. Just do the best you can do and hope that it’ll be good enough. You’ll find a lot of the time that it is. Or at the very least, you’ll be able to maintain your pride and confidence in the knowledge that you tried your best.

2. Consider the best case scenario:

• What if everything is in your favor? What if facing the interview guarantees the job? You're a competent programmer. You're well-versed, well-prepared, and have all the tools needed to succeed. So, why the doubt? Envision your success and let that motivate you to perform to your fullest potential.

‍

Navigating the world of programming interviews can be a rollercoaster of emotions. From the anticipation of showcasing your skills to the nerves of being put to the test, it's a journey that requires both technical prowess and mental fortitude. But with the right preparation and mindset, you can position yourself as a standout candidate. Remember, every interview, whether it leads to a job offer or not, is a learning experience. Each one hones your skills, bolsters your confidence, and brings you one step closer to your dream role. Keep pushing, keep learning, and most importantly, believe in yourself. After all, success in interviews, much like coding, often boils down to persistence and a positive attitude. Best of luck out there! 👩‍💻👨‍💻🌟

This week's Codealike Achiever is Andrés Felipe Suárez Villegas, our Codealike Concentration Connoisseur Prize (which is the award based on Focused Hours) winner for January! Andrés is a skilled coder from Colombia who has been programming for seven years. We spoke about his background and his experience with Torc and Codealike.

Q: I'd like to talk to you about your background pre-Torc. Can you tell me a bit about that?

A: I have been developing software for around seven years. Mostly web apps with Node.js, but in general full stack with both JavaScript and Node.js, as well as Cloud Development, where I mostly work with AWS.

Actually, I started using Codealike around four or five years ago. It was awesome. It also helped me with my bosses at the time, because I shared with them that I was ‘on fire’ when I had an extra productive week. They were very impressed and happy with my productivity levels.

I was using Codealike a lot with all my projects. Previously I was using Codealike with VS Code, right now I'm using it with WebStorm and it's going good. But I remember during COVID they stopped supporting Codealike, and then around a year or two later Codealike reappeared with Torc. So, that's good because actually there were not so many other programs similar to Codealike out there that I could replace it with. Most of them don’t have all those useful metrics and the ranking systems that I like to utilize. The ideas behind Codealike are good, and I like using it a lot.

Ok great, and can I ask, where are you based?

I am from Cali, Colombia, and I am based here now. 

And did you study at the Colombian University to learn coding?

I studied, but I didn't finish. I studied in the Universidad del Valle. That was a very good experience.

Q: How does the Torc platform and community differ from other remote work opportunities you've experienced?

A: With Torc, I haven't entered like into the community very deep yet. I just put my info in and mostly focused on the work. I just feel that I will become more of a part of the community later, because actually I would like, if possible, to make the jump to something else within the company, to find other opportunities and projects with Torc in the future. So I haven't spent that much time on Torc’s community yet, but I would like to continue to get deeper into the Torc ecosystem over time.

Q: How has Codealike impacted your daily coding routine?

A: It has impacted it a lot, because, in the beginning, it makes me push hard, to try to move up in the rankings. So that pushes me to have another day of focused and intense working.

 And I like to work hard and spend more time on my work because in the rankings, you see some of the other Torc developers working really long days, sometimes 18 hours or more. It's crazy and impressive to see some of the hours that people are able to put in. You feel like you're in a new world, knowing how the pros work, that's a good feeling, to be able to compete with them.

Q: Can you share a specific feature of Codealike that has significantly improved your productivity?

A: The on fire for sure, as I mentioned before, makes you push harder. To reach the on fire is good feature and makes you feel good about your day’s work.

Q: How did tracking your coding activity with Codealike help you identify areas for improvements?

A: Well, you also have bad days. Some days are affected by your mood, like how you wake up in the morning for example. Sometimes for coding, you have to put aside all those feelings just to be productive.

Maybe on a certain day things were bad because of something with your family or an argument or something like that. So your work can be affected because of things like that, but you can still look at the data and see that you’re actually having a good working day. Or when you are having a bad day, Codealike helps you to push through the bad day, And sometimes that can just at least help to make the next day better.

‍Q: Why would you recommend Codealike to other developers?

A: I highly recommend it for everyone to use it. Because like I said before, if you embrace it, you are likely to work harder. To see your progress, how you are compared with other devs, that make you like feel competitive.

It makes you feel not alone, which sometimes can be a feeling a remote worker will have. It gives you better perspective on if you are good or bad or something more specific too.

Q: How do you plan to leverage the insights gained from Codealike for future projects?

A: Well, actually, I just try to do the best every day, to accomplish what I can, to keep high in the rankings too. Every hour I work, I try to be the most professional I can be. Sometimes it’s impossible, being so focused for so long. Sometimes, you know, the quantity doesn’t match the quality. But I know that with Codealike I can leverage these insights for the future.

Q: How has Codealike influenced your approach to time management and focus while coding? 

A: You can see the perspective with the timeline, and with the charts. You can see what days you work better and with more focus. You can know that some days you had an hour that was so good that it was better than three hours of another day. Codealike is great for finding these types of insights.  

‍

Andrés is a long-time Codealike user with a ton of experience with the tool. It is positive to hear stories from developers whose productivity has been largely improved by using Codealike, and has seen improvements in their work because of it. We had a good discussion and I enjoyed learning about him and his experiences with Torc.

‍