And on the flip side, engineers can likely relate to this. Would you really want to work somewhere doing something that you weren\u2019t excited about? Some people can get by on that \u201cit\u2019s just a day job\u201d mentality, but most people will find it unfulfilling after a while. Companies are looking for engineers who are excited about solving the tough problems of today. If you\u2019re enthusiastic, how will you show it? Bartram suggests researching the company ahead of time and coming up with a list of questions to ask about to show your excitement.<\/span><\/p>\n Triplebyte does extensive technical screening, so when candidates who go through their process are rejected, it\u2019s often for culture fit reasons. Responding to that, Bartram went back and interviewed all the companies extensively about what they look for. \u201cWhat we observed is that [culture fit] is an extremely overloaded term. It doesn\u2019t mean any one thing.\u201d<\/span><\/p>\n A lot of it comes down to core company philosophy and organizing those perspectives as well as needs\/wants. The Triplebyte approach has a ripple effect of success for all parties involved:<\/span><\/p>\n \u201cCompany A just has a strong belief that if you don’t program in compiled language, that\u2019s the sign that you\u2019re not serious. Company B thinks if you programmed in a compiled language, you’re stodgy and old. I think about 50% of interview failures are due to avoidable fit, avoidable mismatches. What we found is that if we can measure this stuff, we can get the interview pass rate basically doubled. Over the last two months, about 53% of our interviews have resulted in a job offer at a company, and that’s roughly twice the rate at those own companies and we\u2019re able to get that rate just by basically measuring these things.\u201d<\/span><\/p>\n There are a variety of nontechnical reasons to not hire a candidate that Bartram covers. Maybe the company thought you were:<\/span><\/p>\n Bartram further breaks down culture fit into two parts:<\/span><\/p>\n \u201cFacebook\u2019s famous early motto of \u2018move fast and break things.\u2019 You can view that as a specific intentional choice that they want to bias towards sort of productive hackers as opposed to other approaches to engineering. Stripe is an example. Stripe has a particular focus on friendliness to a degree much further than basically any other company. Stripe wants to be an extremely friendly, compassionate place and they will reject people who everyone else would hire just because they\u2019re only a 6 out of 10 from this rather than an 8 out of 10.\u201d – Ammon Bartram<\/span><\/p>\n \u201cThe interesting thing is that companies themselves aren\u2019t very crisp about the differences. It\u2019s a catchall phrase that\u2019s often pretty poorly defined,\u201d said Bartram, and that\u2019s where the weird science of technical interviews and human interaction collide. Part of it is \u201cacknowledging that there are skills outside of technical brilliance that matter. The difficulty then is coming up with how do you actually measure those skills in a way you\u2019re not being led astray by confounding factors?\u201d <\/span><\/p>\n <\/p>\n MEASURES OF SUCCESS: HOW TO CONDUCT AN INTERVIEW<\/b><\/p>\n Triplebyte has found that sometimes the most straightforward engineering problems can be the most predictive and concrete measures of progress, and that an engineer\u2019s interviewing process can be a huge indicator of their working and problem-solving styles.<\/span><\/p>\n Bartram talked through how Triplebyte evaluates interviews:<\/span><\/p>\n \u201cWe like having like paired metrics. One metric to that is a raw measure of how far they got. The second measure, that\u2019s a measure of, for example, process quality. We also like recording subjective numbers and objective numbers. An objective measure of quality will be; did they write tests? Did they create constants to record these values. Did they generalize the problem such that this aspect can be changed and it will still work? A long list of things like that we record yes, no, for these things. Did they do these things? We\u2019re expressing some judgments, because there are some great programmers who might not do some of those things. In balance, we find that people who run a better process get more check marks than people who don\u2019t. That\u2019s these sort of the objective measure of code quality. The objective measure of progress is just how many of these tests passed within the time that they\u2019re working.\u201d<\/span><\/p>\n <\/p>\n One experiment Triplebyte did was with take-home projects. People could do both a regular interview and then also a longer take-home project. \u201cLooking at the difference in quality between the work people did during an hour or two when they\u2019re on the spot versus when they had their time to think about it, it was really quite enlightening,\u201d Bartram said. \u201cJust people who we had written off as bad would then turn around and do really impressive professional-level work.\u201d<\/span> <\/p>\n Here\u2019s Triplebyte\u2019s perspective on interview questions. <\/span><\/p>\n The Bad:<\/b><\/p>\n Questions that require sort of a single leap of insight are very bad questions, because the answer ends up being extremely noisy. Questions where the answer can be given away easily are also bad. <\/span><\/p>\n Example of a bad interview question: <\/b><\/p>\n A better approach is a question where the answer is 45 minutes of programming, and so there\u2019s very little that could have been done sort of practicing the programming ahead of time to give them an advantage. You can measure the candidate \u00a0moving through the process and give some of the noise people get stuck by giving some clues and not totally invalidate the question. <\/span><\/p>\n Example of a good interview question:<\/b><\/p>\n Whiteboarding might really get your motor running, practicing at home with challenging algorithms while wearing your comfy socks. Or it might be the bane of your existence, a necessary evil on the path of success. Bartram sees both sides of the whiteboarding controversy:<\/span><\/p>\n \u201cWhat we found is just there are many many different ways to be good. Someone can be a great programmer and if you ask them at working on a whiteboard, their actual arguments for why a whiteboard is a good way to run a programming interview. This is something that a lot of people have very strong belief that whiteboards are terrible and there is a slight argument. The argument is giving an engineer a whiteboard in an interview, you are removing the constraint that their code actually compile and run and so they don\u2019t get these lose time worrying about the exact syntax of an API call. They can just focus on the core logic. I think ultimately that falls down \u2014 If that\u2019s what you care about, you should probably just have the programmer write code on a computer and then tell them that doesn\u2019t need to run. But there is that argument, and so the more I\u2019ve done this, the more I\u2019ve just sort of come to challenge all of the beliefs that everyone has. The answer is that it’s some weighted combination. The true signal is just some weighted combination of all the different parts that everyone has in their head.\u201d<\/span><\/p>\n Kyle Polich from the <\/span>Data Skeptic podcast<\/span><\/a> has some other <\/span>perspectives for interviewers<\/span><\/a>:<\/span><\/p>\n \u201cMost people are not trained in how to interview properly. They go into a room and seem to ask questions along the lines of, \u2018Does this person know the same things I know?\u2019 Whereas they should actually be asking, \u2018Can this person do the job?\u2019 <\/span><\/p>\n False-positives and false-negatives are another point of controversy within the hiring realm. Bartram reveals, \u201cIt does make sense to optimize for fewer false-positives and more false-negatives, but I think companies still underestimate their actual false-negative rate, and you can look at that by looking at the agreement rate between companies.\u201d <\/span><\/p>\n There are a lot of different ways to conduct interviews, but Triplebyte\u2019s innovative approach considers both the parameters that the hiring companies set forth, as well as their own special blend of unbiased interview conditions.<\/span><\/p>\n <\/p>\n ON HIRING AND BEING HIRED<\/b><\/p>\n In conclusion, the right way to measure skill is not clear-cut and yet Triplebyte is doing a tremendous job in paving a new way forward on the hiring path. Instead of asking people you\u2019re hiring the same questions that you were once asked, there are newer and more efficient ways to round out your team, as well as better ways to connect with the right team for you.<\/span><\/p>\n It\u2019s not easy being a job-seeker or a hiring manager. But with a lot of preparation, clear goals and expectations, open communication, and an open mind, you\u2019ll be on your way to finding your next great career path or hire. Just remember that a lot of people are going through the same frustrations and challenges, and a company like Triplebyte is making the whole process a little easier to find that needle in the haystack person or opportunity. Look beyond the old questions, and maybe even whiteboarding, and look ahead to the dawn of a more efficient and enjoyable interviewing era. Now let\u2019s get back to building great software!<\/span><\/p>\n Triplebyte is a company that connects engineers with top tech companies. We\u2019re running an experiment and our hypothesis is that Software Engineering Daily listeners will do well above average on the quiz. Go to <\/span><\/i>triplebyte.com\/sedaily<\/span><\/i><\/a> and take the multiple-choice quiz, and in a few episodes we\u2019ll share some stats about how you all did. Try it yourself at <\/span><\/i>triplebyte.com\/sedaily<\/span><\/i><\/a>.<\/span><\/i><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" CULTURE FIT, OR: TECHNICAL SKILLS MATTER, SOFT SKILLS ALSO MATTER \u201cCulture fit\u201d is a term that is used to describe engineers that have the right personality for a given company. In the hiring process, \u201clack of culture fit\u201d is used to turn away engineers who are good enough at coding but just don\u2019t seem right<\/p>\n","protected":false},"author":10,"featured_media":5270,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"[Article] Strategies for Interviewing and Hiring: Part 2 of 2 by Erika Hokanson @erikawh0 @Triplebyte","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[1363,83],"tags":[1194,1013,383,2192,628,1559,1195],"class_list":["post-5260","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-all-episodes","category-articles","tag-ammon-bartram","tag-erika-hokanson","tag-hiring","tag-interviewing","tag-jeff-meyerson","tag-job-hunting","tag-triplebyte"],"jetpack_publicize_connections":[],"acf":[],"yoast_head":"\n![\"\"](\"https:\/\/i0.wp.com\/softwareengineeringdaily.com\/wp-content\/uploads\/2018\/06\/softwaredevs-300x225.jpg?resize=300%2C225&ssl=1\")
<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/softwareengineeringdaily.com\/wp-content\/uploads\/2018\/06\/Screen-Shot-2018-06-20-at-5.37.28-PM-300x122.png?resize=500%2C203&ssl=1\")
<\/p>\n\n
\n
![\"\"](\"https:\/\/i0.wp.com\/softwareengineeringdaily.com\/wp-content\/uploads\/2018\/06\/TechnicalInterview-298x300.png?resize=298%2C300&ssl=1\")
<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/softwareengineeringdaily.com\/wp-content\/uploads\/2018\/06\/TriplebyteHireGreatEngineersQuickly-300x83.png?resize=500%2C139&ssl=1\")
<\/p>\n
\n<\/span>
\n<\/span>\u201cI think if you watch yourself, if you really sort of introspect to look at your own decision making process, when you\u2019re trying to do an interview for a [nontechnical role], I think you\u2019ll notice that \u2014 the thing you\u2019re thinking 30 seconds in is what you\u2019re going to think at the end. But when asking technical questions, the impression actually does change quite a lot over time.\u201d – Ammon Bartram<\/i><\/b><\/p>\n![\"\"](\"https:\/\/i0.wp.com\/softwareengineeringdaily.com\/wp-content\/uploads\/2018\/06\/Screen-Shot-2018-06-20-at-5.34.48-PM-300x177.png?resize=500%2C294&ssl=1\")
<\/p>\n\n
\n<\/span>The Good:<\/b><\/p>\n\n
![\"\"](\"https:\/\/i0.wp.com\/softwareengineeringdaily.com\/wp-content\/uploads\/2018\/06\/WhiteboardingInterviewWoman.jpeg?ssl=1\")
<\/a><\/p>\n<\/p>\n<\/p>\n
\n<\/a><\/p>\n