Karat’s purpose is to Unlock Opportunity for engineers and companies alike, and our mission is to make every interview predictive, fair, and enjoyable

Karat

Multiplying numbers is one of the few things we learn while starting on the unique learning journey. The grid method used to perform the multiplication of two numbers is something we grow up doing at least a thousand times. Yet, we all agree that this method is often time-consuming, especially when numbers involved in the process have a large number of digits.  This inefficiency of grid multiplication amplifies when computers try to perform this multiplication. The inefficiency limits the computers to perform large multiplication. Karatsuba Integer Multiplication is a fast multiplication method proposed by Anatoly Karatsuba in 1960. The method/algorithm proposed is a typical example of the divide-and-conquer algorithm. The procedure is preferred over grid multiplication, especially when numbers involved have many digits in them. Task Definition Given two large numbers, and , we have to find their product such that c is . a b c (a*b) Numbers can have a large number of digits. Consider numbers to be represented as an array where the least significant digit is at the lowest index of the array. Each index of the array can hold an integer from 0 to 9 only. With the task now defined clearly, we can formally start working on the problem and slowly form the solution proposed by Karatsuba. Addition and Multiplication we Learnt at School The addition of two numbers having digits each (consider 0 paddings if one of the numbers has fewer digits) can be easily performed using the school addition method. Here we go from least significant digit to most significant digit, taking the carry each time we add numbers at the same significance level. It should not be difficult to digest if the addition method takes O(n) complexity. n Multiplication of two numbers, each having n digits (again consider 0 paddings if one of the numbers has fewer digits), is performed by the grid method. The first step is to create the grid, which is going over each digit of the first number and performing multiplication with all digits of the other number. Thus making the grid takes times itself. Once the grid is completed, we have to perform the last addition of adding all the rows. Since we have n rows and at max cols, the time to solve the problem would be . Thus the multiplication method taught in school is of order 2, which is not the fastest way. O(n*n) 2n+1 O(n*n) First Attempt at the Problem Consider a simple algorithm aimed at solving the multiplication problem slightly differently. Split the numbers into two halves. Let us call the part containing the less significant digits as left half and the other being the right half. If the number of digits is not even, we can add 0 to the right. In this way, dividing the number into two halves becomes easier, and both halves have the same length. Here is the illustration describing how the split is performed. Once we perform this splitting, we get four numbers each of half the original length. Our goal is to represent the product of the original two numbers in the form of these four numbers. This is how we can express it - So now we have reduced the problem of multiplication of two numbers, each containing N digits, to the problem of multiplying four numbers of size each. Note that addition is not the bottleneck since it is a linear time algorithm. Also, note that multiplication by a power of 10 means appending 0s at the end of the array, which is again linear. Thus the main work is done in finding out the four products which are present in the equation. N/2 Unfortunately, this does not improve over the naive way of performing the multiplication using the grid method. Using Master's theorem, we can find this solution's time complexity, which is the same as . O(n*n) Arriving at Karatsuba Algorithm Our previous attempt to reduce the time complexity of the multiplication seems to went in vain. But we could have gained some performance if there were fewer multiplications required. So is there any other way that requires fewer multiplications? It turns out we need not go far looking for another way. Our failed solution holds the potential. A detailed analysis would reveal that, in reality, we only need three multiplications to find the product of two numbers. Are we not convinced? Here is how we can do it - Thus the problem is now solvable using three multiplications of size N/2. Additions are never a bottleneck, and thus the blocking operation is the calculating those three products. Using the Master's theorem, the time complexity of this new algorithm is . And this way of performing multiplication is known as Karatsuba multiplication. O(n^1.58) Final Words This completes the explanation of the Karatsuba algorithm. Do like if this blog helped you. 😊

Divide and Conquer: Karatsuba Integer Multiplication

- that's the story that got nominated for . 's second Noonie Nomination is for a 3-year old OSS project, "karate". In this interview, talks about what it's like to have hard work pay off, and feel like you're at the top of your coding game. "The world needs an alternative to Selenium - so we built one" Peter Thomas from India a 2020 Noonie in the Development award category Peter Peter 🚀 This Year's Noonies were made possible by: Sustany Capital , .TECH Domains , Grant for the Web , Skillsoft , Flipside Crypto , Udacity , and Beyondskills ! VOTE until 12 Oct 2020 at NOONIES.TECH ! 🚀 1.  Which 2020 Noonie have you been nominated for? Hacker Noon Contributor of the Year - OPEN SOURCE , and Best Open Source Project 2. Tell us a bit about yourself. I work at Intuit and have been contributing to open-source since way back in 2004 when there was only SourceForge. And yes, I have been writing code for a very long time ! A fun-fact is that the very first open-source project I created is still being maintained by a developer who I have never met in person, and he is still making regular releases. My language of choice happens to be Java, but I have used Scala, Node, Typescript, and multiple front-end technologies as well, and I dare say I was a "full-stack" engineer way before it was "cool". Anyway, what I am experiencing right now with my 3-year old OSS project "Karate" is truly amazing. All those years of building stuff, honing the craft and generally being curious about programming seems to be paying off now, and I feel like I'm at the peak of my coding game. Karate is being used by hundreds of companies all over the world and I've been able to connect with all manner of awesome people. And my Stack Overflow reputation has just crossed 30000, all of it due to thankful developers whose questions I answered, which shows how far Karate has come as a developer-tool. 3. Tell us about the things you make / write / manage / build. My day job is platform engineering and tech-leadership at Intuit. I'm lucky that my enthusiasm for open-source intersects nicely with my day job, and Karate seems to have come at a very opportune time in this era of micro-services and distributed-systems. We use it a lot at Intuit of course. I care deeply about Developer Experience and I think it is an aspect that is neglected too often. One thing I'm really proud off is the main README file for Karate, it is so long and comprehensive that it consistently gets rave reviews - and stands out in the landscape of open-source solutions out there. I also think that quality-assurance is not given the emphasis it deserves and Karate is my way of trying to make a difference - it is a tool designed to be "programmer friendly" as far as possible while keeping things simple for even non-programmers. This is a very hard balancing act to pull off, and I like to think that Karate has gotten a few things right in this department. 4. What are you most excited about right now? The future of Karate. When it started, I never dreamt that it would get such a rousing reception and that it would evolve to even do browser-automation testing. One of my articles on Hacker Noon has been read 15000 times, and I think we're just getting started. 5. What are you worried about right now? It would be nice to see more contributors step up and contribute code so that Karate can evolve faster. It is certainly getting better as we speak, as more organizations use and become aware of this new-ish framework. 6. What's the most useful advice you've ever given somebody? "Just Open Source it" ! With the success of Karate, nowadays I'm being asked more and more about what it takes and what is the "secret". Unfortunately there is no short-cut and it does take a lot of energy and conviction. But a lot of people seem to be needing a push, they worry about whether their idea or code is good enough. My advice is to not worry about all that and just do it, what's the worst that can happen? The magic in open-source happens when you have the whole world looking at your code, and it doesn't have to be the most clever code. All that will naturally happen over time, and people don't expect it to be so anyway on day one. 7. How has the pandemic changed your life and/or career? It hasn't changed much. To be honest I fall into the "introvert" category and I certainly don't miss the commute ! There's a lot of things you can achieve with just an internet connection, and I have been doing this kind of thing for a while. 8. If we gave you $10 million to invest in one thing right now, where would you put it? Improving the state of the art of Virtual Reality. 9. What's an opinion you have that most people don't agree with? This has come out of some of my recent debates on Twitter, but there are too many test-automation evangelists out there preaching that one has to create a framework "from scratch" for each new project. My answer is that I've been trying to create a framework, it has been 3 years, and I'm still not done. 10. Which apps can't you live without? Email. 11. What are you currently learning? 3D modelling in Blender 3D. VOTE for Peter Thomas in Hacker Noon Contributor of the Year - OPEN SOURCE , and Best Open Source Project - before voting closes on 12 October, 2020! 🚀 With gratitude to Hacker Noon's 2020 Noonies Partners: Sustany Capital , .TECH Domains , Grant for the Web , Skillsoft , Flipside Crypto , Udacity , and Beyondskills !

Best Open Source Project and Writer Nominee Peter Thomas on Karate

Karate Club is an unsupervised machine learning extension library for the NetworkX Python package. See the documentation here. consists of state-of-the-art methods to do unsupervised learning on graph structured data. To put it simply it is a Swiss Army knife for small-scale graph mining research. First, it provides network embedding techniques at the node and graph level. Second, it includes a variety of overlapping and non-overlapping community detection methods. Implemented methods cover a wide range of network science , data mining , artificial intelligence and machine learning conferences, workshops, and pieces from prominent journals. Karate Club (NetSci, Complenet) (ICDM, CIKM, KDD) (AAAI, IJCAI) (NeurIPS, ICML, ICLR) A simple example makes the use of modern community detection techniques quite easy (see for the accompanying tutorial). The snippet below uses an on a synthetic graph. Karate Club here overlapping community detection algorithm networkx nx karateclub EgoNetSplitter

g = nx.newman_watts_strogatz_graph( , , )

splitter = EgoNetSplitter( )

splitter.fit(g)

print(splitter.get_memberships()) import as from import 1000 20 0.05 1.0 Design principles When we created Karate Club we used an API oriented machine learning system design point of view in order to make an end-user friendly machine learning tool. This API oriented design principle entails a few simple ideas. In this section we discuss these ideas and their apparent advantages with appropriate illustrative examples in great detail. Encapsulated model hyperparameters and inspection An unsupervised Karate Club model instance is created by using the constructor of the appropriate Python object. This constructor has a default hyperparameter setting which allows for sensible out-of-the-box model usage. In simple terms this means that the end user does not need to understand the inner model mechanics in great detail to use the methods implemented in our framework. We set these default hyperparameters to provide a reasonable learning and runtime performance. If needed, these model hyperparameters can be modified at the model creation time with the appropriate parametrization of the constructor. The hyperparameters are stored as public attributes to allow the inspection of model settings. networkx nx karateclub DeepWalk
   
graph = nx.gnm_random_graph( , )

model = DeepWalk()
print(model.dimensions)

model = DeepWalk(dimensions= )
print(model.dimensions) import as from import 100 1000 64 We demonstrate the encapsulation of hyperparameters by the code snippet above. First, we want to create an embedding for a generated with the standard hyperparameter settings. NetworkX Erdos-Renyi graph When the model is constructed  we do not change these default hyperparameters and we can print the standard setting of the dimensions hyperparameter. Second, we decided to set a different number of dimensions, so we created a new model and we can still access the dimensions hyperparameter publicly. Consistency and non-proliferation of classes Each unsupervised machine learning model in Karate Club is implemented as a separate class which inherits from the . Algorithms implemented in our framework have a limited number of public methods as we do not assume that the end user is particularly interested in the algorithmic details related to a specific technique. Estimator class All models are fitted by the use of the method which takes the inputs (graph, node features) and calls the appropriate private methods to learn an embedding or clustering. Node and graph embeddings are returned by the public method and cluster memberships are retrieved by calling fit() get_embedding() get_memberships() . networkx nx karateclub DeepWalk
   
graph = nx.gnm_random_graph( , )

model = DeepWalk()
model.fit(graph)
embedding = model.get_embedding() import as from import 100 1000 In the snippet above we create a random graph, and model with the default hyperparameters, we fit this model using the public method and return the embedding by calling the public method. DeepWalk fit() get_embedding() This example can be modified to create a embedding with minimal effort by changing the model import and the constructor - these modifications result in the snippet below. Walklets networkx nx karateclub Walklets
    
graph = nx.gnm_random_graph( , )

model = Walklets()
model.fit(graph)
embedding = model.get_embedding() import as from import 100 1000 Looking at these two snippets the advantage of the is evident as we only needed to do a few modifications. First, one had to change the import of the embedding model. Second, we needed to change the model construction and the default hyperparameters were already set. API driven design Third, the public methods provided by the and classes behave the same way. An embedding is learned with and it is returned by This allows for quick and minimal changes to the code when an upstream unsupervised model used for feature extraction performs poorly. DeepWalk Walklets fit() get_embedding(). We designed Karate Club to use standardized dataset ingestion when a model is fitted. Practically this means that algorithms which have the same purpose use the same data types for model training. In detail: Standardized dataset ingestion Neighbourhood based and structural node embedding techniques use a single as input for the fit method. NetworkX graph Attributed node embedding procedures take a as input and the features are represented as a or as a . In these matrices rows correspond to nodes and columns to features. NetworkX graph NumPy array SciPy sparse matrix Graph level embedding methods and statistical graph fingerprints take a as an input. list of NetworkX graphs Community detection methods use a as an input. NetworkX graph High performance model mechanics The underlying mechanics of the graph mining algorithms were implemented using widely available Python libraries which are not operation system dependent and do not require the presence of other external libraries like or does. The internal graph representations in Karate Club use . TensorFlow PyTorch NetworkX Dense linear algebra operations are done with and their sparse counterparts use . Implicit matrix factorization techniques utilize the package and methods which rely on graph signal processing use NumPy SciPy GenSim PyGSP. Standardized output generation and interfacing The standardized output generation of ensures that unsupervised learning algorithms which serve the same purpose always return the same type of output with a consistent data point ordering. Karate Club There is a very important consequence of this design principle. When a certain type of algorithm is replaced with the same type of algorithm, the downstream code which uses the output of the upstream unsupervised model does not have to be changed. Specifically the outputs generated with our framework use the following data structures: (neighbourhood preserving, attributed and structural) always return a when the method is called. The number of rows in the array is the number of vertices and the row index always corresponds to the vertex index. Furthermore, the number of columns is the number of embedding dimensions. Node embedding algorithms NumPy float array get_embedding() (spectral fingerprints, implicit matrix factorization techniques) return a when the method is called. The row index corresponds to the position of a single graph in the list of graphs inputted. In the same way, columns represent the embedding dimensions. Whole graph embedding methods Numpy float array get_embedding() return a when the method is called. Node indices are keys and the values corresponding to the keys are the community memberships of vertices. Certain graph clustering techniques create a node embedding in order to find vertex clusters. These return a when the method is called. This array is structured like the ones returned by node embedding algorithms. Community detection procedures dictionary get_memberships() NumPy float array get_embedding() We demonstrate the standardized output generation and interfacing by the code fragment below. We create clusterings of a random graph and return dictionaries containing the cluster memberships. Using the external community library we can calculate the modularity of these clusterings. This shows that the standardized output generation makes interfacing with external graph mining and machine learning libraries easy. community networkx nx karateclub LabelPropagation, SCD

graph = nx.gnm_random_graph( , )

model = SCD()
model.fit(graph)
scd_memberships = model.get_memberships()

model = LabelPropagation()
model.fit(graph)
lp_memberships = model.get_memberships()

print(community.modularity(scd_memberships, graph))
print(community.modularity(lp_memberships, graph)) import import as from import 100 1000 Limitations The current design of Karate Club has certain limitations and we make assumptions about the input. We assume that that the graph is undirected and consists of a single . All algorithms assume that nodes are and the starting node index is 0. Moreover, we assume that the graph is not multipartite, nodes are homogeneous and the edges are unweighted (each edge has a unit weight). NetworkX strongly connected component indexed with integers consecutively In case of the whole graph embedding algorithms all graphs in the set of graphs must amend the previously listed requirements with respect to the input. The feature based embedding techniques allow nodes to have a single string feature which can be accessed with the key. Without the presence of this key these algorithms default to the use of degree centrality as a node feature. Weisfeiler-Lehman feature

Karate Club a Python library for graph representation learning

recently crossed on GitHub and has been very , even beginning to feature in as a desired skill. Not bad, given this project is just ten months old ! Karate 500 stars well-received job-postings Test Doubles One of the features in the works (and close to being released) is the ability to spin-up test-doubles to “mock” a web-service API dependency that may still be in development — or for which a test-environment may be un-available or unstable. This is a for many teams — and “ ” are legendary sources of pain for many a platform team dealing with micro-services. pain-point significant flaky integration tests Karate’s innovative has worked out extremely well in practice, and actually happens to be a great fit even when “ ” things to work on the server-side. Here’s an example that showcases how simple it is to write a test-double for a service. Things just click into place, like Karate’s native support for JSON and XML, and the power of the shines through. “mis-use” of Gherkin inverting stateful REST embedded JavaScript engine the actual source for this example: demo-mock.feature You can find a comprehensive list of capabilities in the . While the README evolves, a demo end-to-end example using has been created as an early preview for the community, and is summarized below. project-documentation Spring Boot Consumer-Provider Example We use a simplified example of a Java ‘consumer’ which makes HTTP calls to a Payment Service (provider) where , , and have been implemented. The 'provider' implements CRUD for the 'POJO', and the (or create) results in a message ( as JSON) being placed on a queue, which the consumer is listening to. GET POST PUT DELETE [Payment.java](https://github.com/intuit/karate/blob/develop/karate-demo/src/test/java/mock/contract/Payment.java) POST [Shipment.java](https://github.com/intuit/karate/blob/develop/karate-demo/src/test/java/mock/contract/Shipment.java) is being used for the sake of mixing an asynchronous flow into this example, and with the help of some , we are able to mix asynchronous messaging into a Karate test the test-double. ActiveMQ simple utilities as well as Server-Side Karate Karate on the ‘other side of the fence’ ( HTTP requests instead of them) — turns out to be remarkably effective, yet simple. handling making ‘Native’ support for expressing JSON and XML Manipulate or even transform payloads Validate payloads, using a if needed simpler alternative to JSON schema Karate is about making HTTP calls, giving you the flexibility to call ‘downstream’ services if needed all In-memory JSON and JsonPath solves for ‘state’ and filtering if needed Mix custom JavaScript (or even Java code) if needed — for complex logic Easily ‘seed’ data or switch environment / config on start If you think about it, all the above are to implement micro-service. Karate’s DSL syntax is on exactly these aspects, thus opening up interesting possibilities. sufficient any focused It may be hard to believe that you can spin-up a ‘usable’ micro-service in minutes with — but do try it and let me know what you think ! Karate

API Consumer-Contract Tests and Test-Doubles with Karate

It’s hardly been two months since was open-sourced, and especially thanks to blog posts by and — the response has been fantastic. Thanks Joe and T. J. for giving this brand-new open-source project — a much-needed boost in visibility ! Karate Joe Colantonio T. J. Maher On to the topic at hand. I’d like to explain how Karate relates to and BDD. I expect this to be a frequently asked question as Karate gets more widely adopted — and this blog post is intended to be the definitive reference that I can point folks to from now on. Cucumber very Why Cucumber EDIT / Jan-2019: As of version 0.9.0, Karate is based on Cucumber ( ) — but retains the syntax. And if you are contemplating using BDD for API testing — you should really read . no longer see why what I posted on Stack Overflow The decision to build Karate on top of and use the standard — is turning out to be a great one. And here’s why: Cucumber-JVM Gherkin Free IDE plug-ins exist for both and . Scripts look much more compelling with syntax-coloring, and best of all — you can ‘right-click’ and run a test without needing to write a single line of Java code. I really think that this is a deal, and makes web-API-testing more accessible to non-programmers. Even GitHub has built-in support for syntax-coloring, — and I wouldn’t trade this away in a hurry. Eclipse IntelliJ huge just look at the documentation Behind the scenes, Cucumber-JVM provides ready-to-use integration with unit-test frameworks (such as JUnit and TestNG), has nice reports out of the box, and again — Karate gets all this for free. Standing on the shoulders of giants seems almost sometimes. But that’s the beauty of open-source. unfair Cucumber-JVM simplifies the whole process of parsing a script-file and handing control to custom Java code — and Karate can just focus on getting-right the ‘glue’ code that does the serious business of HTTP calls and JSON / XML data-assertions. And Karate gets the “BDD flavored” - - syntax for free. More on this in a moment, but there should be absolutely no question that this makes tests . Just look at the Karate and try to imagine it without the BDD syntax. It simply, just ain’t the same. Given When Then so much more readable ‘hello-world’ example So is Karate BDD ? Karate certainly gives you the of using the BDD keywords such as , , and . And people familar with Cucumber already know that it doesn’t matter whether you use or or , it is just “ ” and behind the scenes it is completely ignored. option Given When Then And Given When Then syntax sugar But back to the question. I’d rather not lecture you on how BDD should actually be applied in practice because that is something best articulated by the creators and some opinionated users of Cucumber. Consider the following blog-posts a “ if you are contemplating using Cucumber — or even BDD for that matter. Even if you that you are doing BDD the Right Way™, I urge you to read these articles. You may be surprised. must-read” think — by Aslak Hellesøy The Worlds Most Misunderstood Collaboration Tool — by Jonas Nicklas You’re Cuking it Wrong — by Jack Kinsella (which is a critical response to #2) Why Bother With Cucumber Testing? I’ll like to reproduce a quote from link #3 here below: Cucumber has its uses, principally as a high level analysis tool on large, polyglot projects. That said, few programmers work in this kind of position, and acceptance tests beyond a list of the method names of regular integration tests seems wasteful. Cucumber, as used by the majority of Rails programmers, is no more than a clumsy wrapper over basic integration tests. . I’m sure this will resonate with a lot of folks who have used some flavor of BDD at some point, to write tests for an system. And all the while wondering — ? Bingo existing wouldn’t a plain-old integration-test have sufficed If Karate is a “mis-use” of Cucumber, so be it ! Karate unashamedly embraces the fact that it is for integration-testing of HTTP web-services. And it includes a to simplify the business of doing just that. It competes with the likes of in the web-service API testing-tool space — for example, take a look at this . whole lot of capabilities directly REST-assured detailed head-to-head comparison of Karate vs REST-assured Karate makes sense especially for “platform” teams creating and maintaining web-services, and where product-owner involvement in acceptance-testing is not the highest priority. FAQ Once in a while, I run into a “BDD enthusiast” who takes one look at Karate and exclaims that it is an abomination upon this world. I’ll end this blog-post with a “Frequently Asked Questions” section that attempts to reason with some of these people, but I fear that in many cases this is a lost cause — because of deep-set, cognitive-dissonance. But anyhow, here goes. Aren’t you just using Cucumber for the BDD hype ? No. There are very good reasons, see the “Why Cucumber” section above. This defeats the whole purpose of BDD and Gherkin ! There’s so much implementation detail in the scripts. BDD should be readable, executable specifications ! If there’s one thing that Karate does well — it is that it’s a “t ” for HTTP, JSON and XML. The whole point of a DSL is to simplify what would have taken multiple lines of code in a normal programming language — . rue DSL into one-liners But yes, if you are concerned that Karate looks like a programming-language, it certainly is, and by design. It is worth repeating that Karate is for teams wishing to practice BDD. not true Who are the target users for Karate ? It clearly isn’t for non-technical business people. It looks like an abstraction, so will this be suitable for technical folks ? Yes, Karate is for technical folks who need to test web-services and it is on making this as as possible. The motivation for creating Karate in the first place was to avoid using Java code for web-services, as there is a impedance-mismatch. This deserves a whole other blog-post which I hope to do in the future. laser-focused simple significant Karate also — which arguably don’t belong in a BDD context, but are much-needed from an integration-testing perspective. adds some features missing in Cucumber There is an argument to be made that some languages (e.g. and Ruby) can reduce the impedance-mismatch to some extent, but that is debatable — especially since Karate has JSON and XML into the syntax. Anyway, we are already seeing developers as well as quality-engineers create API test-automation at velocities much higher than before. One of the great things about Karate is that it is language-neutral, without sacrificing power or expressiveness for what it is to do. Python baked “natively” designed I’m still not convinced. You are also polluting the world of BDD with Karate and you will lead people new to BDD down the wrong path. Well, think of this blog post as my way of trying to guide users down the right path. I’ll also be prominently linking to this blog — from the Karate documentation. That said, look at the cited blog posts and the fact that over the years, legions of programmers have fallen into the trap of mis-using Cucumber for integration testing. This is likely to continue for a while, even if Karate did not exist. And in closing, I’m by no means un-biased, but I urge you to give Karate a try, or ask your team to evaluate it. I am confident that you will find some good things to say about it over time. don’t knock it till you try it !

Yes, Karate is not *true* BDD

Karat CTO Neil Kumar shares techniques for hitting hiring targets without sacrificing product deadlines In 2018, total venture capital (VC) funds invested totaled , surpassing invested during all of 2017. Compared to 2017, the median VC deal size experienced double-digit percentage growth across all investment stages — the highest jump since 2015. $131 billion $84 billion The primary investment targets of these funds are software-driven companies whose products and solutions are expected to change the way we do everything, from how we commute to the way we’re treated for cancer. These funds are often invested in companies that show huge potential in the short term, pushing them into hyper-growth mode. If these hyper-growth phase companies funnel their capital into the right teams and develop the right products, they will propel significant revenue growth in the very near future. For many companies, this means hiring software engineers to do that product development. But two challenges quickly rear their heads: 1. Software engineering talent isn’t as plentiful as capital. 2. There isn’t enough current engineering capacity internally to conduct the interviews needed to hire new engineers and hit product goals. At Karat, we see that the average company in a high growth or hyper-growth phase will increase the size of its software engineering team by 117% in 2019. Many have teams that are 100% dedicated to software development to begin with, with no available time for interviewing. As a result, engineering leaders are fielding questions about the ability (or inability) to hire as well as reach product deadlines. Who among us hasn’t heard these questions like these, only moments apart: “Your team needs to hire 20 new engineers this quarter, but you’ve only extended 5 offers so far. What’s going on?” Followed by: “Why is the deadline for X feature being pushed? Customers are begging for this.” The answer may be tough to swallow. The fact is that you can rarely achieve both when you only have a portion of the existing team size you need to achieve product and corresponding revenue goals. Due to this Catch-22, companies often miss hiring goals by as much as 40%. This leads to a significant amount of anxiety among tech hiring managers and recruiters. feel that the tech talent shortage has hurt their business through lost revenue, slower product development, market expansion and/or increased employee tension and burnout. 83% I’ve been responsible for growing software engineering teams in a variety of circumstances as talent and capital markets have fluctuated. I helped grow the software engineering team at Yelp from 12 to over 200 software engineers. I conducted thousands (maybe tens of thousands) of first-round interviews and onsites in the process. It wasn’t easy then and it’s not easy today. Yet, there are techniques you can use to get through it and optimize the hiring process while climbing a steep growth curve. Here are a few approaches I’ve taken in the past and continue to find helpful today. 1. Streamline the hiring funnel and reduce the number of onsites per hire. When I was the VP of Engineering at Yelp, I created a recruiting team within my software engineering team. This was necessary because the skills we were looking for were incredibly specialized. We found that building strong relationships between these two teams helped them make informed decisions on the cultural add and technical skills candidates would bring to the table. Recruiters and hiring managers should be able to speak about these topics early in the interview process. If they wait until the onsite interview to figure this out, they’re wasting time. However, if you’re trying to increase the size of your team by 50% or even 150%, you’ll probably need to look at other options to gain efficiencies throughout the hiring funnel. These options may include decreasing the number of onsite interviews you need through more and more rigorous first-round technical interview. 2. Pair a structured and consistent interview with a flexible candidate experience. Investing in candidate experience will leave a big (and positive) impression on candidates. Consider that say a negative interview experience can change their mind about a role or company they once liked, while 87% say a positive interview experience can change their mind about a role or company they once doubted. 83% of talent Dedication to establishing interview success criteria early in the recruiting process and quickly responding to candidates give you a speed advantage that other companies might not have. Also, recruiters who build relationships with candidates can more easily keep track of those who took offers at other companies, helping you better understand your hiring bar. Technical interviews should be structured and consistent across your organization so that candidates can be evaluated on their merit and skills. Structure and consistency make repeatability possible. If multiple engineers are aware of this process and the criteria for success, then they should be able to assess each skill with equal reliability in the onsite loop. As a result, interviews won’t get delayed by scheduling. Interviewing 24/7, giving candidates the option to redo the interview and the ability to schedule their interview directly with the interviewer will make your company stand out — no matter how sexy or unsexy you may feel your product is. Speed and flexibility are both critical to the candidate experience. At Karat, we see that when given the opportunity, 60% of candidates interview outside of business hours and 14% will redo their interview. 3. Unlock software engineering time and put it into product development. Software engineers are motivated by solving problems. Interviewing can be a major distraction from that primary motivation. I’ve heard software engineers say that when interviewing, they only get about one and a half to two productive coding hours in a day. That’s a shame. You can take steps to mitigate the amount of time software engineers spend interviewing and reward those that do. To help maximize productive coding time, consider accommodating schedules. This approach to scheduling recognizes that creative employees, like engineers, are most productive when they aren’t interrupted by meetings and interviews. Instead, it may be better to book them for blocks of time, rather than 30-minute interviews sporadically placed throughout the day. Schedule interviews in blocks of time: maker Your team will ultimately decrease the number of onsite interviews software engineers need to participate in. Then, the creativity and time of a happy and focused team can be unlocked and reinvested into product development. Test your technical interviews to verify they can accurately identify candidates that meet your hiring bar: It can be very demotivating for software engineers to spend time interviewing and feel that it’s a tax on job performance, rather than a benefit to themselves and the team. Consider recognizing and evaluating interviewing skills on performance reviews. This way, you can reward it as well as look for opportunities to team members to improve. Recognize interviewing as a skill in performance reviews: Tech companies claimed the top five spots in the U.S. for R&D spending in 2017, investing a combined total of . In order to keep up with the largest tech companies, it’s imperative to be strategic with how you motivate your software engineers and allocate their time. $76 billion Getting out of the hyper-growth catch 22 It’s true that there isn’t enough software engineering talent to meet demand. The tech talent shortage is real and the competition is not going to relent. However, you can find competitive advantages by: Working in lockstep with recruiting to streamline the process Testing your first-round technical interviews to ensure they identify talent that meets your bar Ensuring your interviews are structured, consistent, but are part of a flexible and fast process Reducing the amount of time software engineers spend interviewing altogether As you look forward to your growth plans in 2019, you may feel like achieving your hiring targets while reaching product development deadlines isn’t possible. To be frank, if nothing changes in the existing process, that might be the case. To achieve your hiring targets and product development goals you’ll have to do what you’ve always done as a tech leader: experiment, innovate and lead by finding a better way to solve a very big problem. To learn more about Karat and what we’re doing to increase interviewing capacity on software engineering teams, visit us at Karat.com .

Are you stuck in the Catch-22 of hiring for hyper-growth?

By Zach van Schouwen, Director of Interview Content. Technical interviewing is something that every company does when hiring software engineers, but often with mixed results. Mis-hires are unfortunately common. Team members tasked with conducting technical interviews will likely use an approach that they are comfortable with, but that others don’t have visibility into and hasn’t been tested for ability to predict performance. What could go wrong? The interviewer may: Assume a candidate knows the criteria for success (when they don’t) Inadvertently overvalue the answer to an irrelevant question Behave or communicate differently with each candidate These are just a few actions that can cause inconsistency in the interview. This will reduce signal for the factors most capable of predicting potential — or fail to measure them at all. Good candidates may end up being rejected, when they could have added significant value to the organization. Creating consistency in variables like questions, a candidate’s background knowledge, and the interviewer’s communication style can go a long way to ensuring that the only variable in the interview is the one you’re trying to evaluate — the candidate. In my role as Director of Interview Content at Karat, I work with our clients to pinpoint exactly which competencies will be critical for success in each role. This guides us in choosing the right questions to ask. An equal amount of work goes into deciding to ask them in a way that will most accurately determine the potential of the candidate. how To accurately identify the candidates most likely to succeed in software engineering roles, we control for dozens if not hundreds of variables in the first-round technical interview. Below are four ways you can dramatically impact the ability of technical interviews to predict onsite and on the job performance. Decrease the risk of false negatives by making criteria for success available to the interviewer and candidate. Simone Biles can’t keep winning gold medals if she doesn’t know what success looks like according to those that hand out medals. Interviewing for a job that requires specific technical skills isn’t really that much different. Candidates and those on the interview loop should be fully aware of the skills and competencies that are relevant to the role. These should be agreed upon across the organization and measurable in the interview process. For example, do you care about the optimality of candidates’ solutions in terms of time/space complexity? If so, how are you measuring this skill, and how predictive is it of future performance on the job? When interviewers and candidates start with the same knowledge of which criteria are determining factors for success, candidates perform better in the interview. This decreases the risk of false negatives. To make sure that the criteria are clear, establish what success looks like and how it will be measured. This should be communicated and agreed upon by all team members. Categorize certain behaviors or skills and then use descriptive statements to identify what beginner, intermediate, and advanced work looks like. Below is a sample question with scoring guide. For context, this is the third question in a series of questions. The candidate and interviewer see the question, while clarifications and scoring categories are seen by the interviewer. This question provides a clear background and instructions for the candidate. Likewise, it includes clear scoring criteria for the interviewer. Any interviewer, hiring manager, or recruiter reviewing the candidate’s results from the interview would know exactly what “beginner” meant as opposed to “advanced.” Criteria for success should be based on tasks that are relevant to the job. In 2017, Software Engineer and Data Scientist Tikhon Jelvis took to to answer the question “what is the future of software engineering interviews?” He said, “I don’t know what will come next, but I know what should come next: carefully calibrated and standardized work-sample tests.” Quora Technical interviews should be predictive of performance at the onsite and on the job. Therefore, technical interviews must rely on performance demonstrated in relevant, real-life problems and challenges. If your company seems to experience a high percentage of false negatives (i.e. rejecting candidates after the technical screen) only to find out later that the candidates went to a high-bar competitor, your technical interviews may not be accurately evaluating skills that are relevant to the job. For example, I’ve seen good candidates rejected from a Java developer role after not answering the following question properly: “given the (x, y, z) coordinates of four points, determine if they all lie in a single plane.” This might be relevant to a few game designers, but not a typical back-end developer. Be rigorous in the process of determining which questions and criteria are truly relevant to the role you’re hiring for. Those that are irrelevant could cause you to reject an otherwise amazing candidate. Communication during the interview matters just as much as asking the right questions. What does verbal and nonverbal communication have to do with consistency and predictiveness, you might ask? Communication is a critically important variable to control for in the technical interview. Interviews are nerve-wracking. An interviewer’s communication and behavior can exacerbate the level of stress a candidate experiences and stifle their ability to problem solve and think creatively. This isn’t good for the company or the candidate. It’s very likely that interviewer communication will be inconsistent across your organization if those tasked with interviewing haven’t been trained on it. Below are a few examples of communication styles interviewers should avoid and instead, those that they should engage in. Examples of three communication styles interviewers should avoid and three to engage in. Thinking carefully about in-interview communication and behavior isn’t enough. The team involved in technical interviewing should practice role playing, with clear guidelines, over an extended time period in order to really get it right. At Karat, interview engineers never really stop practicing and improving — they are required to complete 25 hours of hands-on practice prior to conducting technical interviews on behalf of clients. Over time, they are continuously quality checked. Accountability is a must. Creating consistent questions, defining your success criteria (and being transparent about it), and enforcing proper interviewer communication are all important, but if these standards are not evaluated in a continuous feedback loop, the interviews risk becoming inconsistent and will fail to be predictive. Less experienced interviewers need to be equipped with structured and data-informed best practices to conduct technical interviews. Even strong interviewers can develop bad habits if not checked. In order to implement a technical interview that remains consistent and predictive over time, technical interviews should be thoroughly documented or recorded (with permission, of course) and evaluated by a more experienced interviewer to check for aberrations that lead to inconsistency. Over time, this feedback helps interviewers become significantly more consistent and less prone to these aberrations — and many are even able to avoid them entirely. Final thoughts A consistent technical interview is the only way to ensure that a candidate is truly being evaluated for their potential and produce an accurate assessment of that potential to the hiring team. I’ve personally seen inconsistent and irrelevant interviews result in the rejection of too many great candidates (an action that disproportionately affects underrepresented minorities). At Karat, my job is to make sure that doesn’t happen. This dedicated advocacy has obvious benefits for job candidates, but it also helps the hiring company as they find that more candidates are landing in the right role and becoming more productive more quickly — and having great interview experiences that get them there. To learn more about Karat, please visit Karat.com .

KARAT

karat.com

-- employees

Since n.d.

COMPANY RANKING

KARAT

EVERGREEN INDEX #5424

Representing this company? Click here to claim and customize this page!

Karat WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

KARAT

karat.com

-- employees

Since n.d.

COMPANY RANKING

KARAT

EVERGREEN INDEX #5424

RELATED COMPANIESRANK

STORIES ABOUT KARAT

Representing this company? Click here to claim and customize this page!

Karat WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!