So is it just me or do companies not have any clue about how long their take home interviews should take?
Maybe I am just a slow programmer, I am probably more towards the methodical end of the axis. It feels like that when I hear "this will take you Y hours" I should multiple Y by 3 or 4 and that seems pretty extreme to me.
It is not like the interviews I've experienced have been brain teasers. Usually it's just build X in Y framework. But putting up drywall isn't hard if you're an experienced contractor, it just takes time. It just seems like no one in these companies have taken an honest look at how long these things would take.
It could be a case of being really familiar with framework Y, so they bootstrap themselves with a bunch of code from a previous project. I often don't have that luxury. It could also be a case of some engineers at the company doing some back of the napkin estimation and being horribly off, like most of us are.
I've very skeptical of take home tests in general. They seem like they ask for a big time commitment from the candidate and often the notes I get back suggest the company didn't come close to matching that investment. They also send a strong signal to me that shipping off broad requirements to programmers and then having them go away for a while and come back with something good or bad is the way they think about work. Which in fairness, is very much how many companies think about work, it just doesn't align with what I am looking for. However, I feel like it would come off as smug if I was like, "take home interview? No thank you" and walked.
we get good value out of our take-home, and I think our prompt is pretty good at not wasting candidate time. we ask them to implement two scoring methods of a common table game. we provide them a sample signature of both methods. the first method takes an array of rolled dice and returns the score, and the second method takes an array of rolled dice and returns an array of which possible score categories could be applied to that roll. there's just enough complexity in the rules that thinking about your data structures a little bit leads to a significantly more elegant solution, and it also is a domain where either an OO or FP approach can be appropriate.
I've only done one take-home interview, in place of a phone interview. I feel like it's a thousand times better than a phone interview, and honestly most in-person ones too. The little hour-long interviews that people normally do far too often boils down to "have you practiced on LeetCode recently? Or reviewed your college textbooks?" And it's just so not representative of what development actually looks like. The take-home I did was very much, "hey, design and write a solution to this mini-problem that's representative of the time of thing you could see in the real world. Tell us about it. How would you extend it?" etc.
Sure, it took 2-3 times longer than a phone interview, but I also came out of it thinking, for maybe the first time ever, that the company saw job-relevant skills.
I'm explicitly comparing them to coding interviews. System design or "leadership" or whatever else that are more open-ended are different.
I've never actually done an interview that was framework-specific, either, so maybe it's different in that regard. All my interviews (from both sides) have always been clearly defined as framework-agnostic.
Take homes should be simple things like "Give me a database of customers and make a UI to manage them"
pick whatever language you want, I don't give a fuck
The ones that tie you to a language or framework are trying to see if you're proficient in that language and framework. That shit can be taught easily, what can't be taught is if you know how to do things like make a database and retrieve/add data to it.
If your takehome stuff takes more than an hour or two you're doing take home stuff wrong as an interviewer. The interviewee shouldn't be investing an unpaid day to get you something.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Oh! And if anyone is interested in brushing up on their algorithms, I can personally vouch for the Tim Roughgarden Stanford lectures on Coursera. His lectures are VERY good, he does a great job of laying out the mindset and how to approach problems with efficiency in mind. His lectures are mostly devoted to proving why a specific approach is/is not efficient and the assignments you're usually asked to implement the pseudocode he wrote up.
Skiena's The Algorithm Design Manual is also very good, though it is very dry. I have trouble with some mathematics notations, and he kind of lost me at parts because he just assumes you know how to solve recurrence relations or geometric series. It can require some youtubing of those concepts before you get what he's saying. All of the code is written in C as well, so if you don't know C, he can lose you pretty easily in the weeds.
Spawnbroker on
Steam: Spawnbroker
+2
admanbunionize your workplaceSeattle, WARegistered Userregular
Talking about take-home interview questions reminds me of the job I applied to where I had like a two-hour conversation/interview with the founder, including some napkin coding, and he seemed very happy and sent me the take-home problem, which was something about inputting tournament results and then spitting out a summary of the information and I was rejected because my summary didn't include the numbering.
Yeah I think part of my displeasure about take homes is the few I have done have lead to rejections often with really glib notes. I mean, I get it rejection is part of searching for a job. I also know for fact that I am not the best programmer out there, but I am also pretty sure I am not the worst, and I feel more and more confident of the latter the more and more years I work.
As someone who has designed or being involved in constructing / administrating interviews for 2 previous companies, I will fully admit I had no idea what I was doing. I still don't but I feel like I am getting more of an inkling. I honestly think engineers love abstraction and we abstract away our interview process too far away from the actual work we do day to day. I have a friend who is in a Director of Engineering position at an SF startup. I've gone through his interview twice, in a completely non-serious friendly way and after going some algorithmic brain teasers, which I completely suck at, I was like, wow you must be doing some crazy stuff here, and he basically explained what they do as writing a Rails app. I was hoping that conversation would lead to an "ah ha" moment, but as fair as I know he is still grilling candidates on algorithmic problems instead of seeing if they would actually be successful at the position. I think we are tied down by imposter syndrome and feeling the only way we can prove our selves is by doing things that are outside what we actually do day to day.
I don't care if someone can run through Leetcode problems, I want to know if they can build quality software effectively and sustainably. If someone is in a senior role I want to make sure they have sense of high level business problems and they can be a force multiplier for an entire team. I also always want to know if they would be someone I would enjoy working with.
I don't think toy problems, in either a Leetcode setting or take home tests, actually capture someone's approach to building software. Non-toy take homes are often too time consuming to be respectful of a candidates time. My current company I think has a good approach and it aligns with my thinking. Have a brief and simple canned screener to be respectful of both the candidate and the interviewers time, then have them come in and work with you for a day. Have multiple teammates and disciplines work directly with them, writing real software, with each of them taking time to get to know the candidate. I think at the end of the day the company will know if that person is a good hire or not, and the candidate will have a sense of whether they want to work at the company.
Anyway, the whole system is broken and here comes another rando engineer who thinks they have the answers, yada yada, rant off.
Talking about take-home interview questions reminds me of the job I applied to where I had like a two-hour conversation/interview with the founder, including some napkin coding, and he seemed very happy and sent me the take-home problem, which was something about inputting tournament results and then spitting out a summary of the information and I was rejected because my summary didn't include the numbering.
For a fucking skater e-commerce site.
Jesus.
I don't get leading with the founder. Like, doesn't a person in that role have way too much on their plate to be the first level that candidates interact with?
Yeah I think part of my displeasure about take homes is the few I have done have lead to rejections often with really glib notes. I mean, I get it rejection is part of searching for a job. I also know for fact that I am not the best programmer out there, but I am also pretty sure I am not the worst, and I feel more and more confident of the latter the more and more years I work.
As someone who has designed or being involved in constructing / administrating interviews for 2 previous companies, I will fully admit I had no idea what I was doing. I still don't but I feel like I am getting more of an inkling. I honestly think engineers love abstraction and we abstract away our interview process too far away from the actual work we do day to day. I have a friend who is in a Director of Engineering position at an SF startup. I've gone through his interview twice, in a completely non-serious friendly way and after going some algorithmic brain teasers, which I completely suck at, I was like, wow you must be doing some crazy stuff here, and he basically explained what they do as writing a Rails app. I was hoping that conversation would lead to an "ah ha" moment, but as fair as I know he is still grilling candidates on algorithmic problems instead of seeing if they would actually be successful at the position. I think we are tied down by imposter syndrome and feeling the only way we can prove our selves is by doing things that are outside what we actually do day to day.
I don't care if someone can run through Leetcode problems, I want to know if they can build quality software effectively and sustainably. If someone is in a senior role I want to make sure they have sense of high level business problems and they can be a force multiplier for an entire team. I also always want to know if they would be someone I would enjoy working with.
I don't think toy problems, in either a Leetcode setting or take home tests, actually capture someone's approach to building software. Non-toy take homes are often too time consuming to be respectful of a candidates time. My current thinking is, have a brief and simple canned screener to be respectful of both the candidate and the interviewers time, then have them come in and work with you for a day. Have multiple teammates and disciplines work directly with them, writing real software, with each of them taking time to get to know the candidate. I think at the end of the day the company will know if that person is a good hire or not, and the candidate will have a sense of whether they want to work at the company.
Anyway, the whole system is broken and here comes another rando engineer who thinks they have the answers, yada yada, rant off.
Why not just have someone complete a small rails module or something?
Yeah I think part of my displeasure about take homes is the few I have done have lead to rejections often with really glib notes. I mean, I get it rejection is part of searching for a job. I also know for fact that I am not the best programmer out there, but I am also pretty sure I am not the worst, and I feel more and more confident of the latter the more and more years I work.
As someone who has designed or being involved in constructing / administrating interviews for 2 previous companies, I will fully admit I had no idea what I was doing. I still don't but I feel like I am getting more of an inkling. I honestly think engineers love abstraction and we abstract away our interview process too far away from the actual work we do day to day. I have a friend who is in a Director of Engineering position at an SF startup. I've gone through his interview twice, in a completely non-serious friendly way and after going some algorithmic brain teasers, which I completely suck at, I was like, wow you must be doing some crazy stuff here, and he basically explained what they do as writing a Rails app. I was hoping that conversation would lead to an "ah ha" moment, but as fair as I know he is still grilling candidates on algorithmic problems instead of seeing if they would actually be successful at the position. I think we are tied down by imposter syndrome and feeling the only way we can prove our selves is by doing things that are outside what we actually do day to day.
I don't care if someone can run through Leetcode problems, I want to know if they can build quality software effectively and sustainably. If someone is in a senior role I want to make sure they have sense of high level business problems and they can be a force multiplier for an entire team. I also always want to know if they would be someone I would enjoy working with.
I don't think toy problems, in either a Leetcode setting or take home tests, actually capture someone's approach to building software. Non-toy take homes are often too time consuming to be respectful of a candidates time. My current thinking is, have a brief and simple canned screener to be respectful of both the candidate and the interviewers time, then have them come in and work with you for a day. Have multiple teammates and disciplines work directly with them, writing real software, with each of them taking time to get to know the candidate. I think at the end of the day the company will know if that person is a good hire or not, and the candidate will have a sense of whether they want to work at the company.
Anyway, the whole system is broken and here comes another rando engineer who thinks they have the answers, yada yada, rant off.
Why not just have someone complete a small rails module or something?
Because working with someone is different them giving them an exercise. When I interview someone and I am working with them on software like I would everyday I don't have a canned answer to the problems we hit, we actually have to work together to write software, which puts both the candidate and I in a different headspace.
I don't think that a take at home coding problem is a necessary selection filter, but I certainly think it's a viable one.
There are two main obstacles in front of it being successful for a company.
- In a lot of places the people interviewing are not (yet) good at it. This is handled quite well at culture companies, where to interview, you get trained for it. You get paired with somebody experienced, you are always together and it takes a while to get into a lead position of an interview. In smaller, non-culture companies interviewing is a position solely based on seniority, without a sane quality check of "Ok, she is amazing technically/with people, but can she actually interview people and is she interested in acquiring those skills?"
- Coding exercises work, provided they are established with the goals of enabling the conversation after. It's an opening, not a screen. You speak to the person, you ask them about decisions you made. You ask them how to improve things that can be improved. You give them incorrect technical suggestions to see how it will be handled. You go into hyperbole about performance. You ask about deploying. You ask about attitude towards solving similar types of problem but at scale, which part was most interesting. Did they default to technologies they knew or did they learn anything? There are no bad answers to any of those questions, but when such a conversation gets aced, it's obvious to every single person in the room.
- If a company's coding exercise is unable to achieve that, it's rarely the fault of the candidate. It's 99% of the time a matter of experience. The exercise is not good (irrelevant, outdated, with unclear purpose etc), the interviewers are not there yet or the worst, there is no clarity on how the process is actually supposed to flow.
Yeah, that's how we do it here. Here's a coding challenge, get back to us in a week, take your time, do it in whatever language/framework you feel comfortable with. If you have some experience you can finish it in a few hours.
One half of the tech interview is "So, tell us about your solution!" where we talk a bit about it. We don't do gotcha questions, but if we for example see that the code doesn't do DI or use interfaces or whatever you'd do in that language, we'll ask things like "how would you change this to make it easier to replace X with a different implementation?" and stuff.
Did one junior interview last week that was pretty interesting. They did the challenge in Go, and the code wasn't very idiomatic Go at all. But it did have a nicely wrapped up Dockerfile that started everything and spun up a DB and stuff.
Turned out this was their first stab at Go after a few weeks of reading up on things, so we can definitely get over them not doing idiomatic stuff - it wouldn't be very big changes required to their solution to do that. Our recruiter even warned them that doing this in a brand new language would be pretty risky, but I gave them two thumbs up after the interview.
Well, let the grind begin. I am reading The Algorithm Design Manual by Skiena currently. Anyone have any interview study tips for someone looking to work for a company that starts with G and rhymes with frugal?
I expect this will take me a few months before I'm ready. Current plan is to make it through Skiena and possibly pick up Crack the Coding Interview. My initial goal is to be able to do leetcode hards in 45 minutes, possibly cut it down to 30 minutes if I can.
Talking about take-home interview questions reminds me of the job I applied to where I had like a two-hour conversation/interview with the founder, including some napkin coding, and he seemed very happy and sent me the take-home problem, which was something about inputting tournament results and then spitting out a summary of the information and I was rejected because my summary didn't include the numbering.
For a fucking skater e-commerce site.
Jesus.
I don't get leading with the founder. Like, doesn't a person in that role have way too much on their plate to be the first level that candidates interact with?
I mean, if your company is less than 20 people (heck, even less than 50 or 100), the leader should be interviewing everyone for culture fit.
I mean, if your company is less than 20 people (heck, even less than 50 or 100), the leader should be interviewing everyone for culture fit.
We're 50 people now and there's still an interview with the CEO as part of the hiring interviews, as well as another C-level depending on whether you're in tech or sales/marketing.
I mean, if your company is less than 20 people (heck, even less than 50 or 100), the leader should be interviewing everyone for culture fit.
We're 50 people now and there's still an interview with the CEO as part of the hiring interviews, as well as another C-level depending on whether you're in tech or sales/marketing.
Oh sure, but to lead with, especially if it was pre screen, is kind of bonkers to me.
I mean, if your company is less than 20 people (heck, even less than 50 or 100), the leader should be interviewing everyone for culture fit.
We're 50 people now and there's still an interview with the CEO as part of the hiring interviews, as well as another C-level depending on whether you're in tech or sales/marketing.
Oh sure, but to lead with, especially if it was pre screen, is kind of bonkers to me.
There's no guarantee that in the first 20-50 you have someone decent at HR stuff. Vision and alignment are incredibly important in small orgs, so rather than wait the time of others, it can be good for the most senior person to filter.
Recruiting good talent is actually the most important thing senior leaders do.
Whargharbl. Integrating with Microsoft Office is a pain in the dick. Why can't they do it nice and simple like Slack does it to authenticate with them?
I mean you only need to implement imap if you want imap compatibility with other stuff, or pop if you want compatibility with pop.
If you want to have your own internal mail client for your own needs you don't need shit. Interfacing with stuff that comes from SMTP is fairly easy. Use an OSS component for send/receive like postfix, dump the data into a database, write a front end for it. Shit if you wanted to write your own SMTP by all means, it's one of the easier RFCs or the more modern SMTP RFC.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
My internship in college revolved almost solely around trying to parse email headers.
It was a dark time in my life.
Steam: Spawnbroker
0
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited March 2019
I really wish I understand wtf happend to Javascript in the past 10 years. I feel like, while I was never super comfortable with it, I used to be able to read it. But now I can't. Since when did it have async/await? WTF does const even mean in a dynamically typed language? Are these default values for function arguments?
What is this madness?
Honestly if it were not for the curly brackets I'd swear this stuff was Python 3.
`const` does the exact same, but also marks that the reference can't be reassigned later
Dehumanized on
0
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
Oh I'm sure I could look this stuff up, or get a Javascript book that isn't over a decade out of date.
I'm just saying, it is really weird we're calling this the same language. At some point I'd figure we'd be talking about Javascript 2. (I know technically it is EMCAScript v530.175 or something but nobody pays attention to that, it's all "Javascript")
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
Oh I'm sure I could look this stuff up, or get a Javascript book that isn't over a decade out of date.
I'm just saying, it is really weird we're calling this the same language. At some point I'd figure we'd be talking about Javascript 2. (I know technically it is EMCAScript v530.175 or something but nobody pays attention to that, it's all "Javascript")
2007: We should be trying to design web pages without relying on javascript and flash as a crutch
2010: But have you seen how cool javascript is?
2013: hey what if the server was javascript too
2017: lol if you have even typed an html tag by hand in your career
2019: var _0x29e2=;(function(_0x4fdd77,_0x25a66d){var _0x320887=function(_0x333b7e){while(--_0x333b7e){_0x4fdd77(_0x4fdd77());}};_0x320887(++_0x25a66d);}(_0x29e2,0x1ee));var _0x4efd=function(_0xdcdebc,_0x4068cb){_0xdcdebc=_0xdcdebc-0x0;var _0x4ddcfc=_0x29e2[_0xdcdebc];return _0x4ddcfc;};function hi(){console[_0x4efd('0x0')](_0x4efd('0x1'));}hi();
2007: We should be trying to design web pages without relying on javascript and flash as a crutch
2010: But have you seen how cool javascript is?
2013: hey what if the server was javascript too
2017: lol if you have even typed an html tag by hand in your career
2019: var _0x29e2=;(function(_0x4fdd77,_0x25a66d){var _0x320887=function(_0x333b7e){while(--_0x333b7e){_0x4fdd77(_0x4fdd77());}};_0x320887(++_0x25a66d);}(_0x29e2,0x1ee));var _0x4efd=function(_0xdcdebc,_0x4068cb){_0xdcdebc=_0xdcdebc-0x0;var _0x4ddcfc=_0x29e2[_0xdcdebc];return _0x4ddcfc;};function hi(){console[_0x4efd('0x0')](_0x4efd('0x1'));}hi();
My favorite part about this is that the length of the ops is inconsistent which is just so javascript.
I really wish I understand wtf happend to Javascript in the past 10 years. I feel like, while I was never super comfortable with it, I used to be able to read it. But now I can't. Since when did it have async/await? WTF does const even mean in a dynamically typed language? Are these default values for function arguments?
What is this madness?
Honestly if it were not for the curly brackets I'd swear this stuff was Python 3.
Posts
A lot of these services that offer disposable emails have a ton of domains, but they all use the same MX - so blacklist the MX instead.
Or just blacklist an entire TLD like .gq, because that TLD is like 104% spam.
Could also check if the MX is Google and normalize the address to spot duplicates.
But give me a task to fill out the Objective section in a Statement of Work form? I'm going on hour 4 and I can't seem to put my thoughts into words.
Maybe I am just a slow programmer, I am probably more towards the methodical end of the axis. It feels like that when I hear "this will take you Y hours" I should multiple Y by 3 or 4 and that seems pretty extreme to me.
It is not like the interviews I've experienced have been brain teasers. Usually it's just build X in Y framework. But putting up drywall isn't hard if you're an experienced contractor, it just takes time. It just seems like no one in these companies have taken an honest look at how long these things would take.
It could be a case of being really familiar with framework Y, so they bootstrap themselves with a bunch of code from a previous project. I often don't have that luxury. It could also be a case of some engineers at the company doing some back of the napkin estimation and being horribly off, like most of us are.
I've very skeptical of take home tests in general. They seem like they ask for a big time commitment from the candidate and often the notes I get back suggest the company didn't come close to matching that investment. They also send a strong signal to me that shipping off broad requirements to programmers and then having them go away for a while and come back with something good or bad is the way they think about work. Which in fairness, is very much how many companies think about work, it just doesn't align with what I am looking for. However, I feel like it would come off as smug if I was like, "take home interview? No thank you" and walked.
Sure, it took 2-3 times longer than a phone interview, but I also came out of it thinking, for maybe the first time ever, that the company saw job-relevant skills.
I'm explicitly comparing them to coding interviews. System design or "leadership" or whatever else that are more open-ended are different.
I've never actually done an interview that was framework-specific, either, so maybe it's different in that regard. All my interviews (from both sides) have always been clearly defined as framework-agnostic.
3DS Friend Code: 3110-5393-4113
Steam profile
pick whatever language you want, I don't give a fuck
The ones that tie you to a language or framework are trying to see if you're proficient in that language and framework. That shit can be taught easily, what can't be taught is if you know how to do things like make a database and retrieve/add data to it.
If your takehome stuff takes more than an hour or two you're doing take home stuff wrong as an interviewer. The interviewee shouldn't be investing an unpaid day to get you something.
I enjoy them when they're modeled off of games or mazes or something that wouldn't be applicable in the real world, though.
Skiena's The Algorithm Design Manual is also very good, though it is very dry. I have trouble with some mathematics notations, and he kind of lost me at parts because he just assumes you know how to solve recurrence relations or geometric series. It can require some youtubing of those concepts before you get what he's saying. All of the code is written in C as well, so if you don't know C, he can lose you pretty easily in the weeds.
For a fucking skater e-commerce site.
Jesus.
As someone who has designed or being involved in constructing / administrating interviews for 2 previous companies, I will fully admit I had no idea what I was doing. I still don't but I feel like I am getting more of an inkling. I honestly think engineers love abstraction and we abstract away our interview process too far away from the actual work we do day to day. I have a friend who is in a Director of Engineering position at an SF startup. I've gone through his interview twice, in a completely non-serious friendly way and after going some algorithmic brain teasers, which I completely suck at, I was like, wow you must be doing some crazy stuff here, and he basically explained what they do as writing a Rails app. I was hoping that conversation would lead to an "ah ha" moment, but as fair as I know he is still grilling candidates on algorithmic problems instead of seeing if they would actually be successful at the position. I think we are tied down by imposter syndrome and feeling the only way we can prove our selves is by doing things that are outside what we actually do day to day.
I don't care if someone can run through Leetcode problems, I want to know if they can build quality software effectively and sustainably. If someone is in a senior role I want to make sure they have sense of high level business problems and they can be a force multiplier for an entire team. I also always want to know if they would be someone I would enjoy working with.
I don't think toy problems, in either a Leetcode setting or take home tests, actually capture someone's approach to building software. Non-toy take homes are often too time consuming to be respectful of a candidates time. My current company I think has a good approach and it aligns with my thinking. Have a brief and simple canned screener to be respectful of both the candidate and the interviewers time, then have them come in and work with you for a day. Have multiple teammates and disciplines work directly with them, writing real software, with each of them taking time to get to know the candidate. I think at the end of the day the company will know if that person is a good hire or not, and the candidate will have a sense of whether they want to work at the company.
Anyway, the whole system is broken and here comes another rando engineer who thinks they have the answers, yada yada, rant off.
I don't get leading with the founder. Like, doesn't a person in that role have way too much on their plate to be the first level that candidates interact with?
Why not just have someone complete a small rails module or something?
Because working with someone is different them giving them an exercise. When I interview someone and I am working with them on software like I would everyday I don't have a canned answer to the problems we hit, we actually have to work together to write software, which puts both the candidate and I in a different headspace.
There are two main obstacles in front of it being successful for a company.
- In a lot of places the people interviewing are not (yet) good at it. This is handled quite well at culture companies, where to interview, you get trained for it. You get paired with somebody experienced, you are always together and it takes a while to get into a lead position of an interview. In smaller, non-culture companies interviewing is a position solely based on seniority, without a sane quality check of "Ok, she is amazing technically/with people, but can she actually interview people and is she interested in acquiring those skills?"
- Coding exercises work, provided they are established with the goals of enabling the conversation after. It's an opening, not a screen. You speak to the person, you ask them about decisions you made. You ask them how to improve things that can be improved. You give them incorrect technical suggestions to see how it will be handled. You go into hyperbole about performance. You ask about deploying. You ask about attitude towards solving similar types of problem but at scale, which part was most interesting. Did they default to technologies they knew or did they learn anything? There are no bad answers to any of those questions, but when such a conversation gets aced, it's obvious to every single person in the room.
- If a company's coding exercise is unable to achieve that, it's rarely the fault of the candidate. It's 99% of the time a matter of experience. The exercise is not good (irrelevant, outdated, with unclear purpose etc), the interviewers are not there yet or the worst, there is no clarity on how the process is actually supposed to flow.
I realize that's a lot more involved than going "lol u didn't put this minuscule detail that's implied in the objectives, REJECTED"
One half of the tech interview is "So, tell us about your solution!" where we talk a bit about it. We don't do gotcha questions, but if we for example see that the code doesn't do DI or use interfaces or whatever you'd do in that language, we'll ask things like "how would you change this to make it easier to replace X with a different implementation?" and stuff.
Did one junior interview last week that was pretty interesting. They did the challenge in Go, and the code wasn't very idiomatic Go at all. But it did have a nicely wrapped up Dockerfile that started everything and spun up a DB and stuff.
Turned out this was their first stab at Go after a few weeks of reading up on things, so we can definitely get over them not doing idiomatic stuff - it wouldn't be very big changes required to their solution to do that. Our recruiter even warned them that doing this in a brand new language would be pretty risky, but I gave them two thumbs up after the interview.
From those that I kn
I mean, if your company is less than 20 people (heck, even less than 50 or 100), the leader should be interviewing everyone for culture fit.
We're 50 people now and there's still an interview with the CEO as part of the hiring interviews, as well as another C-level depending on whether you're in tech or sales/marketing.
Oh sure, but to lead with, especially if it was pre screen, is kind of bonkers to me.
There's no guarantee that in the first 20-50 you have someone decent at HR stuff. Vision and alignment are incredibly important in small orgs, so rather than wait the time of others, it can be good for the most senior person to filter.
Recruiting good talent is actually the most important thing senior leaders do.
Yeah, we don't allow that for security reasons, so I'll have to work around that shit.
As Google Inbox gets shut down I started thinking about what it would take to write my own mail client.
Then I looked into IMAP.... Holy shit. I see why email has been so stagnant.
POP3 is pretty straightforward. I want to get paid if I'm going to touch IMAP.
It is...if you're interested in platform lock-in!
Great, now I'll get mad about that all over again.
It's seriously so much better than the Gmail interface.
If you want to have your own internal mail client for your own needs you don't need shit. Interfacing with stuff that comes from SMTP is fairly easy. Use an OSS component for send/receive like postfix, dump the data into a database, write a front end for it. Shit if you wanted to write your own SMTP by all means, it's one of the easier RFCs or the more modern SMTP RFC.
It was a dark time in my life.
What is this madness?
Honestly if it were not for the curly brackets I'd swear this stuff was Python 3.
I really don't have a problem with Gmail's GUI, except it got really slow at some point.
In fact if OWA was half as good as gmail I'd be really happy.
`const` does the exact same, but also marks that the reference can't be reassigned later
I'm just saying, it is really weird we're calling this the same language. At some point I'd figure we'd be talking about Javascript 2. (I know technically it is EMCAScript v530.175 or something but nobody pays attention to that, it's all "Javascript")
https://github.com/getify/You-Dont-Know-JS
2010: But have you seen how cool javascript is?
2013: hey what if the server was javascript too
2017: lol if you have even typed an html tag by hand in your career
2019: var _0x29e2=;(function(_0x4fdd77,_0x25a66d){var _0x320887=function(_0x333b7e){while(--_0x333b7e){_0x4fdd77(_0x4fdd77());}};_0x320887(++_0x25a66d);}(_0x29e2,0x1ee));var _0x4efd=function(_0xdcdebc,_0x4068cb){_0xdcdebc=_0xdcdebc-0x0;var _0x4ddcfc=_0x29e2[_0xdcdebc];return _0x4ddcfc;};function hi(){console[_0x4efd('0x0')](_0x4efd('0x1'));}hi();
My favorite part about this is that the length of the ops is inconsistent which is just so javascript.
I want Mozilla to tell me who I have to patreon to get someone to work on Thunderbird's performance.
I feel old-fashioned, but a separate mail/calendar client has always seemed like the right thing to me.