Dear Programming Job Applicants (2010)(joshcarter.com)
joshcarter.com
Dear Programming Job Applicants (2010)
http://joshcarter.com/software/dear_programming_job_applicant/
198 comments
>Write code on Gedit?
That's fascism, what's your problem if I write my code on CLion? Should I write code on a hipster typewriter and scan my printed document straight to the compiler? Does that make me a qualified programmer?
That's fascism, what's your problem if I write my code on CLion? Should I write code on a hipster typewriter and scan my printed document straight to the compiler? Does that make me a qualified programmer?
Note this is from 2010, but still has many relevant points. As someone who has made some of these mistakes, I'd say the tl;dr is:
Good hiring managers prepare for an interview, so you best prepare as well.
Good hiring managers prepare for an interview, so you best prepare as well.
Depressingly, the difference between then and now is today's blog post would be advice for how to ace your 3 part interview, each with a 1 hour coding test and the take home project for which you are expected to sign an NDA
> So, your code isn’t working, what do you do? Stare blankly at the monitor?
This always gets me. When the interviewer asks a question, the correct answer is literally never, “let me think about it quietly for a moment”. This is one of the disconnects between interview programming and real programming people get frustrated over.
This always gets me. When the interviewer asks a question, the correct answer is literally never, “let me think about it quietly for a moment”. This is one of the disconnects between interview programming and real programming people get frustrated over.
It only shows this interviewer doesn't really know much about programmers' daily job and has never been programming themselves.
Also this: "It’s funny how many people can’t edit text on any machine but their own." - I bought a notebook without properly checking the keyboard and even now after 3 years it still bugs me everytime I type. Nobody can understand how these things can really limit focus. If I got a different computer with different keyboard, different operating system, different text editor (not even an IDE) and was asked to write a program, my focus would be totally ruined, compared to my actual daily work.
Also this: "It’s funny how many people can’t edit text on any machine but their own." - I bought a notebook without properly checking the keyboard and even now after 3 years it still bugs me everytime I type. Nobody can understand how these things can really limit focus. If I got a different computer with different keyboard, different operating system, different text editor (not even an IDE) and was asked to write a program, my focus would be totally ruined, compared to my actual daily work.
I once interviewed in a code base I didn't know, using a language I didn't know (kotlin, so close to a language I do know, Java), in an editor I didn't know. I didn't get the job, but I don't believe it was because of my performance on the coding portion of the application (based on inference). But that was an error on my part. They offered to let me code a different problem on my own machine and I didn't take advantage, having a bit of overconfidence in my ability to pick up things quickly.
But I prefer to let applicants pick whatever language (within limits) and editor/ide they want for our current hiring process.
It's much more about how they solve a problem and navigate their tools (because that's an indicator too) than how they can use my stack.
But I prefer to let applicants pick whatever language (within limits) and editor/ide they want for our current hiring process.
It's much more about how they solve a problem and navigate their tools (because that's an indicator too) than how they can use my stack.
Exactly! How is it relevant to the job if the applicant is able to adapt to a new editor and new keyboard quickly? Even with a new computer, they will set it up once and then never do it again. Let the programmer chose whatever language, whatever carefully crafted settings in IDE that make them comfortable, to solve the problem effectively, because that's what matters. Problem solving is influenced heavily by these seemingly irrelevant details. It's like inspiration, you need a clear mind for that.
I’m glad one of my interviewers didn’t feel that way. I was about to start a pair programming session and they had an ergonomic split keyboard for me to use. I just asked for a regular keyboard, I purposefully didn’t explain why just to see what they would say. They had no problem finding me one.
After they gave me the keyboard, I told them that I can only type with one hand for physical reasons.
After they gave me the keyboard, I told them that I can only type with one hand for physical reasons.
Hmm. The point of an interview isn't for an applicant just to solve the problem, it's to prove they can solve the problem. I think saying "let me think about it for a moment" is perfectly acceptable. But going quiet without guiding the interviewer is not communicating what your plan is.
Not saying interviewing isn't broken in a myriad of ways, but asking a candidate to talk through their process to illuminate it isn't unreasonable.
Not saying interviewing isn't broken in a myriad of ways, but asking a candidate to talk through their process to illuminate it isn't unreasonable.
I have had such hard times with this. I find it very hard to think about the problem and to think what to say to this person without fucking up the interview.
I mean, you don't want to say: "I'm going to trial & error this shit while the fucking compiler builds and the stupid tests say it works" which is how must programming is done anyway.
I mean, you don't want to say: "I'm going to trial & error this shit while the fucking compiler builds and the stupid tests say it works" which is how must programming is done anyway.
I wouldn't use those exact words, no :).
But hopefully you have some ideas on what you want to try (and what your experience says you shouldn't, equally important) and talking about that thought process is exactly the kind of data I would want.
But hopefully you have some ideas on what you want to try (and what your experience says you shouldn't, equally important) and talking about that thought process is exactly the kind of data I would want.
> I find it very hard to think about the problem and to think what to say to this person without fucking up the interview.
It doesn't even take an interview, we've quit pair sessions because it's sometimes fucking impossible to focus on deep stuff with another person competing for your attention.
Shut up, go away, let me focus and solve this is a perfectly good approach in real work.
It doesn't even take an interview, we've quit pair sessions because it's sometimes fucking impossible to focus on deep stuff with another person competing for your attention.
Shut up, go away, let me focus and solve this is a perfectly good approach in real work.
> I think saying "let me think about it for a moment" is perfectly acceptable.
yes, you do, but many interviewers don't and that's the problem
yes, you do, but many interviewers don't and that's the problem
Ah, but then you have a great data point, no? If someone cuts you off when you are interviewing, how will they treat you when you are an employee?
The information flow goes both ways.
The information flow goes both ways.
These are usually agency interviewers or HR people. Sure, I'd definitely take that into account if this was interview with IT lead, but you don't get to that before going through this programming task with some HR guy. They will then pass your solution to some devs for assessment, because they don't understand it. But they are the gatekeepers.
Fair enough. I haven't run into that, probably because I interviewed with smaller companies. I have no tips on solving that problem.
Appreciated. I don't have a real solution either, that's why it's so infuriating. I just try to keep my skills up-to-date and my CV shiny to have more choices. Then I can at least pick what I like, and safely reject companies which have this silly way of interviewing, hoping they would learn. But looking at all the spam I'm getting on linkedin, it seems like I would run into such problem in 90% of the cases.
> The point of an interview isn't for an applicant just to solve the problem, it's to prove they can solve the problem.
Well if you solve it, then you've proved that you can solve it, right? So let people solve it the way they solve it when they're working for real. If that means sitting quietly and focusing on their screen, so be it.
Alternatively, the point of an interview is for the applicant to pretend they're bright and solving it on the spot while broadcasting how smart they are: https://news.ycombinator.com/item?id=17106291
Well if you solve it, then you've proved that you can solve it, right? So let people solve it the way they solve it when they're working for real. If that means sitting quietly and focusing on their screen, so be it.
Alternatively, the point of an interview is for the applicant to pretend they're bright and solving it on the spot while broadcasting how smart they are: https://news.ycombinator.com/item?id=17106291
> Well if you solve it, then you've proved that you can solve it, right?
Which gives you more data on how someone works and thinks?
1. Person silently sits for 15 minutes and then codes up a solution that meets the test criteria in another 15 minutes, typing quickly.
2. Person talks about the issues, tradeoffs and experiences while coding. They ask questions and engage in some discussion around the problem set. They end up with a partial solution after 30 minutes.
Of course those are hypothetical extremes, but it is clear to me which scenario gives the interviewer more information.
Which gives you more data on how someone works and thinks?
1. Person silently sits for 15 minutes and then codes up a solution that meets the test criteria in another 15 minutes, typing quickly.
2. Person talks about the issues, tradeoffs and experiences while coding. They ask questions and engage in some discussion around the problem set. They end up with a partial solution after 30 minutes.
Of course those are hypothetical extremes, but it is clear to me which scenario gives the interviewer more information.
I was interviewing a guy for IT position 6 years ago. After one of the questions, he went silent for a long period of time. It has not happened to me before. I did not think for a moment about interrupting him, it was obvious he is thinking how to approach the problem or his answer.
Interviewing people requires patience, cut down on caffeine before an interview
Actually, in an interview situation, "Let me think about that for a minute." followed by 120 seconds of silence, followed by a solid answer is a GREAT response.
That's different from when the candidate is asked a question and they literally just become silent, with a "deer in the headlights" expression.
That's different from when the candidate is asked a question and they literally just become silent, with a "deer in the headlights" expression.
Usually when you ask for a minute the guy says yes and then just continues rambling...
While I wouldn't consider that a "correct answer", I'd be willing to be patient and let them think about it for a minute or 2. I may look annoyed, or even pull out my phone and start browsing news, but it's not actually taking points away from them until it drags on too long.
Of course, there's not really a way to tell in advance if you get an interviewer like me, or a jerk that insists you know everything off the top of your head.
Of course, there's not really a way to tell in advance if you get an interviewer like me, or a jerk that insists you know everything off the top of your head.
> * I may look annoyed, or even pull out my phone and start browsing news*
If I, as an interviewer, ever did that I would:
a) expect the candidate to walk out, and
b) get told off by pretty much everyone in the company. Deservedly.
I really cannot think of a ruder way to express "you do not matter" sentiment than completely ignoring the candidate and flip through random stuff on my phone - while conducting an interview.
If I, as an interviewer, ever did that I would:
a) expect the candidate to walk out, and
b) get told off by pretty much everyone in the company. Deservedly.
I really cannot think of a ruder way to express "you do not matter" sentiment than completely ignoring the candidate and flip through random stuff on my phone - while conducting an interview.
When I interview people, and they get stuck on a programming problem like this, I tell them "it is completely acceptable for you to show me your Google fu to overcome this problem".
Google-fu is just as important a skill as knowing how to exit vi.
Google-fu is just as important a skill as knowing how to exit vi.
What's a fu?
It's like "kung fu" but for Google (or whatever). It's meant to imply mastery of some technique.
Well of cause you can think quietly about it, but you in an interview situation so you need to communicate that’s what your doing. Literally just saying “hmm, that should not happen, let me think about what’s going on” is all it takes.
Some people completely blank when they’re under examination like conditions. It doesn’t make them bad programmers.
No one is saying that, but companies are trying to create a accurate estimate of the applicants ability and blanking gets in the way of that, so they end up hiring someone who they are more certain about.
Sure, agreed. Except in very special circumstances (devrel, prod system admin, startup first hires) the ability to think clearly under pressure isn't key to success as a developer.
That's why I think that a paid take home test is the best way to understand how someone can program.
But the job of an interviewer is to get data any way they can, and the job of the interviewee is to provide that data as best they can. For the interviewee that means it is almost impossible to over communicate what you are thinking when faced with a problem. (I know, it's not easy to do, I have been there.) It's not natural or what you do when you are programming typically, but an interview is not a natural environment, nor should it be.
That's why I think that a paid take home test is the best way to understand how someone can program.
But the job of an interviewer is to get data any way they can, and the job of the interviewee is to provide that data as best they can. For the interviewee that means it is almost impossible to over communicate what you are thinking when faced with a problem. (I know, it's not easy to do, I have been there.) It's not natural or what you do when you are programming typically, but an interview is not a natural environment, nor should it be.
Interestingly, I've heard people say: if you can't code under pressure then you might not be a good fit here, to which my reply has always been:
If day to day coding in your company generates my interview level of anxiety and stress then you are 100% right that I would not be a good fit and you are doing me a favour by not hiring me.
The problem is that some people don't realise just how stressful interviews can be due to them not suffering that level of stress, anxiety etc. so it's difficult for them to see themselves in that position.
If day to day coding in your company generates my interview level of anxiety and stress then you are 100% right that I would not be a good fit and you are doing me a favour by not hiring me.
The problem is that some people don't realise just how stressful interviews can be due to them not suffering that level of stress, anxiety etc. so it's difficult for them to see themselves in that position.
I interviewed for the first time in years in 2018 and hell yes it is stressful.
I wish every hiring manager had that experience as it gave me a lot of empathy for candidates.
I wish every hiring manager had that experience as it gave me a lot of empathy for candidates.
> Except in very special circumstances (devrel, prod system admin, startup first hires) the ability to think clearly under pressure isn't key to success as a developer.
Even pressure comes in many forms. When your future and career is on the line and you're being judged by a bunch of strangers, it can feel very very adversarial. Instead of having the interviewer's trust, you have the anxiety that comes from the mere thought that they're looking out for all your mistakes and failures. They're doubting you, out to get you. (Even if they weren't, that's how many people often feel)
By contrast, you can have immense pressure in production when shit is on fire and you got a sudden unexpected hard deadline and your team & customer is relying on you. How this feels depends on many factors but it can definitely feel more like being a comrade in battle (and the hero of the day). It can even be energizing. Usually, you have the team's trust and support here. It might be stressful as heck, yet the total opposite of adversarial.
It's kind of a big deal. I would never want to work in an adversarial environment, I don't think it's healthy for anyone. But a bit of stress here and there can help maintain a good pace and make the work more satisfying.
Even pressure comes in many forms. When your future and career is on the line and you're being judged by a bunch of strangers, it can feel very very adversarial. Instead of having the interviewer's trust, you have the anxiety that comes from the mere thought that they're looking out for all your mistakes and failures. They're doubting you, out to get you. (Even if they weren't, that's how many people often feel)
By contrast, you can have immense pressure in production when shit is on fire and you got a sudden unexpected hard deadline and your team & customer is relying on you. How this feels depends on many factors but it can definitely feel more like being a comrade in battle (and the hero of the day). It can even be energizing. Usually, you have the team's trust and support here. It might be stressful as heck, yet the total opposite of adversarial.
It's kind of a big deal. I would never want to work in an adversarial environment, I don't think it's healthy for anyone. But a bit of stress here and there can help maintain a good pace and make the work more satisfying.
"I'll spend hours brushing up on Scheme just to test you on something completely irrelevant to the role just because I like playing Resumé Gotcha".
Yeah that's a thanks but no thanks from me. I wouldn't work for this guy in a thousand years.
Yeah that's a thanks but no thanks from me. I wouldn't work for this guy in a thousand years.
It's a good investment for the company, if the interviewer can red flag a candidate who is blatantly lying on his resumé because the candidate would assume no one would know said technology, it would save a lot of money from cutting ties with an employee in a later stage.
As an anecdote, I used to work for a company and would require candidates to know some Ruby, for one guy with several years experience in Python we changed the requirements of the home assignment so he could write it using whatever he wanted. he hands over a nodeJS application claiming he took the opportunity to learn something new(why not Ruby?), seemed like it was well done, so we bring him in for an interview, unlucky for him, there was one member in our team with some nodeJS experience(me), having reviewed the code, I asked him to do a minor feature addition to his own code, he froze, couldn't do it because he didn't write the code(copying from some repo) and didn't know any nodeJS at all, asked him to do it in Python instead and he still couldn't do it, he had just spiced up his resumé with tech we didn't use to see if he could weasel his way in.
As an anecdote, I used to work for a company and would require candidates to know some Ruby, for one guy with several years experience in Python we changed the requirements of the home assignment so he could write it using whatever he wanted. he hands over a nodeJS application claiming he took the opportunity to learn something new(why not Ruby?), seemed like it was well done, so we bring him in for an interview, unlucky for him, there was one member in our team with some nodeJS experience(me), having reviewed the code, I asked him to do a minor feature addition to his own code, he froze, couldn't do it because he didn't write the code(copying from some repo) and didn't know any nodeJS at all, asked him to do it in Python instead and he still couldn't do it, he had just spiced up his resumé with tech we didn't use to see if he could weasel his way in.
Yeah, bottom line, if you don't know an answer, then "I don't know" is always the right answer and the (ironically) most impressive answer. Plus you can always do things to mitigate, like talk about related or adjacent concepts a bit, state how you're willing to learn, maybe even take a guess at it. But if you bullshit you're either going to get caught, or, almost worse, get the job and feel like a fraud for months.
Always be hired or not hired for who you actually are!
Always be hired or not hired for who you actually are!
that's why i like live coding. i had candidates who were dumbfounded with something like elevatorsaga.com.
Imagine he got the role and did well. Trying to find the perfect person doesn't always work out as expected.
Yeah, but lying to that extent is a huge red flag, not just saying your Spanish is "mediocre" instead of "beginner".
What? The person in the example lied about two entire programming languages and couldn’t even touch them. That kind of person can destroy a team! I wouldn’t hire them either
I think the problem is that programmers have been taught to list every language and tech they have used on order to pass through HR. So, for example, when I was a student I wrote a ton of c# code. I’d be inclined to put that on a resume. But if they then asked me to code something in the language, it would certainly go poorly due to rust. Heck, I was a TA for a course where we taught lisp, but that doesn’t mean I can just start coding.
But if it’s listed as a job requirement, sure start quizzing.
But if it’s listed as a job requirement, sure start quizzing.
Agreed. But also I think a lot of job requirements list every programing language under the sun...so candidates just trying to match the resume screening algorithms.
I did C afor over a decade, I was really good at it. I haven’t used it in a decade. But, I left it off of my resume after an experience I had 4 years ago. I was applying for a C#/JavaScript job that didn’t have one line of C in the codebase, but one of the interviewers started asking me trivia about C. I happened to remember it, I got the job, but I learned my lesson.
You could also interpret as the interviewer making the effort to ask the candidate questions where they can shine.
I always try to start with a technical question where the candidate can make a good impression and get confident.
I always try to start with a technical question where the candidate can make a good impression and get confident.
You could, but sometimes the interviewer doesn't even know exactly why they are doing it.
First, it's a natural tendency. If you want to find if somebody "knows" a particular subject, an inexperienced person would start asking for factoids and interpret every incorrect answer as the proof that they don't really know the subject.
Second, many interviewers learn from other interviewers or just by trial and error, or from some courses, many of which have very dubious origins. There are many beliefs that are simply wrong, but still get circulated among interviewers, because nobody does 30 year careers in interviewing React programmers - wonder why...
First, it's a natural tendency. If you want to find if somebody "knows" a particular subject, an inexperienced person would start asking for factoids and interpret every incorrect answer as the proof that they don't really know the subject.
Second, many interviewers learn from other interviewers or just by trial and error, or from some courses, many of which have very dubious origins. There are many beliefs that are simply wrong, but still get circulated among interviewers, because nobody does 30 year careers in interviewing React programmers - wonder why...
- "Hey, I worked at FAANG or better, creating latest super-duper tech you use daily, was featured on TV, got multiple awards etc."
- "Let's see if you can do Fizz Buzz!"
- "Let's see if you can do Fizz Buzz!"
> - "Let's see if you can do Fizz Buzz!"
Yes, exactly. I'd like to verify that you can string a few lines of code together to solve a trivially simple problem. This is not an unreasonable ask, and I really don't care how impressive your CV is. If you can't solve fizzbuzz you're not going to be able to solve any of the much more complicated problems we wrestle with on a day to day basis.
Yes, exactly. I'd like to verify that you can string a few lines of code together to solve a trivially simple problem. This is not an unreasonable ask, and I really don't care how impressive your CV is. If you can't solve fizzbuzz you're not going to be able to solve any of the much more complicated problems we wrestle with on a day to day basis.
It's such a simple task, but in reality it's a fantastic way to weed out those that really don't have a clue what they're doing. Saves a lot of time interviewing.
Not at all. If the candidate can solve fizzbuzz but fails at more difficult coding challenges you won't hire him/her.
Therefore, the fizzbuzz test is not useful and it's offensive (or at least, boring) to any good candidate.
Therefore, the fizzbuzz test is not useful and it's offensive (or at least, boring) to any good candidate.
It's useful as a gatekeeper, to quickly weed out the chaff - I'm not saying it's the only test I do.
> it's offensive (or at least, boring) to any good candidate
Personally, I find this preposterous. When I get a CV, I don't know the person, and I need to decide if they are worth spending time on. FizzBuzz is a simple filter that I've found to be very effective the fact is that a lot of candidates just aren't up to even the most basic of tasks.
If being asked to do a dirt simple task that will take you less than 5 minutes offends you, then I don't want you on my team.
> it's offensive (or at least, boring) to any good candidate
Personally, I find this preposterous. When I get a CV, I don't know the person, and I need to decide if they are worth spending time on. FizzBuzz is a simple filter that I've found to be very effective the fact is that a lot of candidates just aren't up to even the most basic of tasks.
If being asked to do a dirt simple task that will take you less than 5 minutes offends you, then I don't want you on my team.
Imagine your candidate studied at best schools, worked at best companies, contributed to some popular open source projects, now you lucked out and for some reason she ended up interviewing for your team. You examine the CV, and decide "it's Fizz Buzz time!". Now what kind of reaction would you expect from the candidate, whose CV is screaming "I worked super hard to be able to handle the most difficult tasks with enormous responsibility, often life or death situations", and now she needs to "get down to the basics" or no job in your team :DDD What do you think will she tell to her network when they ask her why didn't she end up working for you?
That's a fair point, but I thought exceptional scenarios were implied and didn't think I needed to add a disclaimer - if I receive a CV from someone with a good OSS profile, that alone is enough to avoid silly tests. The whole point of FizzBuzz is to act as a crude filter - it's only employed where it's required (which for me is > 90% of CVs).
...unless the person you are interviewing decides you are childish, immediately walks away and doesn't respond to your mail ever again, and your business goes belly up as you can't find anyone on the market with the skills that person was bringing, essential to your business. Frankly, not sure why anyone competent in the current climate should take you seriously if you attempted that.
It's equivalent to asking a partner of another law company you want to join you what were the most important things that happened in 1753 and then rejecting them because they didn't know.
It's equivalent to asking a partner of another law company you want to join you what were the most important things that happened in 1753 and then rejecting them because they didn't know.
I mean honestly, Fizzbuzz is about the complexity you'll see in most of your day-to-day coding. So if you're too immature to go through with a task like that, then I'm afraid you're too immature to work here.
> ...unless the person you are interviewing decides you are childish, immediately walks away and doesn't respond to your mail ever again,
...in that case they just proved they were childish and I'd be happy to avoid working with them.
> and your business goes belly up as you can't find anyone on the market with the skills that person was bringing, essential to your business.
I think you are overestimating the value of childish ex-FAANGs :-)
If someone is too full of themselves to write a FizzBuzz once they are too full of themselves for a number of other tasks as well.
...in that case they just proved they were childish and I'd be happy to avoid working with them.
> and your business goes belly up as you can't find anyone on the market with the skills that person was bringing, essential to your business.
I think you are overestimating the value of childish ex-FAANGs :-)
If someone is too full of themselves to write a FizzBuzz once they are too full of themselves for a number of other tasks as well.
> If someone is too full of themselves to write a FizzBuzz once they are too full of themselves for a number of other tasks as well.
Agreed: and one of the related issues that's worth stating is the damage and demoralisation to your team(s) that's likely to result, were they hired.
Agreed: and one of the related issues that's worth stating is the damage and demoralisation to your team(s) that's likely to result, were they hired.
> unless the person you are interviewing decides you are childish, immediately walks away and doesn't respond to your mail ever again, and your business goes belly up as you can't find anyone on the market with the skills that person was bringing
Literally not sure of this was meant to be ironic?
Literally not sure of this was meant to be ironic?
Why? You mean showing right away reflection of your childish behavior so that you have some food for thought on how you appear and repel potential employees? :D
The idea of walking out and ghosting a company for daring to ask a (very) basic technical question before/during an interview seems very childish.
And the "imaginative" notion of a company going under because they dared to not hire you - a guru above all other, resplendent in technical magnificence - is, frankly, ridiculous.
And the "imaginative" notion of a company going under because they dared to not hire you - a guru above all other, resplendent in technical magnificence - is, frankly, ridiculous.
I worked with a guy that had FAANG on his resume, and we ended up letting him go because he couldn't actually do real programming for a device from that same company. He flailed for months to get simple things done, and failed.
Just having worked somewhere doesn't mean you actually did well there.
Just having worked somewhere doesn't mean you actually did well there.
Having worked at a FAANG, I can concur. Sure, some of the developers were world class. Some of them, though, had been there for years just kind of "lost in the sauce".
Well, if you are a good programmer then getting a Fizz Buzz on the interview is a jackpot no? It seems weird that half of the complaints about tech interviews is that they are too easy and the other half is that they are too tedious (I know that these are not mutually exclusive). The one alternative I see is to give one, really hard problem to people, but then the complaints about difficulty would come.
It's like telling the candidate "we are a bunch of idiots that don't appreciate your time, we are infantile and joyous about it, and in this place we don't really solve anything interesting as we have time for these stupid tasks."
I can feel the pain here but in my own way. As a hiring manager it must be so frustrating to be assaulted with massive idiocy when you are looking for a candidate. Think about it:
- candidates have zero penalty for applying to something they know they aren't qualified for
- there's constant noise about getting one of those well paying "tech jobs"
- everyone who has ever logged hello world to the console thinks they are the best programmer in the world
- people are desperate and will lie
- the ratio of unqualified to qualified candidates must be 100 to 1
It must be like dying of thirst in the middle of the ocean. The one thing I love about this, though, is the "senior developer" who hasn't read a book in a decade and has to get a new job. ahahahahaha. The moment when that mountain of BS collapses underneath them must be ga-lorious.
Also though, I get the feeling it's a different job market than it was in 2010. I'm still trying to understand what I think I see.
Languages seem to be able to cover multiple platforms now. Programming I don't think is as technical as it once was. At the same time everything seems to be a mess right now. Everything's broken. There's a million and a half frameworks for everything. ...It's like programming as a field has become much more broad, while simultaneously lowering in quality, with knowledge that was once spent on technical mastery now being traded for either lower wages or domain knowledge. So if you went to school and got a degree in programming that was once pretty impressive but now you're just some dude who can "code".
- candidates have zero penalty for applying to something they know they aren't qualified for
- there's constant noise about getting one of those well paying "tech jobs"
- everyone who has ever logged hello world to the console thinks they are the best programmer in the world
- people are desperate and will lie
- the ratio of unqualified to qualified candidates must be 100 to 1
It must be like dying of thirst in the middle of the ocean. The one thing I love about this, though, is the "senior developer" who hasn't read a book in a decade and has to get a new job. ahahahahaha. The moment when that mountain of BS collapses underneath them must be ga-lorious.
Also though, I get the feeling it's a different job market than it was in 2010. I'm still trying to understand what I think I see.
Languages seem to be able to cover multiple platforms now. Programming I don't think is as technical as it once was. At the same time everything seems to be a mess right now. Everything's broken. There's a million and a half frameworks for everything. ...It's like programming as a field has become much more broad, while simultaneously lowering in quality, with knowledge that was once spent on technical mastery now being traded for either lower wages or domain knowledge. So if you went to school and got a degree in programming that was once pretty impressive but now you're just some dude who can "code".
Most of this is good, but one real WTF:
"Editor Flailing
It’s funny how many people can’t edit text on any machine but their own. I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like. Most can barely navigate gedit, and it’s stupid simple.
Don’t ever let yourself get hung up on the editor. If you can’t figure out the magic command keys to indent code the way you like, just press the damn space bar and indent it yourself. Flailing in the editor wastes time."
Talk about an arbitrary condition. Sure, being adaptable and/or pragmatic with respect to tooling is a nice thing for your candidate to have, but to prioritize it at a similar level to knowing what your company does?! Are you really going to hire the incompetent-but-familiar-with-emacs Linux user over the capable-but-rigid Windows dev? Unless you're looking for an SA or full-stack dev, this seems rather arbitrary, especially considering the availability of plenty of cross-platform, fully-featured editors.
"Editor Flailing
It’s funny how many people can’t edit text on any machine but their own. I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like. Most can barely navigate gedit, and it’s stupid simple.
Don’t ever let yourself get hung up on the editor. If you can’t figure out the magic command keys to indent code the way you like, just press the damn space bar and indent it yourself. Flailing in the editor wastes time."
Talk about an arbitrary condition. Sure, being adaptable and/or pragmatic with respect to tooling is a nice thing for your candidate to have, but to prioritize it at a similar level to knowing what your company does?! Are you really going to hire the incompetent-but-familiar-with-emacs Linux user over the capable-but-rigid Windows dev? Unless you're looking for an SA or full-stack dev, this seems rather arbitrary, especially considering the availability of plenty of cross-platform, fully-featured editors.
I think thats what the article is trying to say with that second paragraph. Don't worry about how to use the editor the "right" way and just focus on the getting the code to work with whats available, which he pretty much confirmed in the third paragraph by mentioning how he hired someone who struggled with the editor but got the job done anyway.
I don’t know, I’ve found in my experience with some people that being only able to operate productively in a very particular setup is a real negative signal. And you’re giving the article a very inaccurate reading.
This is a great reason to learn vi for basic editing tasks. It's everywhere. Even if you typically use a different editor/ide, vi is a common ground.
Disclosure: I'm an emacs user
Disclosure: I'm an emacs user
It’s kind of weird to NOT know basic vi/vim if you get to a certain point in your career. If you can’t at least open the software, go into insert mode, and save/quit, have you ever had to ssh into a remote server and edit a config file before? Only excuse I could think of is if you literally did everything in windows for your entire career.
Yeap. Even the hard-core Emacs fanboys at my work know a few basic vi/vim commands. I mean, you're almost certainly going to use it at some point in your career, might as well learn "i -> type something -> :wq" at the very least.
Is it? There's plenty of amazing engineers and systems architects who develop (gasp!) on Windows and don't even use command line. And many many of those have designed highly reliable systems driving your basic infrastructure, power plants, industrial systems and myriad of other systems. Why on earth is knowing an old editor connected to anything useful you need from a person in a job?
Honestly I don't know a single good Windows guy that don't even use command line, there are basic things like ping, tracert, curl and openssl that you run in a command prompt. This is assuming you can get around using powershell.
Ping and tracert sure. But curl?
I’ll use Postman for quick sanity checking and I’ve never had a reason to use OpenSSL
What's wrong with using nano for that?
> It's everywhere.
It almost litterally is. Even busybox contains a vi clone. While I have encountered more systems without nano nor Emacs than I can remember. Plus, there is no excuse for learning the basic set of commands: i,ESC,x,u, and maybe navigating with the letters (which I'm not proficient at).
It almost litterally is. Even busybox contains a vi clone. While I have encountered more systems without nano nor Emacs than I can remember. Plus, there is no excuse for learning the basic set of commands: i,ESC,x,u, and maybe navigating with the letters (which I'm not proficient at).
I only have to edit a file on Linux once every couple of months of so - I tired of forgetting how to exit vi (or enter/exit edit mode, save the file... just about anything really), so started installing nano as the first thing I do on any system. Nano is so much more obvious than vi.
Most people can't install arbitrary software on every system they access.
This exactly. I am pretty sure that if you gain [adb] shell access inside of an android recovery partition (as a random example), you have read-only access to the system, with only busybox at your disposal. Thus vi, but no nano.
Also, there's a reason why there are so many "can't quit vi" memes.
Reading the comments about vi... Am I the only one that knows/uses ZZ to save and quit?
As I tend not quit vi that often compared to the time I spend inside, I prefer to use the more explicit version. I have made some mistakes in the past typing `^X-O` in nano instead of `^X-N` because of muscle memory, thereby overwriting a file I didn't want, and I am afraid of repeating this if `ZZ` became part of my muscle memory.
vi is enshrined in POSIX; nano isn't.
Been using Linux since the 90's and opening, editing and saving is exactly what I know in vi.
All that does is remind me that I haven't set nano as the default editor on that box and then I move on.
All that does is remind me that I haven't set nano as the default editor on that box and then I move on.
Knowing vi basics is useful, I agree. However, for interviews I really don't think that putting a candidate who is not familiar with it is a nice thing to do.
Any modeless editor should not cause trouble but vi (especially) is quite pernicious and the candidate would be just losing time.
Any modeless editor should not cause trouble but vi (especially) is quite pernicious and the candidate would be just losing time.
It's a very easy way to find the 0.5x engineer.
But I agree, it should not be a show stopper.
(Emacs and vscode user here)
But I agree, it should not be a show stopper.
(Emacs and vscode user here)
I believe todays programming field is vast enough that you can actually have a really good engineer that never needed to touch a command line editor. An iOS or android developer with 8 years of experience for example. Other front-end positions too.
I love vi and set it as editing mode everywhere, nevertheless I accept that it might not be something people actively seek. If I was looking for a unix server admin then I would definitely assume they know vi.
I love vi and set it as editing mode everywhere, nevertheless I accept that it might not be something people actively seek. If I was looking for a unix server admin then I would definitely assume they know vi.
Says a lot about googles recruiting standards you do know until recently "front end developers" were designers.
not for realy good Engineer in my book.
Why is "unix server administration in an environment that doesn't have other options" such a critical skill for all engineers? Or why else is vim experience required? Sure, many are going to have it, but it doesn't mean anything in itself.
I don’t consider vi to be a system admin tool only.
While I don’t think vi is a showstopper, it would certainly be curious how a mid to senior engineer wouldn’t know how to use insert and quit in vi. This would make me think that a Windows only background never even meant connecting to a shell and having to view a file.
I’ve experienced lots of app developers who only use an IDE and don’t know how code is deployed or runs so they’ve never debugged a deployment, ever. They are in a big enough environment where that’s someone else’s job and they never have to talk with them.
That’s perfectly cool and folks will make a living and retiring in that world. But I don’t typically hire too many of those because I work in cross functional teams where the windows devs have to at least be able to understand and communicate with the Linux devs, and vice versa. That means having basic user level skills like two commands in vi, because it is almost always available on Unix systems. And frequently the only one allowed.
I think folks confuse this as meaning that people who don’t know vi are dumb, they aren’t. They could be geniuses who just don’t need to know vi. But for many types of interviews, it’s a super easy screening question that makes me follow up with more questions if they answer “I have to google.” It would be similar if a developer didn’t know cd or had never seen notepad or something.
While I don’t think vi is a showstopper, it would certainly be curious how a mid to senior engineer wouldn’t know how to use insert and quit in vi. This would make me think that a Windows only background never even meant connecting to a shell and having to view a file.
I’ve experienced lots of app developers who only use an IDE and don’t know how code is deployed or runs so they’ve never debugged a deployment, ever. They are in a big enough environment where that’s someone else’s job and they never have to talk with them.
That’s perfectly cool and folks will make a living and retiring in that world. But I don’t typically hire too many of those because I work in cross functional teams where the windows devs have to at least be able to understand and communicate with the Linux devs, and vice versa. That means having basic user level skills like two commands in vi, because it is almost always available on Unix systems. And frequently the only one allowed.
I think folks confuse this as meaning that people who don’t know vi are dumb, they aren’t. They could be geniuses who just don’t need to know vi. But for many types of interviews, it’s a super easy screening question that makes me follow up with more questions if they answer “I have to google.” It would be similar if a developer didn’t know cd or had never seen notepad or something.
The comment I replied to said that a "really good" engineer has to know vi, that's what I was responding to, not "nearly all good engineers in my specific area will know vi", which is a lot more reasonable.
For a Linux desktop user, including devs, I wouldn't consider not knowing vi to be that odd, given that other editors commonly ship or are a single install command away. For someone not working on Linux, it's even less expected.
For a Linux desktop user, including devs, I wouldn't consider not knowing vi to be that odd, given that other editors commonly ship or are a single install command away. For someone not working on Linux, it's even less expected.
Right, I think a vast majority of “really good” engineers will know minimal vi skills.
My point is that you can be a perfectly nice programmer with a full career without being really good.
My point is that you can be a perfectly nice programmer with a full career without being really good.
I said really good for a reason and vi is used for other things than pure sysad work
The point is, a good engineer is always curious and as such has gathered a lot of knowledge about other fields. Maybe he is a unix server admin that writes iOS app on his own time just for fun? Maybe he is a data scientist that also enjoys UI design?
A bad engineer is happy that he has learned framework X and doesn't feel he needs to learn anything else.
Putting the Linux admin candidate in front of an xcode window is a quick and to find out where he stands. If he looks totally lost, he is definitely a 10x guy.
A bad engineer is happy that he has learned framework X and doesn't feel he needs to learn anything else.
Putting the Linux admin candidate in front of an xcode window is a quick and to find out where he stands. If he looks totally lost, he is definitely a 10x guy.
I agree, but my point is that today there are so many fields to be curious about that knowledge or not of vi is just one of them. There is no time to know about everything.
> Putting the Linux admin candidate in front of an xcode window is a quick and to find out where he stands. If he looks totally lost, he is definitely a 10x guy.
They are or they are not? Judging by the previous paragraph this sentence seems odd.
> Putting the Linux admin candidate in front of an xcode window is a quick and to find out where he stands. If he looks totally lost, he is definitely a 10x guy.
They are or they are not? Judging by the previous paragraph this sentence seems odd.
Sorry, I meant "is definitely not"
I think vi is the de-facto install of an editor on any non-Windows machine. You can't assume any other as vi in its simplest form is extremely lightweight and prevalent.
Pity I cant upvote you more than once, everyone who works on a unix system should know the basics of vi.
And I would argue that you could apply that to all programmers
And I would argue that you could apply that to all programmers
It's everywhere if you're on unix systems. Windows devs have little exposure to it.
> Talk about an arbitrary condition.
I've interviewed a lot of people in Amazon and always offered choice between at least 4 editors.
If you cannot pass a coding challenge the problem is not in the editor.
Did you read the next sentence? The Windows guy that chose to use vi was hired.
I've interviewed a lot of people in Amazon and always offered choice between at least 4 editors.
If you cannot pass a coding challenge the problem is not in the editor.
Did you read the next sentence? The Windows guy that chose to use vi was hired.
As someone spending a large amount of their week doing interviews these days, I really empathize with the spirit of this article. I've expressed an annoyance very similar to this one many times before - it's astounding how many nominally senior programmers are not adept at manipulating text.
If you've been writing a lot of software, I would expect you to be good at actually putting the characters into a file and moving them around therein. I would be very suspicious of someone who claimed to be a master carpenter but couldn't drive a nail cleanly. Muscle memory is a real thing, and the mechanics of a task matter. What is the point of all our fetishization of editors and keyboards and such if not to smooth the transition between brain and paper?
This isn't even always a matter of candidates operating in an unfamiliar environment. Even on their own personal computers, in the editor they presumably use for work, I see a lot of flailing.
If you've been writing a lot of software, I would expect you to be good at actually putting the characters into a file and moving them around therein. I would be very suspicious of someone who claimed to be a master carpenter but couldn't drive a nail cleanly. Muscle memory is a real thing, and the mechanics of a task matter. What is the point of all our fetishization of editors and keyboards and such if not to smooth the transition between brain and paper?
This isn't even always a matter of candidates operating in an unfamiliar environment. Even on their own personal computers, in the editor they presumably use for work, I see a lot of flailing.
This sounds like you're suffering from interview burn out to me. If you have a condescending voice towards interviewees outside interviews then it is usually a manifestation of how you perceive them in the interviews.
Do yourself and the candidates a favor and step back from it to allow yourself to lose such prejudices.
Do yourself and the candidates a favor and step back from it to allow yourself to lose such prejudices.
Letting a windows programmer use vi in an interview is just cruel. I mean, I like vim after months of practice, but just exiting vi(m) is notoriously hard for a newbie.
I'd agree if they were forced to use vi, but it seems like vi is just an option.
>I open gedit for them to use, with the offer that they can use any other Unix editor they like.
I wonder if he required using vi when that Windows programmer interviewed or if the Windows guy chose to use vi.
>I open gedit for them to use, with the offer that they can use any other Unix editor they like.
I wonder if he required using vi when that Windows programmer interviewed or if the Windows guy chose to use vi.
Being able to use vim at a basic level doesn't really take all that long to learn. Sure, there's the memes about vim being impossible to escape, but it's really not that hard to learn how to do so.
the cruel part is that it adds to the candidates nervousness. so i avoid that, but otherwise i agree, especially if it is a modern version where arrow keys and backspace work in insert mode, so one doesn't even need to use command mode to make corrections.
I learned vi by being too lazy to change my default editor in git..
Get them coding on a whiteboard, problem solved :)
A few more things:
1) Be humble. Don't expect people to take it easy on you because you got street cred (You are a ruby contributor? You still need to show them how good you are at coding Ruby). Many people with creds get offended when they realize they are not as good as their credentials would imply.
2) Know yourself. Most candidates I've seen, including myself, encounter a moment in the interview where they get hit by the nerves. Know that it's going to happen, announce it to the interviewer, recompose yourself, start again when calmer. You are not going to fail an interview because you are nervous. You will not succeed if you are terrified, panic, and shut up.
3) Explain your reasoning. The way you approach a problem, which is a large part of what the interviewer wants to see is in your mind only unless you vocalize it. With a good enough mental approach, you will get a lot of slack on the actual code by most interviewers.
4) Interview your interviewer. Go prepared with smart, non-trivial questions on the job and the company. Ensure your interviewer is an empathic, intelligent, and humble person. Assume anything annoying you experience is going to be relatively permanent at the job -- will that be acceptable or not?
1) Be humble. Don't expect people to take it easy on you because you got street cred (You are a ruby contributor? You still need to show them how good you are at coding Ruby). Many people with creds get offended when they realize they are not as good as their credentials would imply.
2) Know yourself. Most candidates I've seen, including myself, encounter a moment in the interview where they get hit by the nerves. Know that it's going to happen, announce it to the interviewer, recompose yourself, start again when calmer. You are not going to fail an interview because you are nervous. You will not succeed if you are terrified, panic, and shut up.
3) Explain your reasoning. The way you approach a problem, which is a large part of what the interviewer wants to see is in your mind only unless you vocalize it. With a good enough mental approach, you will get a lot of slack on the actual code by most interviewers.
4) Interview your interviewer. Go prepared with smart, non-trivial questions on the job and the company. Ensure your interviewer is an empathic, intelligent, and humble person. Assume anything annoying you experience is going to be relatively permanent at the job -- will that be acceptable or not?
#1 does not make always sense to me. Open-source authors and contributors have their work out in the open. You can see their work, the way they interact with others online. Would you reject Guido van Rossum if he can't solve your whiteboard problem? Assuming he's suited for the job, his work speaks for itself.
But that's exactly the thing - just because Guido did some project it doesn't automatically mean he has the skills for the job you're hiring for. Especially if you're interviewing people who aren't Guido (most of them aren't!) but are more local celebrity level contributor - being a contributor to something doesn't always give transferrable skills.
And people lie on their resumes all the time. It's amazing how many outright lies we've caught when interviewing people (even those with "streed cred").
And people lie on their resumes all the time. It's amazing how many outright lies we've caught when interviewing people (even those with "streed cred").
And just because someone solved (or didn't) a whiteboard puzzle doesn't mean they have (or don't have) the skills for the job you're hiring for. I would argue that actual working code out in the open speaks more than a puzzle solving session.
ad 1.) yes, being a contributor doesn't automatically make you good programmer. But having 7 years of coding practice in several companies kinda does, because why else would those companies have you for so long? Yet these programming interviews are required even for them. Probation period is much much more telling about a programmer than the 15 minute coding task.
> But having 7 years of coding practice in several companies kinda does, because why else would those companies have you for so long?
Several jobs in 7 years might very well imply several companies gave that person a chance and then gave up.
I often got questions about that years ago, and it was completely reasonable, at one point I'd worked in 4 different positions in 5 years. (There were good reasons for it and I had good references so I just explained it and it was OK, but I can easily see why they asked.)
Several jobs in 7 years might very well imply several companies gave that person a chance and then gave up.
I often got questions about that years ago, and it was completely reasonable, at one point I'd worked in 4 different positions in 5 years. (There were good reasons for it and I had good references so I just explained it and it was OK, but I can easily see why they asked.)
> gave that person a chance and then gave up.
Nobody "gives a chance" for a year. Either the problems were discovered during the probation period, or they were not as bad. Definitely not so bad that you'd have any chance discovering it during the interview. Besides, this high fluctuation is quite normal in IT.
Nobody "gives a chance" for a year. Either the problems were discovered during the probation period, or they were not as bad. Definitely not so bad that you'd have any chance discovering it during the interview. Besides, this high fluctuation is quite normal in IT.
That is simply not true in my experience. Its very hard to know if somebody is valuable within 6m unless they are completely bonk or completely great and majority of people is somewhere in between.
Most of the folks I personally ditched were working for company for about 1y. You still may not want to kick a person if he fails because you might recognize that he could be better at a different type of job (frontend -> automatic tests -> ci/cd ?). Notably, I didn't have success with this type of shifting so far but sample size is still small, maybe its just a failure bias. Nevertheless, in my mind this is the right thing to do, to offer another chance at something different, rather then kick people out on inability to adapt to particular problem space.
Most of the folks I personally ditched were working for company for about 1y. You still may not want to kick a person if he fails because you might recognize that he could be better at a different type of job (frontend -> automatic tests -> ci/cd ?). Notably, I didn't have success with this type of shifting so far but sample size is still small, maybe its just a failure bias. Nevertheless, in my mind this is the right thing to do, to offer another chance at something different, rather then kick people out on inability to adapt to particular problem space.
You'd be surprised. A common scenario is that manager A hires a bad employee but doesn't want to admit their mistake. Then they move on to another position and the new manager B has to go through the lengthy PIP and termination process.
Yes, but say 4 times in a row? And 3 times without discovering how bad the person is during the interview? That says something about the prediction power of an interview...
Agreed, but they are not alternatives, they are both possible. Also, I was not referring to super hard questions that require practicing "cracking the coding interview" for a month before passing. I've had "popular" candidates that could not shuffle an array, find a substring within a string or do some other relatively simple task that requires the candidate to think a bit.
The reality is that of course, people with seven years experience should not need to do such tests, but in practice, there are many candidates with such prerequisites that can't even code anything. How they get the seven years, is beyond me. All I know is that they can't code.
> I brought in a guy that hadn’t programmed professionally in years, in fact he didn’t even have programming on the first page of his resume. However, he had been practicing while looking for a job and he rocked my programming interview. He reasoned through the problem, wrote the code, it ran perfectly the first time. I hired him.
And yet, I have a computer science master with an 8.1 (equivalent to a 4.0 GPA) and companies like Spotify/Google won't even give me a chance to do an automated online coding test.
> One other thing: if I ask for a program sample ahead of an interview, don’t even think about sending in code that doesn’t include unit tests.
I haven't learned about testing in school or at my previous jobs or freelance gigs. Where's a good place to practice it? I mean, I know what assert does and all but I don't have a strong mentality to write a unit test, unless I'm writing code that is finicky like a Red Black tree, then I do write some tests.
I hate these snarky posts, because I don't even get to an interview. In all fairness, maybe I shouldn't apply to A-tier companies such as:
- Google
- Facebook
- Spotify
- Digital McKinsey (I did some business studies back in the day)
Shout out to Optiver and OpenAI for giving me a chance though. Optiver made me realize I needed to brush up on my algorithms in the first place. OpenAI made me realize that I need to brush up on my math.
And yet, I have a computer science master with an 8.1 (equivalent to a 4.0 GPA) and companies like Spotify/Google won't even give me a chance to do an automated online coding test.
> One other thing: if I ask for a program sample ahead of an interview, don’t even think about sending in code that doesn’t include unit tests.
I haven't learned about testing in school or at my previous jobs or freelance gigs. Where's a good place to practice it? I mean, I know what assert does and all but I don't have a strong mentality to write a unit test, unless I'm writing code that is finicky like a Red Black tree, then I do write some tests.
I hate these snarky posts, because I don't even get to an interview. In all fairness, maybe I shouldn't apply to A-tier companies such as:
- Spotify
- Digital McKinsey (I did some business studies back in the day)
Shout out to Optiver and OpenAI for giving me a chance though. Optiver made me realize I needed to brush up on my algorithms in the first place. OpenAI made me realize that I need to brush up on my math.
I was just in the rabbit hole in this guy’s posts about tech job strategy is worth reading - I started here https://haseebq.com/my-ten-rules-for-negotiating-a-job-offer...
but he covers a good amount of algo resources and writes well.
but he covers a good amount of algo resources and writes well.
I've written tests before, but there ain't no way I'm writing unit tests for a throw away coding exercise that used 4 hours of my time already.
> but there ain't no way I'm writing unit tests for a throw away coding exercise
I would, if whoever gave the exercise told me they want unit tests.
Not telling that, and then failing people for the lack of tests is fucking stupid imo. At that point it's just rejecting them for not having the right (secret) religion.
I would, if whoever gave the exercise told me they want unit tests.
Not telling that, and then failing people for the lack of tests is fucking stupid imo. At that point it's just rejecting them for not having the right (secret) religion.
usually for a coding challenge i include in the instructions to add unittests. ;)
since I consider the ability to write well designed unittests as crucial.
since I consider the ability to write well designed unittests as crucial.
Just writing a unit test for an existing code would actually tell a lot more about the applicant's skills than a coding interview with vi. Or a task like "here is 100 lines of code, there is a bug there, show me how would you look for it". I wish more companies were doing these kind of coding tasks. Instead, all we get where I come from is "write a simple todo list application in your free time".
> He reasoned through the problem, wrote the code, it ran perfectly the first time. I hired him.
I get the overall sentiment, but come on, "I hired him" sounds like self-absorbed anecdata - so this post is about how to quickly appeal to some manager dude on the interwebs? A more useful metric would be, did this hire survive the first two years, and what do the people around him have to say about his performance.
> It’s funny how many people can’t edit text on any machine but their own
How often does this person himself get thrown into random-ass editors and forced to quickly work through some rando algorithm while absolutely not forgetting to eloquently detail out loud their entire thought process? Self-absorbed, out of touch with how humans work.
I get the overall sentiment, but come on, "I hired him" sounds like self-absorbed anecdata - so this post is about how to quickly appeal to some manager dude on the interwebs? A more useful metric would be, did this hire survive the first two years, and what do the people around him have to say about his performance.
> It’s funny how many people can’t edit text on any machine but their own
How often does this person himself get thrown into random-ass editors and forced to quickly work through some rando algorithm while absolutely not forgetting to eloquently detail out loud their entire thought process? Self-absorbed, out of touch with how humans work.
Bullshit. It'll go like this:
Interviewer: here, a laptop with vi
Applicant: I've never used vi
Interviewer: just hit "i" to be dropped into insert mode, then just navigate with the arrows and use backspace like in any other editor. Ask me when you're ready to save and I'll teach you the magic incantation.
Applicant: types away
If you're not able to code in what's essentially just a test box then that's a useful thing for an interviewer to know. It's a strong indication that you don't fully grasp where the editor stops and the language begins, and unless you're applying for a junior role that's a negative sign.
Interviewer: here, a laptop with vi
Applicant: I've never used vi
Interviewer: just hit "i" to be dropped into insert mode, then just navigate with the arrows and use backspace like in any other editor. Ask me when you're ready to save and I'll teach you the magic incantation.
Applicant: types away
If you're not able to code in what's essentially just a test box then that's a useful thing for an interviewer to know. It's a strong indication that you don't fully grasp where the editor stops and the language begins, and unless you're applying for a junior role that's a negative sign.
just hit "i" to be dropped into insert mode, then just navigate with the arrows and use backspace like in any other editor.
Yeah maybe. The default vi config that comes with FreeBSD will get out of insert mode if you use the arrow keys to go beyond the end of the line (and maybe some other situations I've forgotten).
Editors are extremely personal, there's a pretty good reason that vi vs emacs is one of the eternal flame wars. I would absolutely expect a bit of discomfort and less proficiency with a different computer and a different keyboard. And, quite frankly, I'd be pretty put off by an interviewer who expected I'd hit the ground running with neither apprehension nor mistakes on someone else's computer.
Yeah maybe. The default vi config that comes with FreeBSD will get out of insert mode if you use the arrow keys to go beyond the end of the line (and maybe some other situations I've forgotten).
Editors are extremely personal, there's a pretty good reason that vi vs emacs is one of the eternal flame wars. I would absolutely expect a bit of discomfort and less proficiency with a different computer and a different keyboard. And, quite frankly, I'd be pretty put off by an interviewer who expected I'd hit the ground running with neither apprehension nor mistakes on someone else's computer.
> The default vi config that comes with FreeBSD will get out of insert mode if you use the arrow keys to go beyond the end of the line
No it doesn't.
No it doesn't.
No it doesn't.
I checked before I made the post on a FreeBSD 12 machine. The stock vi on OSX (vim 8) behaves more "normally".
I checked before I made the post on a FreeBSD 12 machine. The stock vi on OSX (vim 8) behaves more "normally".
I'm on FreeBSD 12 now. No it doesn't. And vim is not vi but vim doesn't do that either.
Dunno what to tell you. At a prompt, running vi and entering the following keys:
i a b c [right arrow] d e f
results in vi displaying the text:
ab
Note that the key f generates a bell as vi is no longer in insert/append mode.
If you're seeing different behavior I can only assume you've got wildly different terminal settings, you've configured vi and forgot about it, or have aliased vi to vim or some vi variant from ports.
Either way that lends credence to the idea that judging someone for being uncomfortable at a vi prompt is a bad way to interview candidates.
i a b c [right arrow] d e f
results in vi displaying the text:
ab
Note that the key f generates a bell as vi is no longer in insert/append mode.
If you're seeing different behavior I can only assume you've got wildly different terminal settings, you've configured vi and forgot about it, or have aliased vi to vim or some vi variant from ports.
Either way that lends credence to the idea that judging someone for being uncomfortable at a vi prompt is a bad way to interview candidates.
I have absolutely no vi knowledge. I just opened an ssh to a vanilla Ubuntu install (digital ocean droplet), tried what you wrote, and I got:
I'm super confused by your comment.
abcdef
I'm super confused by your comment.
I’ve programmed professionally for over 20 years gotten paid to program in more than a half a dozen languages and before that I learned how to program on an Apple //e by typing:
But if you insist on me using Vi, an editor I’ve never used and I get dinged for that, it tells me a lot about your company and I will move on to the other 6 or 7 interviews I have lined up. Your company is not that special.
CALL -151
!
But if you insist on me using Vi, an editor I’ve never used and I get dinged for that, it tells me a lot about your company and I will move on to the other 6 or 7 interviews I have lined up. Your company is not that special.
If the task was "write me a basic function that adds two numbers" then sure, editor doesn't matter, anyone with basic understanding of the language must absolutely be able to do that without google.
But that's not the task they use for interviews. It's gonna be something like one special scenario of an abstract academic problem that you will never encounter in a high traffic website project. You either shouldn't need to code it and the thought process should be enough for the purpose of the interview, or you need to think and focus really hard, and being constantly distracted by an editor that doesn't do what you expected, because you have a muscle memory for your own keyboard shortcuts totally ruins that.
The result is that your performance in this task has nothing in common with your performance in the job.
But that's not the task they use for interviews. It's gonna be something like one special scenario of an abstract academic problem that you will never encounter in a high traffic website project. You either shouldn't need to code it and the thought process should be enough for the purpose of the interview, or you need to think and focus really hard, and being constantly distracted by an editor that doesn't do what you expected, because you have a muscle memory for your own keyboard shortcuts totally ruins that.
The result is that your performance in this task has nothing in common with your performance in the job.
Walking into an interview, being given vi and told to write code would be a horrible experience.
Expecting someone to grasp a dramatically different editor with interview jitters is unfair. Frankly, that’s the kind of behaviour that would be a massive red flag for me - it would absolutely lead me to reject any position I was offered.
Expecting someone to grasp a dramatically different editor with interview jitters is unfair. Frankly, that’s the kind of behaviour that would be a massive red flag for me - it would absolutely lead me to reject any position I was offered.
Agree. I'm perfectly capable at vi and I'd probably just walk because it shows total arrogance on the interviewer's part.
Anecdotal - I use zsh, with the bureau theme - pretty obvious it's not just a bash shell. During a more operations-focused interview I had someone ask me if he could use bash because he wasn't very familiar with zsh and would like to work with a known tool. Super competent guy.
I thought it was a perfectly reasonable request.
Anecdotal - I use zsh, with the bureau theme - pretty obvious it's not just a bash shell. During a more operations-focused interview I had someone ask me if he could use bash because he wasn't very familiar with zsh and would like to work with a known tool. Super competent guy.
I thought it was a perfectly reasonable request.
Additionally vi is so configurable that one may be intimately familiar with their own vi configuration but really awkward with the stock (or interviewer's) configuration.
> Additionally vi is so configurable that one may be intimately familiar with their own vi configuration
Didn't even think of that - you could totally say the same about my Sublime editor =D
People are comfortable with their own tools and I don't like putting candidates into a corner with what they're using.
Didn't even think of that - you could totally say the same about my Sublime editor =D
People are comfortable with their own tools and I don't like putting candidates into a corner with what they're using.
> just hit "i" to be dropped into insert mode, then just navigate with the arrows and use backspace like in any other editor.
Yeah, no. Let me call bullshit on you calling bullshit.
I've been working as a mediocre programmer at the same company for the last 10 years. when I landed this job, I had never ever even heard of vi. I was "gently" introduced to it by my boss, and eventually got to kind of get used to a basic usage of it.
But in the box where our server run it is configured to highlight syntax, maintain tabs and shit, delete deletes, you can move using arrow keys, and a slew of other non default niceties.
Over the years I more or less got acquainted with different tastes of Linux, and used and installed it in a few of my own boxes (Debian, mostly).
Even thought vi respects arrow keys by default now it seems (thanks god I don't have to use hjkl. It is hjkl, right?) there's this conf issue that I've never been able to fix _because I don't know how to formulated the question in order to google it_ and it's the fact that when you're in non edit mode, _the cursor never goes to the end of the line_, so if I have to let's say add a new line, and the last word is `return;` I have to convert that to `return;;` put the line jump between the 2 ;; and then remove the extra ;. Plus, arrow keys in non edit mode add lines with crap in it.
I can't even fathom how stressfull would be doing a job interview under this circumstances.
Force a person to use a different OS than they are used to? Well, may be. Even thought I don't like nano, it would be a better choice than vi because at least it beheaves as a "normal" editor.
force a person to use vi with default settings? thank you very much for your time.
I've been working as a mediocre programmer at the same company for the last 10 years. when I landed this job, I had never ever even heard of vi. I was "gently" introduced to it by my boss, and eventually got to kind of get used to a basic usage of it.
But in the box where our server run it is configured to highlight syntax, maintain tabs and shit, delete deletes, you can move using arrow keys, and a slew of other non default niceties.
Over the years I more or less got acquainted with different tastes of Linux, and used and installed it in a few of my own boxes (Debian, mostly).
Even thought vi respects arrow keys by default now it seems (thanks god I don't have to use hjkl. It is hjkl, right?) there's this conf issue that I've never been able to fix _because I don't know how to formulated the question in order to google it_ and it's the fact that when you're in non edit mode, _the cursor never goes to the end of the line_, so if I have to let's say add a new line, and the last word is `return;` I have to convert that to `return;;` put the line jump between the 2 ;; and then remove the extra ;. Plus, arrow keys in non edit mode add lines with crap in it.
I can't even fathom how stressfull would be doing a job interview under this circumstances.
Force a person to use a different OS than they are used to? Well, may be. Even thought I don't like nano, it would be a better choice than vi because at least it beheaves as a "normal" editor.
force a person to use vi with default settings? thank you very much for your time.
I had your same problem for years (I use vi extremely sparingly) and the answer is “a” - which means “append”: it will go to the end of the line and leave you in insert mode after the last character.
Found out when I was looking for something else, and improved my quality of life quite a bit. (I still hate distributions where arrow keys in insert mode don’t work like any reasonable human would expect, but they are thankfully getting thinner on the ground).
Found out when I was looking for something else, and improved my quality of life quite a bit. (I still hate distributions where arrow keys in insert mode don’t work like any reasonable human would expect, but they are thankfully getting thinner on the ground).
Yep, well thanks for that. But imaging having a job interview, you are forced to use an editor you never in your life used and that _doesn't behave as a normal editor_ and you can't even inser a line _normally_.
Thanks, I always thought hitting $+i+right arrow was wrong!
In case you need to use more vim in your life: that's not actually a conf issue, it's just how the 'i'-key behaves. You can use 'a' to open insert mode after the current character, or to more directly get the effect you want, 'o' to create a new line after the current and put yourself in insert mode.
"I've never driven a semi before."
"NEXT! Obviously you just can't drive, your claim that you were a professional Formula 1 driver is a complete fabrication, and worse, you're clearly bone idle and don't want to learn anything new."
"NEXT! Obviously you just can't drive, your claim that you were a professional Formula 1 driver is a complete fabrication, and worse, you're clearly bone idle and don't want to learn anything new."
Have you seen some of the other comments in this thread? Seems like there's a good chance it would be more like:
Interviewer: here, a laptop with vi
Applicant: I've never used vi
Interviewer: ....
Interviewer: here, a laptop with vi
Applicant: I've never used vi
Interviewer: ....
Applicant: I prefer emacs
Interviewer: REPENT, SINNER!
Interviewer: REPENT, SINNER!
Eliminate My Application, Continue Searching
vi vi vi is the number of the DEviL!
When reading the article I was ready to accept some of practical advice, but lack of empathy makes me not want to listen to the author.
The value of an article does not come from the empathy of the author. For example, my physics manual was very cold describing the formula for acceleration, but I did not ignore it because of that.
Competence is not a Boolean, and hiring is not a physics problem.
If you don't understand why you're hiring people, and what specific skills, psychological mindset and attitude, and abilities you're looking for - not assumed, but rationally chosen, preferably with some peer input - then you'll be bad at it.
OP obviously wants waterfall programmers - give them a predigested problem of limited scope, set them loose, and pick up working code in $time_interval.
That's actually fine for some jobs, but it's going to be a disaster in other contexts.
If you don't understand why you're hiring people, and what specific skills, psychological mindset and attitude, and abilities you're looking for - not assumed, but rationally chosen, preferably with some peer input - then you'll be bad at it.
OP obviously wants waterfall programmers - give them a predigested problem of limited scope, set them loose, and pick up working code in $time_interval.
That's actually fine for some jobs, but it's going to be a disaster in other contexts.
At the top he wrote something about putting on a flame suit.
> how to quickly appeal to some manager dude
That is a great description of what an interview actually is. While your larger point is valid, you do have to get the job in the first place to have the opportunity to prove they were right to hire you. So you need to appeal to whomever you are talking to.
That is a great description of what an interview actually is. While your larger point is valid, you do have to get the job in the first place to have the opportunity to prove they were right to hire you. So you need to appeal to whomever you are talking to.
But the fact that it is being like that is the problem. It shouldn't be about who performs the most elaborate mating dance. This is a job and the performance of the project will be measurable and might have far-reaching consequences even for many people outside the company. None of the victims of the Equfax hack cares that the people on the job impressed their managers.
I agree, but I think the idea is “can they deal with the unexpected or new? How fast do they grok things” Which happens all the time with these new frameworks, tools, etc
The colleague who interviewed me later confided that i was the first he ever had who brought his own laptop for the interview. Apparently, it is not common!
Interesting, I brought my laptop to every interview for a software job I've had. Figured that's the best way for me to show and talk about some of my code, and maybe even code too if it comes to that.
Honestly, the guy has valid points, but he is probably an asshole I wouldn't want to work for. I appreciate getting valuable advice, but the tone doesn't have to be like this. Maybe he is mad because of the "bad candidates", but that is his job, so he should be able to handle it.
If you interview for Java or C# positions, editor matters. Give me an IDE. It'll take me hours to get the details right, because I'm used to the IDE fixing it
Oof, this is pretty antithetical to hiring. Author seems pretty frustrated. I hope this guy takes a long vacation. If I’m a candidate, I’d say this guy is clearly way overworked and I’d bail. Good points, but the volume of negative sadly speaks louder than the rationality of the points.
I see there being two parts to an SWE interview:
1) What experience does the candidate bring? Do they have compatible core competencies? If yes, then what’s novel about their experience—- will they help the team grok unknown unknowns? (And if the team’s burning issue is not unknown unknowns... then how does the candidate’s background add to the team’s creativity?)
2) How well does the candidate adapt on their feet? How effectively can they communicate? (If English is not a primary language, can they still get an idea across, perhaps using code instead of prose?). Can they code their way out of a paper bag?
The interview session is the interviewer’s responsibility to make the strongest case possible for the candidate. Let’s say that again: the interviewer needs to play doctor and adapt to the candidate. The interviewer is getting paid, not the candidate. Only once that sample has been taken properly can a hiring manager (who might very well be the interviewer..) begin to make an effective prediction as to how the candidate might do on the job.
Folks, demand for SWE jobs far outweighs supply. And it’s gonna be that way for at least another decade as universities catch up. It’s time to stop discriminating for the wrong reasons.
I see there being two parts to an SWE interview:
1) What experience does the candidate bring? Do they have compatible core competencies? If yes, then what’s novel about their experience—- will they help the team grok unknown unknowns? (And if the team’s burning issue is not unknown unknowns... then how does the candidate’s background add to the team’s creativity?)
2) How well does the candidate adapt on their feet? How effectively can they communicate? (If English is not a primary language, can they still get an idea across, perhaps using code instead of prose?). Can they code their way out of a paper bag?
The interview session is the interviewer’s responsibility to make the strongest case possible for the candidate. Let’s say that again: the interviewer needs to play doctor and adapt to the candidate. The interviewer is getting paid, not the candidate. Only once that sample has been taken properly can a hiring manager (who might very well be the interviewer..) begin to make an effective prediction as to how the candidate might do on the job.
Folks, demand for SWE jobs far outweighs supply. And it’s gonna be that way for at least another decade as universities catch up. It’s time to stop discriminating for the wrong reasons.
This is mostly agreeable, but you do need to actually test the competencies the candidate says they have.
As someone that's done aot of hiring, I can concur with the author that there are many poor candidates out there, many who grossly "stretch the truth" about their capabilities and experiences. Unless you want to be lumbered with a dud, some kind of practical test is a must.
> It’s time to stop discriminating for the wrong reasons
I wasn't sure what you meant was the discriminating factor here?
As someone that's done aot of hiring, I can concur with the author that there are many poor candidates out there, many who grossly "stretch the truth" about their capabilities and experiences. Unless you want to be lumbered with a dud, some kind of practical test is a must.
> It’s time to stop discriminating for the wrong reasons
I wasn't sure what you meant was the discriminating factor here?
So author, who are you? You start already with an authoritarian touch. What makes you believe you are not an incompetent interviewer? How can an applicant assess your skills, you could easily be the greatest fuck up in the company. Is your company really that cool that I should want to die to work there? Did you first weed out all the incompetent staff that is duck sitting there playing business politics?
IMAO most companies are not any better than the applicants applying. And no, you didn't hire only the best from all candidates, you just have a rich imagination that favours your ego.
IMAO most companies are not any better than the applicants applying. And no, you didn't hire only the best from all candidates, you just have a rich imagination that favours your ego.
the title should have the (2010) appended to it. And just judging by the website, the author is a 3d printing nerd with interest in weird keyboards and wrote a sudoku solver in 2012: https://github.com/joshcarter
And what makes him think that his company is so special that I would be willing to deal with his attitude at the interview let alone accept the job?
I’ve rejected plenty of offers because I didn’t like the interviewer.
I’ve rejected plenty of offers because I didn’t like the interviewer.
I once rejected a company because they had a big framed picture with 4 naked girls full frontal in the interviewing room. And because the manager pointed to it saying how "open minded" the company is.
The thing is that the candidate does not know if the interviewer falls into the pragmatic or dogmatic camp. I've absolutely had cases where the interviewers insisted that the applicant was proficient in a specific compiler toolchain + hardware debugger setup (for pretty generic embedded ARM where skills transfer nicely from other commerical ARM ecosystems), and cases where the interviewer gets hung up on coding style.
So, yes, I'll fiddle with the editor, because I'm not a fucking mind reader.
Besides, putting the candidate into gedit and then talking about debuggers is a bit inconsistent. If you put me into this situation, I'll of course use printf() debugging, whereas in a familiar environment I'd use the debugger.
So, yes, I'll fiddle with the editor, because I'm not a fucking mind reader.
Besides, putting the candidate into gedit and then talking about debuggers is a bit inconsistent. If you put me into this situation, I'll of course use printf() debugging, whereas in a familiar environment I'd use the debugger.
Dear Programming Job Recruiter,
If I get your job, you and I are going to share our lives together. We will spend a lot of time creating something new out of the ether, and it will be a rocky, adventurous ride for both of us. Hopefully, you will be worth working for. The job market is large - me coming to you means I'm interested in what you have to offer, too.
If I accept your offer to spend a sizeable portion of my life working for you, it will be because I evaluated your authority, calculated the effect that your snark will have on my life, and decided it was worth it.
Programming interviews are where I can see, for myself, just how ignorant you are of Putts Corollary. Don't know what that is? You just flunked the interview. Got some clue about it, and have designed the interview to test me on it, too? Great, we're going to be able to work together.
If I get your job, you and I are going to share our lives together. We will spend a lot of time creating something new out of the ether, and it will be a rocky, adventurous ride for both of us. Hopefully, you will be worth working for. The job market is large - me coming to you means I'm interested in what you have to offer, too.
If I accept your offer to spend a sizeable portion of my life working for you, it will be because I evaluated your authority, calculated the effect that your snark will have on my life, and decided it was worth it.
Programming interviews are where I can see, for myself, just how ignorant you are of Putts Corollary. Don't know what that is? You just flunked the interview. Got some clue about it, and have designed the interview to test me on it, too? Great, we're going to be able to work together.
> If you say you’re a master of network protocols, guess what, I’ve maintained a TCP/IP stack, and unless you’re really a master I’m going to bury you.
The goal of interviewing is never under any circumstances to "bury" someone with obscure, difficult questions. Even as the OP is obviously impressed with his own skill set ("I've maintained a TCP/IP stack") I'm sure someone coming from a different vantage point could stump him easily, there's too many nooks & crannies of a field that vast.
> I’ve interviewed several people that couldn’t write Fibonacci sequence. I’d tell them what it was and write on the whiteboard the first ten numbers so they could see it. They’d start typing and immediately go into the weeds.
There's a lot of pressure in the live format to produce right away. Maybe you should consider take-homes instead of instantly assuming the candidates lack your superior communication and abstract reasoning skills?
> Don’t make me point out cases where your code breaks.
Right. I'm sure you've never written a bug in your life -- especially as a C programmer.
> I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like.
I run Ubuntu desktop but why throw someone out of their comfort zone? Just ask them to bring a machine, or remote into a Google Hangout. The point of the interview is not to surprise candidates in unknown environments then feel superior because they don't know what you know.
> ...I ask if you’ve got questions for me, and you say, “so what does your company do?” the interview is over.
If it's cheapfurnaces.com, sure. But most companies it's not completely obvious what the company does exactly, even if you browse the company website or LinkedIn -- don't be so snide in your assumptions the candidates did no research on the company first, maybe they're just not articulate in their phrasing when asking what exactly a company does. They applied for a developer role, not to be CEO. This seems like an arrogant position to take.
> I’m not trying to beat up candidates because I’m a sadist, I’m looking for people I want to work with.
There's also a fair amount of chest-beating going on here, IMHO. The OP doesn't just want to assess the skill level of the candidates he simultaneously wants to assert his own perceived superiority ("most programming job applicants suck").
OP should consider acting more humble and try to demonstrate more empathy toward others -- often it's not the candidates "sucks" but his or her particular skill set or career level isn't ideally suited to the open role.
The goal of interviewing is never under any circumstances to "bury" someone with obscure, difficult questions. Even as the OP is obviously impressed with his own skill set ("I've maintained a TCP/IP stack") I'm sure someone coming from a different vantage point could stump him easily, there's too many nooks & crannies of a field that vast.
> I’ve interviewed several people that couldn’t write Fibonacci sequence. I’d tell them what it was and write on the whiteboard the first ten numbers so they could see it. They’d start typing and immediately go into the weeds.
There's a lot of pressure in the live format to produce right away. Maybe you should consider take-homes instead of instantly assuming the candidates lack your superior communication and abstract reasoning skills?
> Don’t make me point out cases where your code breaks.
Right. I'm sure you've never written a bug in your life -- especially as a C programmer.
> I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like.
I run Ubuntu desktop but why throw someone out of their comfort zone? Just ask them to bring a machine, or remote into a Google Hangout. The point of the interview is not to surprise candidates in unknown environments then feel superior because they don't know what you know.
> ...I ask if you’ve got questions for me, and you say, “so what does your company do?” the interview is over.
If it's cheapfurnaces.com, sure. But most companies it's not completely obvious what the company does exactly, even if you browse the company website or LinkedIn -- don't be so snide in your assumptions the candidates did no research on the company first, maybe they're just not articulate in their phrasing when asking what exactly a company does. They applied for a developer role, not to be CEO. This seems like an arrogant position to take.
> I’m not trying to beat up candidates because I’m a sadist, I’m looking for people I want to work with.
There's also a fair amount of chest-beating going on here, IMHO. The OP doesn't just want to assess the skill level of the candidates he simultaneously wants to assert his own perceived superiority ("most programming job applicants suck").
OP should consider acting more humble and try to demonstrate more empathy toward others -- often it's not the candidates "sucks" but his or her particular skill set or career level isn't ideally suited to the open role.
Exactly, it sounds like this guy sees interviews as a way to feed his ego and make himself feel smarter than the candidate.
He would be a massive red flag to me as an indicator I don't want to work there.
He would be a massive red flag to me as an indicator I don't want to work there.
Definitely a solid pass on a job here.
Something I don’t see enough of is developers who have a lot of recent interview experience (as an interviewee) being the interviewer. These devs are inevitably contractors so they are rarely chosen to be the interviewer in a company. Rather, the team lead who has been there for years is chosen. The thing is, as a person who has a lot of experience at being interviewed, I know the mistakes that interviewers make and they never get to learn this information. An candidate gets to correct their mistakes and become better at the interview process in preparation for the next one they do. An interviewer learns, 3 months down the line, that they have made some mistake but never learn what went wrong.
Here are some common mistakes that interviewers make:
1. Not testing the candidate’s argumentative skills. The interviewer should take a questionable stance on a topic and see how the candidate argues their point.
2. Never testing a candidate’s ability to read and understand code. Without this skill a candidate is more likely to reject your team’s existing code base and rewrite things from scratch. Instead of asking them to implement an algorithm (which, btw, they already may have practice doing - making the test pointless) get them to read a lot of regular code. Not a complex algorithm but something that spans multiple files and is quite large. It could be your codebase or something you found on GitHub. “Tell me what this does” “Tell me what you think is wrong with this code” “How would you change it?”. Being able to read code and write it are two separate skills and both need to be tested in the interview.
3. Making the candidate feel uncomfortable. For example, two interviewers against one candidate could make certain devs uncomfortable. Why is this important? A developer is going to get settled in the team at some point and feel comfortable. Wouldn’t you rather test them in that state rather than a state they would rarely be in? Unfamiliar text editors, interviewers watching you code; these are further examples. Sure, some devs are unfazed but others are, and they may be good devs that an interviewer is chucking away.
3. The interview should always involve a tech test and I strongly believe that the candidate should be left alone to do the test. However, this depends on how pair-programmer heavy the team is. Regardless, the most important part comes later when going through the results. So many interviewers miss the opportunity to question the interviewee on what they have written. It can be quite distracting if the interviewer is constantly picking through the code as it is being written.
4. Not going through the candidates cv during the interview. This should happen first and is part of the prep that an interviewer should make. As boring and full of exaggerations as other people’s CVs sometimes are, it is a good way to increase the confidence of the candidate so that the interviewer can get the most out of them for the rest of the interview.
Here are some common mistakes that interviewers make:
1. Not testing the candidate’s argumentative skills. The interviewer should take a questionable stance on a topic and see how the candidate argues their point.
2. Never testing a candidate’s ability to read and understand code. Without this skill a candidate is more likely to reject your team’s existing code base and rewrite things from scratch. Instead of asking them to implement an algorithm (which, btw, they already may have practice doing - making the test pointless) get them to read a lot of regular code. Not a complex algorithm but something that spans multiple files and is quite large. It could be your codebase or something you found on GitHub. “Tell me what this does” “Tell me what you think is wrong with this code” “How would you change it?”. Being able to read code and write it are two separate skills and both need to be tested in the interview.
3. Making the candidate feel uncomfortable. For example, two interviewers against one candidate could make certain devs uncomfortable. Why is this important? A developer is going to get settled in the team at some point and feel comfortable. Wouldn’t you rather test them in that state rather than a state they would rarely be in? Unfamiliar text editors, interviewers watching you code; these are further examples. Sure, some devs are unfazed but others are, and they may be good devs that an interviewer is chucking away.
3. The interview should always involve a tech test and I strongly believe that the candidate should be left alone to do the test. However, this depends on how pair-programmer heavy the team is. Regardless, the most important part comes later when going through the results. So many interviewers miss the opportunity to question the interviewee on what they have written. It can be quite distracting if the interviewer is constantly picking through the code as it is being written.
4. Not going through the candidates cv during the interview. This should happen first and is part of the prep that an interviewer should make. As boring and full of exaggerations as other people’s CVs sometimes are, it is a good way to increase the confidence of the candidate so that the interviewer can get the most out of them for the rest of the interview.
Looks like the author favours candidates that are able to adapt to his hiring process.
I think this approach results in too many false negatives. I prefer adapting my hiring process, asking questions and/or helping.
I feel that this makes it easier for the candidate to demonstrate their skills. Staying humble helps too.
EDIT: it’s possible that this article doesn’t represent author’s current opinion; we should add „(2010)” to the title.
I think this approach results in too many false negatives. I prefer adapting my hiring process, asking questions and/or helping.
I feel that this makes it easier for the candidate to demonstrate their skills. Staying humble helps too.
EDIT: it’s possible that this article doesn’t represent author’s current opinion; we should add „(2010)” to the title.
> It’s funny how many people can’t edit text on any machine but their own. I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like. Most can barely navigate gedit, and it’s stupid simple.
No, it's not funny. Accessibility is important, what if, for example, the person is used to a different keyboard layout?
I would always encourage people to use their own machine and setup. If a programmer is uncomfortable on a different machine that might just stress them out and ruin the interview.
Also, you could be missing out on some hidden skills. I could show off some ninja moves in sublime text or emacs, or in my customised shell, but I'm pretty sure I'd suck on a fresh ubuntu in Gedit.
I agree that most programmers should be able to ssh into a server and edit a file without any issue, but that's different from completing a programming task. It's like testing if a tennis player can ace a serve with a golf club.
No, it's not funny. Accessibility is important, what if, for example, the person is used to a different keyboard layout?
I would always encourage people to use their own machine and setup. If a programmer is uncomfortable on a different machine that might just stress them out and ruin the interview.
Also, you could be missing out on some hidden skills. I could show off some ninja moves in sublime text or emacs, or in my customised shell, but I'm pretty sure I'd suck on a fresh ubuntu in Gedit.
I agree that most programmers should be able to ssh into a server and edit a file without any issue, but that's different from completing a programming task. It's like testing if a tennis player can ace a serve with a golf club.
This is why I bring my split ergonomic keyboard with dvorak firmware to on-site interviews.
> if you say you’re a master of network protocols, guess what, I’ve maintained a TCP/IP stack, and unless you’re really a master I’m going to bury you.
yep. :) all lot of applicants should take a note at this.
yep. :) all lot of applicants should take a note at this.
I'd bet 10 bucks this guys built one shitty ass team of people and I'm not even talking about their programming skills. He's so caught up in being cheeky and a dick he shows how unskilled he is at building an actual performant cohesive team that works well together. He's not building a team of robots, well maybe he is. I'd bet another 10 bucks his salary/hourly rates are also sub-market.
TFW Dwight Shrute is your programming job interviewer...
Programming _is_ like riding a bike...after a brief reimmersion. Maybe a little wobbly at first, but it's never taken me long to jump back into something that used to be an old friend.
[deleted]
This guy seems like the kind of interviewer to quiz you on how to type-cast a binary-void floating function-function pointer array to a U64_INT_WIDE TCHAR and then fail you for not using the right number of spaces in your code. Lmaoo. Would not work with / 10.
> I’ll brush up on Scheme myself just so I can give you a Scheme programming question.
That's when I realised the author was quite obviously lying.
That's when I realised the author was quite obviously lying.
Summary: if you don't know little thing X for sure you can't do Y! now and forever! because Y can no longer be learned!
"you can’t program anymore" and forever?
"can’t edit text on any machine" and forever?
"can’t figure out the magic command keys to indent code" and forever?
He sees the developer as having static knowledge that somehow, in the very moment of the interview, becomes frozen in time and nothing can be done about it.
I should copy/paste this article and change the name "How not to hire -the best-"
"you can’t program anymore" and forever?
"can’t edit text on any machine" and forever?
"can’t figure out the magic command keys to indent code" and forever?
He sees the developer as having static knowledge that somehow, in the very moment of the interview, becomes frozen in time and nothing can be done about it.
I should copy/paste this article and change the name "How not to hire -the best-"
Oh, after they complain about everything that is not really important, they spend 2 weeks to create a user/pass for you and months to learn the project because the senior left.
"if you haven’t been programming for a while, you can’t program anymore."
I do not agree with this at all. For a person who has a proper understanding of how a computers works from the basics, getting up to speed on any language and paradigm might take a short time but telling a person they cannot program anymore is complete BS.
Ok, object oriented environments are now more common but so what; they were invented 50 years ago and most of us have had some exposure to them at least on a general level.
So telling us we can't program anymore because we cannot pick up your laptop and your editor and toss out a program in five minutes is not a test of the person, but more designed to make the tester feel superior.
I am happy that I do not have to interview with Josh Carter.
I do not agree with this at all. For a person who has a proper understanding of how a computers works from the basics, getting up to speed on any language and paradigm might take a short time but telling a person they cannot program anymore is complete BS.
Ok, object oriented environments are now more common but so what; they were invented 50 years ago and most of us have had some exposure to them at least on a general level.
So telling us we can't program anymore because we cannot pick up your laptop and your editor and toss out a program in five minutes is not a test of the person, but more designed to make the tester feel superior.
I am happy that I do not have to interview with Josh Carter.
He doesn't mean that you don't know the JavaScript framework of the week.
He means if you have not been writing any code regularly recently (because you have been a Manager or Architect or whatever) then your programming skills will be rusty. You will struggle with FizzBuzz because you have have spent less than 5 hours programming in the last 12 months.
He means if you have not been writing any code regularly recently (because you have been a Manager or Architect or whatever) then your programming skills will be rusty. You will struggle with FizzBuzz because you have have spent less than 5 hours programming in the last 12 months.
The article was okay to read but calling people out for not being able to use an editor you know how to use is low.
This interviewer seems to have a machoistic view of interviewing people. At all times you should be treating people with dignity and respect, not trying to nail them to the ground to see them flounder.
Interviewing people by waiting around while they plod away at a text editor isn't appropriate use of your or the candidates time. You should be interacting with the individual via talking to them. If they claim to be an expert in TCP/IP then you can peel back the layers back asking open-ended questions to see where the conversation goes. If they have the depth of expertise then it'll become pretty apparent when you discuss the intricacies of the topic.
Trying to trip somebody up with returning int V long is just redundant. That is an mistake to make and will be trapped by the compiler at compile time.
To interviewers I say stop wasting everybody's time and focus on discussion not exam style questions.
Interviewing people by waiting around while they plod away at a text editor isn't appropriate use of your or the candidates time. You should be interacting with the individual via talking to them. If they claim to be an expert in TCP/IP then you can peel back the layers back asking open-ended questions to see where the conversation goes. If they have the depth of expertise then it'll become pretty apparent when you discuss the intricacies of the topic.
Trying to trip somebody up with returning int V long is just redundant. That is an mistake to make and will be trapped by the compiler at compile time.
To interviewers I say stop wasting everybody's time and focus on discussion not exam style questions.
> it’s worth a few hours of my time to prepare for an interview
So, how many interviews he did in one week? 1 or even 0.5? Today typical manager with 2-3 open positions performs no less than 3 interviews a week. I personally will not spend all my time learning some irrelevant languages or frameworks just to show off in front of random people passed through HR screening.