Coding Interview Tips(interviewcake.com)
interviewcake.com
Coding Interview Tips
http://www.interviewcake.com/tips-and-tricks
27 comments
I agree that the summation solution is an "aha" moment. But I don't think a reasonable interviewer would require someone to get that answer, and I can see how this problem could showcase a candidate's thought process and ability to reach incremental solutions.
For example, a naive approach is to sort and find the element where arr[n] == arr[n+1]. From here, the interviewer can see if the candidate is aware that most sorts are O(nlogn). A better candidate knows that with a fixed range, you can sort in O(n). Maybe the candidate will go with a hash table or set and check for the duplicate that way. I've interviewed people who look good on paper but don't intuitively grasp how to use hash tables, so this is a useful screening exercise.
My point is not that this question isn't simple, it's just that there are a number of ways to approach it besides the "aha" moment that give you insight into how a candidate works.
For example, a naive approach is to sort and find the element where arr[n] == arr[n+1]. From here, the interviewer can see if the candidate is aware that most sorts are O(nlogn). A better candidate knows that with a fixed range, you can sort in O(n). Maybe the candidate will go with a hash table or set and check for the duplicate that way. I've interviewed people who look good on paper but don't intuitively grasp how to use hash tables, so this is a useful screening exercise.
My point is not that this question isn't simple, it's just that there are a number of ways to approach it besides the "aha" moment that give you insight into how a candidate works.
I see what you are saying. I was initially thinking about using dynamic programming, and surely I could illustrate my chops (or not) in that regard. But what if I do have that 'aha' moment, or I just remember that trick? Now you are not measuring my ability to think about these things on my feet, but either get no info (if I just regurgitate the answer), or get to evaluate my acting skills if I decide to pretend to 'figure it out'. And still, none of those, whichever way it goes, really answer how I do in production. I have come across plenty of really 'puzzle' clever people that cannot really pull together working code for a complex problem, and those (like me) who are just terrible at them, but really deliver (ignore that I'm patting myself on the back here, that's not the point, it's just a data point I know well). For example, I am terrible at chess. I'll move a piece into a lane where they can be attacked with impunity. The same goes with computers. Plenty of times I'll miss something obvious, for a short time (like the length of an interview). But I compensate for that with things like unit tests, thinking in the shower and then coding at work, and so on. Take it on faith that it works and I produce.
For example, let's say I need to hire somebody to do a lot of low level optimizations. I can ask them some specific problem, and keep saying 'make it faster'. Or, I could start talking to them about cache misses, and see if we can just talk about it. Anyone that can actually do the work will be bringing up the pipelines, out of order instruction executions, the costs of going off chip, how to organize data and programs to minimize cache misses, well, the whole ball of wax. In that context I can start feeling out if they are original thinkers, or just plodding followers of some rules they read on HN or somewhere. If they don't have experience in this, but I think they might be good at it, I can talk about their debugging skills, or some other engineering/optimization problem that they have solved. I'll admit that this all presupposes an existing career - I do find it harder to interview and evaluate recent grads because it is all speculation at that point. Heck, if all you have done is CRUD apps I can see if you have thought about the good/clean code vs put it together to get it out the door to get market share issues. There is no one, clear, obvious answer, and a good mind will see that, and be able to free associate about it. A mediocre mind will repeat whatever HN quote resonated with them when they read it. If you can think about that clearly, you can learn the micro-architecture and then use the same style of thinking to optimize code.
So, all of that is why I don't like 'aha' questions, or even reverse the string questions. I don't think it has any predictive value. Certainly, Google, which asks tough algorithmic questions, admits that with all their collected data they see no correlation between interviews and performance, except for the situational type interview stuff I write about (and that the OP wrote about).
For example, let's say I need to hire somebody to do a lot of low level optimizations. I can ask them some specific problem, and keep saying 'make it faster'. Or, I could start talking to them about cache misses, and see if we can just talk about it. Anyone that can actually do the work will be bringing up the pipelines, out of order instruction executions, the costs of going off chip, how to organize data and programs to minimize cache misses, well, the whole ball of wax. In that context I can start feeling out if they are original thinkers, or just plodding followers of some rules they read on HN or somewhere. If they don't have experience in this, but I think they might be good at it, I can talk about their debugging skills, or some other engineering/optimization problem that they have solved. I'll admit that this all presupposes an existing career - I do find it harder to interview and evaluate recent grads because it is all speculation at that point. Heck, if all you have done is CRUD apps I can see if you have thought about the good/clean code vs put it together to get it out the door to get market share issues. There is no one, clear, obvious answer, and a good mind will see that, and be able to free associate about it. A mediocre mind will repeat whatever HN quote resonated with them when they read it. If you can think about that clearly, you can learn the micro-architecture and then use the same style of thinking to optimize code.
So, all of that is why I don't like 'aha' questions, or even reverse the string questions. I don't think it has any predictive value. Certainly, Google, which asks tough algorithmic questions, admits that with all their collected data they see no correlation between interviews and performance, except for the situational type interview stuff I write about (and that the OP wrote about).
Asking this question in a real interview, if the candidate missed the summation approach and used an array to keep counts, I'd simply say "That sounds good. What if we were really worried about memory use? Could we do it with less memory?"
This is what it's supposed to feel like when Interview Cake offers the "gotcha" that we can solve the problem with O(1) additional memory after you say you have an answer, before showing you the final solution. In real life I wouldn't fault the candidate for needing the nudge.
Another flow I've considered is to make the question multi-part, with the second part (the "follow-up" question) adding the O(1) time constraint. I'm worried that with this flow, in the case where you do jump right to the summation approach, the app will feel naive because it will pose a whole new question that you've already answered.
So far I think the best approach is to keep the current flow but use a less harsh word than "gotcha." What do you think? Do you still think the question is just fundamentally too much of an "aha"?
(I agree that if the candidate jumped right to the summation answer on this one it's a weak signal. I wouldn't ask this question in an interview--it's not my favorite either, and it's unfortunate that it's a common one. My favorites aren't on the site yet because they're hard to explain without pictures. Adding those pictures is the next project!)
This is what it's supposed to feel like when Interview Cake offers the "gotcha" that we can solve the problem with O(1) additional memory after you say you have an answer, before showing you the final solution. In real life I wouldn't fault the candidate for needing the nudge.
Another flow I've considered is to make the question multi-part, with the second part (the "follow-up" question) adding the O(1) time constraint. I'm worried that with this flow, in the case where you do jump right to the summation approach, the app will feel naive because it will pose a whole new question that you've already answered.
So far I think the best approach is to keep the current flow but use a less harsh word than "gotcha." What do you think? Do you still think the question is just fundamentally too much of an "aha"?
(I agree that if the candidate jumped right to the summation answer on this one it's a weak signal. I wouldn't ask this question in an interview--it's not my favorite either, and it's unfortunate that it's a common one. My favorites aren't on the site yet because they're hard to explain without pictures. Adding those pictures is the next project!)
Nitpicking because this tripped me up: You can do this in-place and in O(n) time by repeatedly partitioning the array in half (by value) and discarding the smaller half. I'd have needed a hint that you can do it in one pass to have noticed the summation approach.
[deleted]
As an interviewer, I'm far more interested in soft skills than hard skills. I just want to know that they can actually program, which I can usually tell by how they talk about accomplishments in the face of some probing detail questions. Good programmers want to take a difficult problem, shoot it, mount its head on the wall like a set of antlers, and brag about it to anyone who will tolerate that. So competence shines through without a lot of tech question grilling.
Soft skills, on the other hand... is this person an asshole? Inflexible and dogmatic? Timid? Boring? That stuff drags down a whole team.
Soft skills, on the other hand... is this person an asshole? Inflexible and dogmatic? Timid? Boring? That stuff drags down a whole team.
>Timid? Boring? That stuff drags down a whole team.
The previous 3 I get, but these two? Maybe we should be interviewing for the ability to get work done without being affected by other people?
The previous 3 I get, but these two? Maybe we should be interviewing for the ability to get work done without being affected by other people?
Timid people get overrun by dominant people, and the kind of aspie cluelessness that runs through so many programmers (and I have no problem with that). So timid programmers often wind up unhappy and unwilling to talk about being unhappy, and the value of their ideas and opinions is lost. That's a loss to the team.
Boring people? Hell, I just don't want to work with them. If I have a say in hiring someone I'm going to spend hours a day around, I'm going to do my best to make sure it's someone I find entertaining.
Boring people? Hell, I just don't want to work with them. If I have a say in hiring someone I'm going to spend hours a day around, I'm going to do my best to make sure it's someone I find entertaining.
If we met for the first time and you were in an authoritative position (interviewer) I'd probably come off as timid because I'm reserved around new people, but once I get to know the person/environment and get a good sense of my limits/role/status I have no problem voicing opinions or dealing with assertive people. Just because I might seem timid initially doesn't mean I'm a pushover, and I don't think I'm the only one like this.
I'm pretty good at getting timid people to come out of their shell (I actually like a lot of timid people). But it's not usually their interactions with me I'm worried about - it's their interactions with the rest of the team.
> Boring people? Hell, I just don't want to work with them. If I have a say in hiring someone I'm going to spend hours a day around, I'm going to do my best to make sure it's someone I find entertaining.
What the fuck, man? Are you trying to hire professionals to do a job or are you treating hiring as some sort of fucked up way of making friends?
What the fuck, man? Are you trying to hire professionals to do a job or are you treating hiring as some sort of fucked up way of making friends?
I don't know about you, but I spend approximately one third of my awake time at work. One third of my conscious life. I'm going to make sure that I enjoy that time, and having enticing colleagues has a lot to do with that in my experience.
There are tons of interesting, very professional people around. There's no need to stick with the boring ones you find along the way, so yes, I would also avoid them.
There are tons of interesting, very professional people around. There's no need to stick with the boring ones you find along the way, so yes, I would also avoid them.
If there's a glut of otherwise equally qualified people, sure. Is that the case with programmers?
An otherwise boring guy who goes home to his family and spends his weekends working on his house and watching football might get you one week closer to shipping product than the guy who goes out for drinks after work and will play video games with you and go rock climbing. So if you don't hire him, your competitors will and then your competition will leave you behind while you're out drinking and playing video games and rock climbing.
An otherwise boring guy who goes home to his family and spends his weekends working on his house and watching football might get you one week closer to shipping product than the guy who goes out for drinks after work and will play video games with you and go rock climbing. So if you don't hire him, your competitors will and then your competition will leave you behind while you're out drinking and playing video games and rock climbing.
Why do you link "enticing colleague" with "doing whatever with that guy after (instead of) work(ing)"?
So your competitors hire the boring guy and get that feature one week earlier. You hire interesting people and they form a cohesive team, carry each other through tough times and work more passionately overall. At the end, you get N extra, unique features as a byproduct of your more involved workers, shooting months ahead of your competitor.
I know I presented an ideal case, but it makes my point. Working around boring (as in non-interesting) people is boring, and you won't be as productive in that environment. Thus, it makes sense to avoid these people unless you very much need their specific skills and you can't find those anywhere else.
So your competitors hire the boring guy and get that feature one week earlier. You hire interesting people and they form a cohesive team, carry each other through tough times and work more passionately overall. At the end, you get N extra, unique features as a byproduct of your more involved workers, shooting months ahead of your competitor.
I know I presented an ideal case, but it makes my point. Working around boring (as in non-interesting) people is boring, and you won't be as productive in that environment. Thus, it makes sense to avoid these people unless you very much need their specific skills and you can't find those anywhere else.
I guess you'll just have to define what you mean by "boring" then. People who can meaningfully contribute to solving problems are good programmers and good professionals, but they could still be "boring" in the sense that they're not interesting as people.
Let's say you had a coworker who was knowledgable about the problem domain you worked on, produced lots of good code, made great positive contributions to any design meeting or code review he was invited to, always had a free moment to answer questions, but he always brought leftovers from home for lunch and ate by himself and never really made a joke or hung around with the team in a social context and you never got a sense for what his personality was outside of work because he only ever seemed to get engaged when the discussion was about work. I'd say that's a great coworker, someone I would love to work with, but also a very boring person. So why wouldn't you want to work with this guy?
Let's say you had a coworker who was knowledgable about the problem domain you worked on, produced lots of good code, made great positive contributions to any design meeting or code review he was invited to, always had a free moment to answer questions, but he always brought leftovers from home for lunch and ate by himself and never really made a joke or hung around with the team in a social context and you never got a sense for what his personality was outside of work because he only ever seemed to get engaged when the discussion was about work. I'd say that's a great coworker, someone I would love to work with, but also a very boring person. So why wouldn't you want to work with this guy?
Obviously, I would prefer to work with this guy than with someone more interesting but clueless. However, this doesn't mean that I would be happy doing it.
On the one hand, you present a very idealized case: how can she engage in (tangentially) work-related discussions if she's never around when discussions happen outside of meetings? After 8 years in industry and 4 as a PhD student, I have worked with and around many excellent people. However, I still have to meet someone that fits your example. They probably exist, but it is way easier to find either excellent interesting people or excellent boring people who simply won't get as engaged in your team/company.
On the other hand, at least for a small company, hiring the wrong person is much more costly than passing on a good candidate. Thus, when you interview (hopefully excellent) boring persons, probabilities are hugely stacked against them.
On the one hand, you present a very idealized case: how can she engage in (tangentially) work-related discussions if she's never around when discussions happen outside of meetings? After 8 years in industry and 4 as a PhD student, I have worked with and around many excellent people. However, I still have to meet someone that fits your example. They probably exist, but it is way easier to find either excellent interesting people or excellent boring people who simply won't get as engaged in your team/company.
On the other hand, at least for a small company, hiring the wrong person is much more costly than passing on a good candidate. Thus, when you interview (hopefully excellent) boring persons, probabilities are hugely stacked against them.
The point of my example was to isolate "boring" as a trait to demonstrate that, all other things being equal, "boring" doesn't matter. If someone's boring and also an asshole, the problem is that they're an asshole. If someone's boring and also doesn't contribute ideas, then the problem is that they don't contribute ideas. And so forth. The actual problem is never that someone is boring.
Personally I wouldn't mind working with him as a fellow employee, but he'd make me nervous as a manager of a small business. He sounds like he's great at his job, but has zero emotional ties to it, which translates to him being less likely to weather any bad times the company may face.
Ultimately, you clearly agree that gaining and retaining great talent is what makes a software business stand ahead of its competition, so isn't it risky to gain someone who isn't going to feel bad about leaving the business (and take all his experience with him)? If I can hire someone who'll fit in well with the team and produce good quality code, then I'd consider him a better long term investment that someone who fits in poorly with the team and writes great quality code, purely because the latter person has fewer reasons to stick with the business than the former.
Ultimately, you clearly agree that gaining and retaining great talent is what makes a software business stand ahead of its competition, so isn't it risky to gain someone who isn't going to feel bad about leaving the business (and take all his experience with him)? If I can hire someone who'll fit in well with the team and produce good quality code, then I'd consider him a better long term investment that someone who fits in poorly with the team and writes great quality code, purely because the latter person has fewer reasons to stick with the business than the former.
I'm not sure what kind of connection there is between being boring and being more likely to jump ship. Plenty of interesting people jump ship too, because the best way to become interesting is to accumulate a lifetime of diverse experiences and staying in any one place gets in the way of that.
If you don't want people to leave the business, earn their loyalty. A boring person still wants to be treated fairly. They still want to take vacation, even if it's to visit their boring family rather than go backpacking in Tibet. They still have the same capacity to either enjoy or hate their job. They just don't necessarily have an interesting answer to the question "any plans for the weekend?", and I don't see why that makes them worse employees.
If you don't want people to leave the business, earn their loyalty. A boring person still wants to be treated fairly. They still want to take vacation, even if it's to visit their boring family rather than go backpacking in Tibet. They still have the same capacity to either enjoy or hate their job. They just don't necessarily have an interesting answer to the question "any plans for the weekend?", and I don't see why that makes them worse employees.
I'm not sure we mean the same thing by 'boring'. Boring, to me, doesn't mean that the person doesn't have hobbies, rather it means that the person is a perfectly nice person who just doesn't gel with the team. In fact, 'boring' is probably the wrong word here: it should probably be something closer to 'outsider'. That said, larger organisations do depend upon outsiders to prevent groupthink, so this is a multi-faceted issue.
That's not quite what I was after, but it's a good observation. I don't mind outsiders so long as they're energetic and interesting.
In this context there are two kinds of people - the "just a job" crowd and the "live and breathe this thing" crowd.
Either is a completely valid lifestyle, but they just don't mix well, so they should screen each other out at interviews.
Either is a completely valid lifestyle, but they just don't mix well, so they should screen each other out at interviews.
If you live and breathe programming than you want to work with the best programmers. It shouldn't matter whether they're "entertaining". To me that sounds like the interviewer has no friends and uses work as a surrogate social life, not that he lives and breathes the actual work.
I should add here that "the best programmers" are, quite frankly, not always people I want to work with. I worked under a totally brilliant tech lead for a while, one of the finest programmers I've ever met. But he relished being an asshole, and really grated on people. I learned as much from him as I've ever learned from anyone, and I actually kind of like him as a person, but I'm so glad I don't have to work with him anymore.
Brilliant people don't always play well with others, and software is (in my world at least) a team effort. I want to work with people who pull the team together, not tear it apart, no matter how talented they are technically.
Brilliant people don't always play well with others, and software is (in my world at least) a team effort. I want to work with people who pull the team together, not tear it apart, no matter how talented they are technically.
"Best programmers" and "people who contribute effectively to a team's culture" can sometimes be exclusive sets.
One of the most intelligent and creative programmers I know is an arrogant douchebag who demoralises entire teams. He's very effective on his own, but stick him in a scrum team, and watch the culture of that team sour and watch its productivity drop.
One of the most intelligent and creative programmers I know is an arrogant douchebag who demoralises entire teams. He's very effective on his own, but stick him in a scrum team, and watch the culture of that team sour and watch its productivity drop.
And if your team culture is "let's be interesting creative people with zany hairstyles and really unusual hobbies" (not my team, but I sit beside them), then someone who is passionate mainly about checked exceptions is probably going to be a bad fit.
I used the arrogant douchebag as an example of why a great programmer who doesn't fit a team's culture is going to drag down the productivity of that team - how they don't fit that culture can obviously vary.
I used the arrogant douchebag as an example of why a great programmer who doesn't fit a team's culture is going to drag down the productivity of that team - how they don't fit that culture can obviously vary.
The team I work on has gone from a culture of "single guys who stay after work playing board games and go out drinking sometimes" to a culture of "married guys who leave promptly at 5 PM to go home to their pregnant wives and/or children" by gradually introducing people from the second set while people from the first set leave. Guess what? It didn't affect how much we managed to accomplish, because it's work and that bullshit doesn't really matter.
Fair enough, each team's dynamics are different.
Kind of the opposite, really. I have a tremendous number of friends and a very active social life. I find "work" can be a drag if it's not as much fun as not-work is.
One of the ways I manage to be a very happy person is to not spend time with people who don't actively make me happy, any more than necessary.
One of the ways I manage to be a very happy person is to not spend time with people who don't actively make me happy, any more than necessary.
I guess I can't fault that if you're running a lifestyle business, but hiring programmers on the basis of how entertaining they are isn't really defensible on the basis of delivering results.
I wouldn't hire someone just because they're entertaining. But I might not hire someone otherwise qualified if they're not. And I'm not even in the habit of socializing with co-workers outside the job. But the job is enough hours with someone that I'd much prefer to enjoy their company.
I'm not sure why you keep assuming the best programmers are boring or unpleasant. I've found the opposite to be true, generally.
I'm not sure why you keep assuming the best programmers are boring or unpleasant. I've found the opposite to be true, generally.
I assume nothing. I'm just pointing out that being "boring" or "entertaining" is completely irrelevant to whether someone is suited for a programming job, and that unless you're running a lifestyle business where enjoying your work day is more important than delivering results for your customers or getting paid, you're doing your company a disservice by hiring people based on these kinds of irrelevant characteristics.
I think it really depends upon the business. I mean, a genuinely bad programmer, who doesn't merely fail to positively affect a codebase but actually manages to worsen it, will be bad in any programming business. However, many software shops just won't see the return on having a superstar. For instance, consider a shop writing Excel VSTO plug-ins: it's not wildly difficult work once you've done it a few times, but the work is time consuming, so it'd make more sense in that business to have good programmers who can work together and cover each others' backs than it would to have one brilliant programmer who annoys the rest of the team into leaving, or bores the rest of the team into losing what little enthusiasm they have for an already fairly boring niche of software development.
It may not make sense to choose personality over technical chops if you're trying to hire a language designer, but it may make sense to do so if you're in a niche which requires teamwork.
It may not make sense to choose personality over technical chops if you're trying to hire a language designer, but it may make sense to do so if you're in a niche which requires teamwork.
I think he's looking for people that are fit for the job AND the chat over coffee.
Maybe I'm the clueless aspie here, but that sounds like the consequences of having a dominant-personality team that doesn't respect boundaries.
But, at the end of the day, teams can hire who they want, so I definitely don't think this sort of thing is inherently wrong -- I guess I miss the part of the industry where one could work in near-solitude since that's what I prefer.
But, at the end of the day, teams can hire who they want, so I definitely don't think this sort of thing is inherently wrong -- I guess I miss the part of the industry where one could work in near-solitude since that's what I prefer.
I don't like working in solitude myself. I'm a social person, and I need other people to bounce off of.
I'm not the only one, either. I was trying to recruit an old colleague (and I'm not done trying to recruit him!), and his biggest concern about going to an early startup was the lack of a team to work with. He's one of the nicest and most easygoing people I know, and a natural leader. I'd love to have him leading a team of developers for me. But first, I'd have to get him a team.
I'm not the only one, either. I was trying to recruit an old colleague (and I'm not done trying to recruit him!), and his biggest concern about going to an early startup was the lack of a team to work with. He's one of the nicest and most easygoing people I know, and a natural leader. I'd love to have him leading a team of developers for me. But first, I'd have to get him a team.
[deleted]
I also like to use the opportunity of an interview to focus on the softs skills. Although I think there´s a company and a job for everyone. Sometimes you might want to hire a timid or boring person to perform a task on their own, on a night shift, or even the culture of the company is intended to be boring, I mean there´s a lot of reasons you can hire timid, boring... even assholes are handy sometimes!
-1 for forcing sign in. What if I don't care about saving my progress? What if I'm not a member of any of those services? Answer: 10 second pageview guaranteed to not become a return visiter.
They have a list of all the questions you can go through, no sign in required. Not sure what you're talking about.
http://www.interviewcake.com/all-questions
http://www.interviewcake.com/all-questions
That's great. Now, go to their homepage without being logged in and see if you can find a link anywhere to the all-questions page.
Only by using "view source":
<!--
<li>
<a href="/all-questions">All Questions</a>
</li>
-->
Hrm. Maybe that's one of the interview questions.
He's talking about the normal flow of the site (click the big blue button at the bottom of the first page, then the second page). This leads to a "Login with Github/Google/Facebook" prompt that can't be skipped. You can close it, but that doesn't get you anywhere.
I would guess that obituary_latte is talking about the fact that there's no link to the page you're referring to.
Worst part is their max-stack isn't optimal. You can do it with O(1) additional space.
Please explain. Without maintaining that ordering, you're going to have to iterate over the entire stack after every pop, no? One of their requirements was to keep pop() at O(1) rather than O(n).
Hm. How?
Also, cookies are perfectly fine for saving progress.
Quick someone show this to college students. Most of his advice is exactly what I am looking for when I give interviews.
So then give it to the people you are interviewing before you interview them. You don't need a middle man.
Here's where I think I diverge from most people on this topic. My personal view is that I think by the time you bring someone in for an interview, you should already know that they can code, whether that's through code samples they provide or through Github accounts or whatever.
TL;DR; Don't waste your applicants time or your own
## The Interview Interviewing should have two parts, imo:
* Confirming that I actually wrote the code I sent you and know what it means
* Confirming that you want to sit next to me for the next six months
I can tell you right now that if I take time off my current job to go sit in your office for an interview and you ask me basic questions like "What is MVC?" or "What's the difference between a POST and a GET request?", I'm going to thank you for your time and walk right out.
Why? Because my Github profile, which is featured prominently on my resume, contains examples of both. Half my projects are MVC projects, and many of them use 3rd party APIs (or are even APIs themselves!). The fact that you're asking me basic definitions means you didn't even pay attention to the stuff I sent you, so you're wasting my time and yours. You could have already figured this out ahead of time. Instead, you asked me to take time out of my day (probably during work hours) to ask questions whose answers I've already provided.
(Please note that this only really goes for non-entry-level positions. For entry-level applicants, such as kids fresh out of college, you may not have very many code samples to work with. That's fine. In that case, send some problems for them to work on at home. Hopefully, these are dumbed-down but real-world problems your company has faced in the past.)
## Phone Screen (aka verifying authenticity)
The first thing you should do is take a gander at my Github profile or my code samples. Then you call me up at a prearranged time and ask me questions about that code. Make me prove that I wrote what I said I wrote.
* I noticed you made this combat simulator (www.bitfalls.com/2013/08/autofight-php-job-interview-task-part-1.html). Walk me through your thought process.
* Your code appears to be a custom MVC. Why did you choose to go with a custom one versus say, CodeIgniter or Symfony?
* This project is an API for Nerd Nite scheduling. First of all, what's Nerd Nite and why did you make an API for it? Second, explain how you scraped the data, organized it, and output the results.
The above three questions will give you way more insight into my programming style and thought process than "What is an MVC?". Please. Don't waste my time. As a senior engineer with 7+ years in the field, I shouldn't need to prove the equivalent of my ABCs to you. It should be understood.
I personally would also skip the whole "live coding" thing via Stypi or whatever. Waste of time, imo. You've already got code samples and you can ask me as many questions as you want about it. I shouldn't need to write code in front of you to establish my credentials.
## What about people who lie?
There are people who lie about their resume and their qualifications, but that's exactly why you should tailor your questions to fit the code samples provided. If I don't get excited about that code and I can't eloquently explain why I did what I did or how it works, then maybe I didn't write it after all. It also gives you an insight as to my personality: I clearly took time out of my day to write this code. Why? What prompted me to write an API for Nerd Nite schedules?
The answers to those questions should give you an idea of whether I can actually program or not. Questions like "What is MVC?" can be looked up in a dictionary. Explaining code samples is much more difficult.
## What next?
Once you've established that I wrote the code I said I wrote, then Step 1 of The Interviewing process is mostly done. Now you bring me into the office to determine Step 2 -- am I someone you want sitting next to you for 8+ hours a day for the next six months? Do I fit in with company culture?
You could give me a problem to solve on the spot, but hopefully it's more of a higher level thing rather than a "write code on a whiteboard" thing. The reason I say this is because at this point you should already have seen my code. You should know by now that I can build a class. The question you need to answer now is: given an arbitrary problem, can I solve it or at least come up with a reasonable thought process?
Bonus points if it's relevant to the job. (i.e., if your job never requires you to write binary trees from scratch, don't ask the applicant to do so.)
## Finally
Between the phone screen (technical) and in-person interview (personal), you should have a good idea of whether you want me on your team or not.
Occasionally for small teams, you may decide that you need to know something about time, creativity, independence, and other similar qualities that you can't really get from code samples. If this is the case, then I suggest doing the contract thing, where you give them an assignment on contract. Once the assignment is finished, you hire them or pay them for the work completed (or hopefully both).
I really, really, really despise whiteboard coding. I don't think it's indicative of anything, and I think you will find a lot of false negatives (i.e., rule out good candidates) using the whiteboard method.
A few other thoughts:
* I should meet my potential future boss at the in-person interview
* I should meet at least one of my potential future coworkers
* Be respectful of my time. Most interviews take place during work hours, so I've taken time off work -- and probably lied to my boss about where I'm going! -- to meet with you. The least you can do is not waste my time.
* Be familiar with my resume and code samples. I took the time to write them, you should take the time to read them. It will answer way more questions about my abilities than a 20 minute quiz on technical terms will.
The more informal the in-person interview is, the better. The technical qualifications should already be accepted by the time I walk in the door. At this point, it's a two way street as we figure out whether we want to work together. I'm interviewing you just as much as you are interviewing me.
(Note: These are just my opinions about how I interview others. It hasn't failed me yet. On the other hand, almost every job I've ever interviewed for has completely wasted my time on that front.)
TL;DR; Don't waste your applicants time or your own
## The Interview Interviewing should have two parts, imo:
* Confirming that I actually wrote the code I sent you and know what it means
* Confirming that you want to sit next to me for the next six months
I can tell you right now that if I take time off my current job to go sit in your office for an interview and you ask me basic questions like "What is MVC?" or "What's the difference between a POST and a GET request?", I'm going to thank you for your time and walk right out.
Why? Because my Github profile, which is featured prominently on my resume, contains examples of both. Half my projects are MVC projects, and many of them use 3rd party APIs (or are even APIs themselves!). The fact that you're asking me basic definitions means you didn't even pay attention to the stuff I sent you, so you're wasting my time and yours. You could have already figured this out ahead of time. Instead, you asked me to take time out of my day (probably during work hours) to ask questions whose answers I've already provided.
(Please note that this only really goes for non-entry-level positions. For entry-level applicants, such as kids fresh out of college, you may not have very many code samples to work with. That's fine. In that case, send some problems for them to work on at home. Hopefully, these are dumbed-down but real-world problems your company has faced in the past.)
## Phone Screen (aka verifying authenticity)
The first thing you should do is take a gander at my Github profile or my code samples. Then you call me up at a prearranged time and ask me questions about that code. Make me prove that I wrote what I said I wrote.
* I noticed you made this combat simulator (www.bitfalls.com/2013/08/autofight-php-job-interview-task-part-1.html). Walk me through your thought process.
* Your code appears to be a custom MVC. Why did you choose to go with a custom one versus say, CodeIgniter or Symfony?
* This project is an API for Nerd Nite scheduling. First of all, what's Nerd Nite and why did you make an API for it? Second, explain how you scraped the data, organized it, and output the results.
The above three questions will give you way more insight into my programming style and thought process than "What is an MVC?". Please. Don't waste my time. As a senior engineer with 7+ years in the field, I shouldn't need to prove the equivalent of my ABCs to you. It should be understood.
I personally would also skip the whole "live coding" thing via Stypi or whatever. Waste of time, imo. You've already got code samples and you can ask me as many questions as you want about it. I shouldn't need to write code in front of you to establish my credentials.
## What about people who lie?
There are people who lie about their resume and their qualifications, but that's exactly why you should tailor your questions to fit the code samples provided. If I don't get excited about that code and I can't eloquently explain why I did what I did or how it works, then maybe I didn't write it after all. It also gives you an insight as to my personality: I clearly took time out of my day to write this code. Why? What prompted me to write an API for Nerd Nite schedules?
The answers to those questions should give you an idea of whether I can actually program or not. Questions like "What is MVC?" can be looked up in a dictionary. Explaining code samples is much more difficult.
## What next?
Once you've established that I wrote the code I said I wrote, then Step 1 of The Interviewing process is mostly done. Now you bring me into the office to determine Step 2 -- am I someone you want sitting next to you for 8+ hours a day for the next six months? Do I fit in with company culture?
You could give me a problem to solve on the spot, but hopefully it's more of a higher level thing rather than a "write code on a whiteboard" thing. The reason I say this is because at this point you should already have seen my code. You should know by now that I can build a class. The question you need to answer now is: given an arbitrary problem, can I solve it or at least come up with a reasonable thought process?
Bonus points if it's relevant to the job. (i.e., if your job never requires you to write binary trees from scratch, don't ask the applicant to do so.)
## Finally
Between the phone screen (technical) and in-person interview (personal), you should have a good idea of whether you want me on your team or not.
Occasionally for small teams, you may decide that you need to know something about time, creativity, independence, and other similar qualities that you can't really get from code samples. If this is the case, then I suggest doing the contract thing, where you give them an assignment on contract. Once the assignment is finished, you hire them or pay them for the work completed (or hopefully both).
I really, really, really despise whiteboard coding. I don't think it's indicative of anything, and I think you will find a lot of false negatives (i.e., rule out good candidates) using the whiteboard method.
A few other thoughts:
* I should meet my potential future boss at the in-person interview
* I should meet at least one of my potential future coworkers
* Be respectful of my time. Most interviews take place during work hours, so I've taken time off work -- and probably lied to my boss about where I'm going! -- to meet with you. The least you can do is not waste my time.
* Be familiar with my resume and code samples. I took the time to write them, you should take the time to read them. It will answer way more questions about my abilities than a 20 minute quiz on technical terms will.
The more informal the in-person interview is, the better. The technical qualifications should already be accepted by the time I walk in the door. At this point, it's a two way street as we figure out whether we want to work together. I'm interviewing you just as much as you are interviewing me.
(Note: These are just my opinions about how I interview others. It hasn't failed me yet. On the other hand, almost every job I've ever interviewed for has completely wasted my time on that front.)
I can tell you right now that if I take time off my current job to go sit in your office for an interview and you ask me basic questions like "What is MVC?" or "What's the difference between a POST and a GET request?", I'm going to thank you for your time and walk right out.
Oh yeah? Well, if I'm being interviewed, and someone doesn't ask me those questions, I'm going to walk right out!!
This is how we debate interview tactics, right?
Oh yeah? Well, if I'm being interviewed, and someone doesn't ask me those questions, I'm going to walk right out!!
This is how we debate interview tactics, right?
Seriously, I stopped reading right there.
It must be the current tech-boom, the whole Demand > Supply, that creates attitudes like that.
Don't walk out on interviews just because you feel your time is so valuable. You're already at the interview. You planned your day for it and started it. Just politely continue 'till the end, you might learn something you didn't know before.
At the most, if you get a way out there question, like, you applied for a dev job and they ask about your proficiency in Microsoft Office, just politely say. "I've used it from time to time. By the way, I've never been asked that question in a developer interview before."...and just continue on. If you think so much of yourself that you're offended by that type of question and abort the interview, I think that says a lot about you just as much as the interviewer.
Hmm, I'm going to suggest to my company that we actually asked dev candidates that question! See what happens! (somehow, I doubt they'll do it.... but it'd be funny to get the reactions).
Don't walk out on interviews just because you feel your time is so valuable. You're already at the interview. You planned your day for it and started it. Just politely continue 'till the end, you might learn something you didn't know before.
At the most, if you get a way out there question, like, you applied for a dev job and they ask about your proficiency in Microsoft Office, just politely say. "I've used it from time to time. By the way, I've never been asked that question in a developer interview before."...and just continue on. If you think so much of yourself that you're offended by that type of question and abort the interview, I think that says a lot about you just as much as the interviewer.
Hmm, I'm going to suggest to my company that we actually asked dev candidates that question! See what happens! (somehow, I doubt they'll do it.... but it'd be funny to get the reactions).
I probably wouldn't literally just up and walk out, but it would count against you. Why would I want to work for someone who can't be bothered to read my sample code or resume? There's a double-standard here, where I'm supposed to have done research on your company before showing up, but you don't necessarily have to do that for me.
Are you hiring me to recite textbook definitions to you, or are you hiring me to write code? You can't really have it both ways. By asking me to recite textbook definitions when I've clearly demonstrated that I know the basics (at the very least), then you're wasting my time and your own.
This isn't hubris or egotism -- it's pragmatism. I've already provided the answer, and you're asking me the question again. You should ask me something you can't easily find the answer. Or better yet, ask me a question that answers several questions at once.
You might ask "I noticed on your Github profile you have an application called NaNoWriMo clone. What's that all about?" and I might say "Well, it's an MVC-based application that uses third party API calls to Google Docs using cURL and...."
And you might find that I've answered all of the stupid, basic "What is MVC?" and "What's a POST request?" and "Describe how HTTP works" questions that you would have asked before, except now instead of asking me rote questions that I get at every single interview, you'll find that you're getting the answers to those questions and then some.
Are you hiring me to recite textbook definitions to you, or are you hiring me to write code? You can't really have it both ways. By asking me to recite textbook definitions when I've clearly demonstrated that I know the basics (at the very least), then you're wasting my time and your own.
This isn't hubris or egotism -- it's pragmatism. I've already provided the answer, and you're asking me the question again. You should ask me something you can't easily find the answer. Or better yet, ask me a question that answers several questions at once.
You might ask "I noticed on your Github profile you have an application called NaNoWriMo clone. What's that all about?" and I might say "Well, it's an MVC-based application that uses third party API calls to Google Docs using cURL and...."
And you might find that I've answered all of the stupid, basic "What is MVC?" and "What's a POST request?" and "Describe how HTTP works" questions that you would have asked before, except now instead of asking me rote questions that I get at every single interview, you'll find that you're getting the answers to those questions and then some.
Just because someone has code in their repo that uses GET and POST correctly doesn't mean the person knows why it was written that way. I've talked with people who admitted "I just copied this from stackoverflow."
It's also a very easy filter question that takes about 10 seconds to answer. There are still people that show up to interview that cannot FizzBuzz.
I appreciate feeling pissed at companies that don't seem to do any research into you. I've felt that same annoyance, especially when job hunting while employed, meaning I was using my PTO to talk to you guys. (And I especially hate the recruiters who call me at 4pm saying "I got you an interview tomorrow morning at 10am." Guess what I've got for you?) But maybe your code isn't showing exactly what you do the same way you think, or maybe they are working for an organization that is lucky enough to use something besides git.
I have a long list of complaints about how companies hire people. Giving me quick tests on basics isn't one of them.
It's also a very easy filter question that takes about 10 seconds to answer. There are still people that show up to interview that cannot FizzBuzz.
I appreciate feeling pissed at companies that don't seem to do any research into you. I've felt that same annoyance, especially when job hunting while employed, meaning I was using my PTO to talk to you guys. (And I especially hate the recruiters who call me at 4pm saying "I got you an interview tomorrow morning at 10am." Guess what I've got for you?) But maybe your code isn't showing exactly what you do the same way you think, or maybe they are working for an organization that is lucky enough to use something besides git.
I have a long list of complaints about how companies hire people. Giving me quick tests on basics isn't one of them.
I think you miss my point. The point isn't that "What's the difference between POST and GET?" is a bad question (it absolutely is), but rather that there's a better way to find that answer out than ask that question.
Here's how tech interviews normally go for me.
Interviewer: "Hi. Tell me about yourself while I look at your resume for the first time."
Me: "I've been programming since I was 12, went to college, got a degree in X. In the past several years I've worked on Y, which was built using Z with blah blah blah."
Interviewer: "Great, great. Can you tell me what an MVC is?"
Me: (mentally groaning) "MVC stands for model-view-controller. A model is..."
Interviewer: "Great, great. What's the difference between a POST and a GET request?"
Me: (mentally groaning again) "They're both verbs used in HTTP requests. A POST is..."
Interviewer: "Great, great. Let's do some whiteboard coding. Convert this array into a binary tree."
Me: "function convert_array_to_binary_tree(foo) {..."
Interviewer: "Great, great. Well, we're all out of time. I'll bring in the next person."
Interviewer2: "Hi, tell me about yourself while I look at your resume for the first time."
How it should go:
Interviewer: "Hi, I'm so-and-so. I've been checking out your resume and I saw that on your Github profile, you wrote an application called NaNoWriMoClone. What's that?"
Me: (excited) "Oh man. So in my free time, I like to write. Every year in November I participate in a contest called NaNoWriMo, which stands for National Novel Writing Month. I like their interface so much that I wanted to be able to use it every day, even if it's not during NaNoWriMo. What I did was I started out with a custom MVC framework that I wrote a year ago. Basically, you go to the main page, and you sign in using either FB or Twitter sign-on, which use OAuth to connect. I wrote a custom OAuth implementation, which you probably saw on my profile. I can go into detail about that, if you want. Anyway, so there are two models: users and novels. There's a one-to-many relationship where one user can have many novels. As the user writes, they can update the word count on the novel, and the app will calculate progress and how many words need to be written per day."
Interviewer: "Cool! I like to write too and I did NaNoWriMo last year. It was a nice experience, but it was so hard to track words."
Me: "I know! I thought about that, too, which is why I also integrated it with a Google Docs API. What I'm doing in the Google_Api class is hitting their API with a GET request to get the contents of their novel, then I count the number of words and update their count automatically. That's one thing NaNoWriMo doesn't do -- you have to input your progress manually. I also want to add a Markdown editor in-app which would send a POST request back to Google Docs and update the novel. So they can write it in the app and store it in Google Docs!"
Interviewer: "Awesome. You mentioned you used the Google Docs API. Did you run into any problems with that? If so, how did you get around them?"
Me: "The Google Docs API is pretty straightforward, but I wound up having to make several requests to get the data I wanted. For instance, I have to make one GET request to get the list of documents my app has access to, then another GET request to get the actual document I wanted, and then a third GET request to get metadata about the document. It took me awhile to handle exceptions, such as if I was denied access to a specific document, but I finally got that working, and now if something goes wrong, I can notify the user and have them look into the permissions or whether the document actually exists and so on."
Interviewer: "You mentioned you wrote the MVC framework from scratch. Why did you do that rather than use CodeIgniter or Symfony? Did you run into any problems?"
Me: "I decided I wanted to learn how MVC worked from the ground up. I had used Symfony in the past, but I wanted something a little less complex. So I started off with..." (and so on)
Interviewer: "I see you went to X college and got a degree in Y. That's interesting. How did you transition over to programming?"
----
Anyway, as you can see, the interviewer is getting WAY more out of me in the second example. Not only does he know that I know what MVC means, I've also demonstrated that I know how to use a 3rd party API, which necessitates knowledge of GET/POST requests. Furthermore, with a follow up question like "What problems did you run into?" the interviewer can find out whether I actually wrote it myself or if I went to StackOverflow to copy and paste it.
The point isn't that "What is the difference between POST and GET?" is a bad question (though it is unquestionably an inefficient question), the point is that you can find out that information in other ways (specifically from code samples!) and get so, so, so much more out of the interview. You will not only be saving both of us time, but the experience should be much more enjoyable for both of us.
You'll also notice in the second example that I've expressed non-programming aspects about myself. I enjoy writing. Maybe my interviewer enjoys writing (everyone harbors aspirations of writing a book someday, yes?), so now we have something to connect on. I have a non-CS degree. Maybe in a topic the interviewer is interested in. It establishes that I'm a real, live person and not just a code monkey. It's something we could talk about over lunch that's not work-related. It's a huge plus, imo.
Finally, your "lucky enough use something besides git" is irrelevant. You don't have to use git to look at my Github profile. My public repositories are public, and you can view the code willy nilly without even signing up for Github. You could just as easily substitute SVN or Mercurial or whatever.
This is why articles like OPs frustrate me so much. They pile on with the simple questions that get a single answer and don't really teach you how to interview more effectively.
Here's how tech interviews normally go for me.
Interviewer: "Hi. Tell me about yourself while I look at your resume for the first time."
Me: "I've been programming since I was 12, went to college, got a degree in X. In the past several years I've worked on Y, which was built using Z with blah blah blah."
Interviewer: "Great, great. Can you tell me what an MVC is?"
Me: (mentally groaning) "MVC stands for model-view-controller. A model is..."
Interviewer: "Great, great. What's the difference between a POST and a GET request?"
Me: (mentally groaning again) "They're both verbs used in HTTP requests. A POST is..."
Interviewer: "Great, great. Let's do some whiteboard coding. Convert this array into a binary tree."
Me: "function convert_array_to_binary_tree(foo) {..."
Interviewer: "Great, great. Well, we're all out of time. I'll bring in the next person."
Interviewer2: "Hi, tell me about yourself while I look at your resume for the first time."
How it should go:
Interviewer: "Hi, I'm so-and-so. I've been checking out your resume and I saw that on your Github profile, you wrote an application called NaNoWriMoClone. What's that?"
Me: (excited) "Oh man. So in my free time, I like to write. Every year in November I participate in a contest called NaNoWriMo, which stands for National Novel Writing Month. I like their interface so much that I wanted to be able to use it every day, even if it's not during NaNoWriMo. What I did was I started out with a custom MVC framework that I wrote a year ago. Basically, you go to the main page, and you sign in using either FB or Twitter sign-on, which use OAuth to connect. I wrote a custom OAuth implementation, which you probably saw on my profile. I can go into detail about that, if you want. Anyway, so there are two models: users and novels. There's a one-to-many relationship where one user can have many novels. As the user writes, they can update the word count on the novel, and the app will calculate progress and how many words need to be written per day."
Interviewer: "Cool! I like to write too and I did NaNoWriMo last year. It was a nice experience, but it was so hard to track words."
Me: "I know! I thought about that, too, which is why I also integrated it with a Google Docs API. What I'm doing in the Google_Api class is hitting their API with a GET request to get the contents of their novel, then I count the number of words and update their count automatically. That's one thing NaNoWriMo doesn't do -- you have to input your progress manually. I also want to add a Markdown editor in-app which would send a POST request back to Google Docs and update the novel. So they can write it in the app and store it in Google Docs!"
Interviewer: "Awesome. You mentioned you used the Google Docs API. Did you run into any problems with that? If so, how did you get around them?"
Me: "The Google Docs API is pretty straightforward, but I wound up having to make several requests to get the data I wanted. For instance, I have to make one GET request to get the list of documents my app has access to, then another GET request to get the actual document I wanted, and then a third GET request to get metadata about the document. It took me awhile to handle exceptions, such as if I was denied access to a specific document, but I finally got that working, and now if something goes wrong, I can notify the user and have them look into the permissions or whether the document actually exists and so on."
Interviewer: "You mentioned you wrote the MVC framework from scratch. Why did you do that rather than use CodeIgniter or Symfony? Did you run into any problems?"
Me: "I decided I wanted to learn how MVC worked from the ground up. I had used Symfony in the past, but I wanted something a little less complex. So I started off with..." (and so on)
Interviewer: "I see you went to X college and got a degree in Y. That's interesting. How did you transition over to programming?"
----
Anyway, as you can see, the interviewer is getting WAY more out of me in the second example. Not only does he know that I know what MVC means, I've also demonstrated that I know how to use a 3rd party API, which necessitates knowledge of GET/POST requests. Furthermore, with a follow up question like "What problems did you run into?" the interviewer can find out whether I actually wrote it myself or if I went to StackOverflow to copy and paste it.
The point isn't that "What is the difference between POST and GET?" is a bad question (though it is unquestionably an inefficient question), the point is that you can find out that information in other ways (specifically from code samples!) and get so, so, so much more out of the interview. You will not only be saving both of us time, but the experience should be much more enjoyable for both of us.
You'll also notice in the second example that I've expressed non-programming aspects about myself. I enjoy writing. Maybe my interviewer enjoys writing (everyone harbors aspirations of writing a book someday, yes?), so now we have something to connect on. I have a non-CS degree. Maybe in a topic the interviewer is interested in. It establishes that I'm a real, live person and not just a code monkey. It's something we could talk about over lunch that's not work-related. It's a huge plus, imo.
Finally, your "lucky enough use something besides git" is irrelevant. You don't have to use git to look at my Github profile. My public repositories are public, and you can view the code willy nilly without even signing up for Github. You could just as easily substitute SVN or Mercurial or whatever.
This is why articles like OPs frustrate me so much. They pile on with the simple questions that get a single answer and don't really teach you how to interview more effectively.
I agree, but I think people should still maintain politeness even if the interviewer appears to be doing a less-than-awesome job. Even if you already know halfway into the interview that you're not taking any job-offer from them... just go through it 'till the end. If nothing else, it's an experience and maybe you'll pick up more info on how to avoid those companies in the future.
Sure, I agree.
Agreed. Personally; if I'm giving an interview and the candidate were to walk out for something like that I would be thinking, "Glad they walked out; I really would rather not work with that asshole."
There is such thing as figures of speech. :) I doubt I'd seriously just up and walk out, but it would be a huge strike against you on my part. Remember, you're not just interviewing me -- I'm interviewing you as well.
How will you know that no one is going to ask those questions if you don't stick around for the entire interview?
As a senior engineer with 7+ years in the field, I shouldn't need to prove the equivalent of my ABCs to you. It should be understood.
You'd be surprised how many 'senior' engineers can't code their way out of a cardboard box.
Background: I've interviewed hundreds (if not thousands) of engineers.
You'd be surprised how many 'senior' engineers can't code their way out of a cardboard box.
Background: I've interviewed hundreds (if not thousands) of engineers.
I'm always curious about the senior engineers who "can't code their way out of a cardboard box". I often wonder if I'm one of those, or come across as one of those.
Can you give an example of something you've seen. I just keep hearing about people who can't do fizzbuzz, but how bad are people really? Or what is it that makes these engineers so bad? How have they lasted in the industry?
Can you give an example of something you've seen. I just keep hearing about people who can't do fizzbuzz, but how bad are people really? Or what is it that makes these engineers so bad? How have they lasted in the industry?
they're really bad. i interviewed people that couldn't fill in a simple fizzbuzz after defining a function body and return type for them. they last because they can last, a lot of these jobs really just require codemonkeys. I have seen if states literally hundreds of words long made by these kinds of people.
that said i feel you. tbh, i have managed to impress anyone i worked with. most were people i met at hackathons, people that wanted to bootstrap their startups or general referals. on the other hand I failed most interviews i took(with a few noteworthy exceptions)
It once took me until after the interview to figure out that the guy just wanted to find out whether i understand how variable scopes work.
A lot of interview questions are questionable at best, and most code challenges are even worse. they're exactly how universities teach programming. The only problem is that universities suck at teaching programming. I know a lot of really awesome people that went to university because they thought knowing the topic they study was a good idea, but it turned out to be the opposite.
But one lady once asked me is there a special command to find out where traffic goes? I said route. Is there any special flag you would use she continued. But what she wanted was to hear route -n.
I'm pretty sure in those kinds of interviews they think i'm an idiot
that said i feel you. tbh, i have managed to impress anyone i worked with. most were people i met at hackathons, people that wanted to bootstrap their startups or general referals. on the other hand I failed most interviews i took(with a few noteworthy exceptions)
It once took me until after the interview to figure out that the guy just wanted to find out whether i understand how variable scopes work.
A lot of interview questions are questionable at best, and most code challenges are even worse. they're exactly how universities teach programming. The only problem is that universities suck at teaching programming. I know a lot of really awesome people that went to university because they thought knowing the topic they study was a good idea, but it turned out to be the opposite.
But one lady once asked me is there a special command to find out where traffic goes? I said route. Is there any special flag you would use she continued. But what she wanted was to hear route -n.
I'm pretty sure in those kinds of interviews they think i'm an idiot
I have two examples to share. A simple whiteboard question I ask is "Write a function to compute interest on your money. You have $X and I'm going to give you y% interesting for Z years."
I'm generally happy if they don't ask any questions and write a simple interest calculator. Most people ask some questions about when interest is calculated during the year. Then, if the questions haven't gotten us there yet, I ask them to modify it to a compound interest calculator where you can also contribute some money every year.
I've never had anyone who didn't understand the concept or what I was after. Or at least I didn't have anyone who admitted to still not understanding how it worked.
Two people stand out.
One of them immediately tried to write a recursive function and got lost. Then started over and tried to calculate a one-liner to do compound interest without looping. Couldn't get it, started over with a for-loop and failed to return in the proper place: the code was returning a value and then immediate next line was more calculation.
The second let me explain the problem and then said "I'm sure there's some library call for calculating compound interest, I'm just not sure what it is." Full stop. I explained that I wasn't asking for the library call, I was asking them to work up the algorithm and write code that did it.
They repeated the statement that there was a library call for it but they didn't know it and that if the interview was going to be about the specifics of library functions then it wasn't going to be a good interview.
In both cases these people passed a phone screen focusing mainly on experience, algorithms, design, etc... Since then I've adapted the phone screen to cover more of Steve Yegge's points [1] and I actually include a small coding question on the phone.
I don't think my system is perfect, but in the last round of hiring the people who made it through the screen were almost all good technically and weren't offered positions because of fit with the team. I'm sure there were a few people who might have been good that got filtered out by writing code over the phone but at the time I was willing to risk that vs the time commitment for the rest of my team to do on-site interviews for someone that could be DOA.
[1] https://sites.google.com/site/steveyegge2/five-essential-pho...
I'm generally happy if they don't ask any questions and write a simple interest calculator. Most people ask some questions about when interest is calculated during the year. Then, if the questions haven't gotten us there yet, I ask them to modify it to a compound interest calculator where you can also contribute some money every year.
I've never had anyone who didn't understand the concept or what I was after. Or at least I didn't have anyone who admitted to still not understanding how it worked.
Two people stand out.
One of them immediately tried to write a recursive function and got lost. Then started over and tried to calculate a one-liner to do compound interest without looping. Couldn't get it, started over with a for-loop and failed to return in the proper place: the code was returning a value and then immediate next line was more calculation.
The second let me explain the problem and then said "I'm sure there's some library call for calculating compound interest, I'm just not sure what it is." Full stop. I explained that I wasn't asking for the library call, I was asking them to work up the algorithm and write code that did it.
They repeated the statement that there was a library call for it but they didn't know it and that if the interview was going to be about the specifics of library functions then it wasn't going to be a good interview.
In both cases these people passed a phone screen focusing mainly on experience, algorithms, design, etc... Since then I've adapted the phone screen to cover more of Steve Yegge's points [1] and I actually include a small coding question on the phone.
I don't think my system is perfect, but in the last round of hiring the people who made it through the screen were almost all good technically and weren't offered positions because of fit with the team. I'm sure there were a few people who might have been good that got filtered out by writing code over the phone but at the time I was willing to risk that vs the time commitment for the rest of my team to do on-site interviews for someone that could be DOA.
[1] https://sites.google.com/site/steveyegge2/five-essential-pho...
"Engineers" who use so many nested if's that I have to horizontally scroll my 2560px width monitor.
They've lasted because they've usually only had one or two employers, as a permanent employee (rather than a contract) and no-one code reviews until it's too late.
They've lasted because they've usually only had one or two employers, as a permanent employee (rather than a contract) and no-one code reviews until it's too late.
So you are saying that you have interviewed hundreds of engineers and found many, many wanting according to whatever standards you set up in your interviews? Including many who came with high, verified recommendations from other workplace?
Have you also followed up on those failed interviewees to verify that in a real world setting they cannot perform?
If you haven't, then all I can see is a statement of "I have a standard very few can meet".
Have you also followed up on those failed interviewees to verify that in a real world setting they cannot perform?
If you haven't, then all I can see is a statement of "I have a standard very few can meet".
The more pernicious senior engineer is one who can code their way out of a box in an interview, but cannot deliver working code in a production environment due to various reasons - perfectionism seems to be a common thread to not delivering in my (limited) experience.
Do you have any pointers on weeding these candidates out? Our country's employment laws make it hard to fire net negative producing programmers.
Do you have any pointers on weeding these candidates out? Our country's employment laws make it hard to fire net negative producing programmers.
> can code their way out of a box in an interview, but cannot deliver working code in a production environment
> perfectionism seems to be a common thread to not delivering in my (limited) experience
I'm afraid I'm the engineer being described here. I pride myself on technical excellence, theoretical understanding and practical experience with lots of different technologies.
Yet my work history mostly consists of an unbroken trail of unfinished projects and undelivered deliverables stretching back decades.
How can I cure myself of this? Or should I switch careers?
> perfectionism seems to be a common thread to not delivering in my (limited) experience
I'm afraid I'm the engineer being described here. I pride myself on technical excellence, theoretical understanding and practical experience with lots of different technologies.
Yet my work history mostly consists of an unbroken trail of unfinished projects and undelivered deliverables stretching back decades.
How can I cure myself of this? Or should I switch careers?
I suppose the answer can only be supplied if we know more about you as a developer, and as a person. If you're a perfectionist, then it could well be that your previous projects are perceived by others to be of better quality than you yourself perceive them. A perfectionist could well consider a project 'unfinished' if it doesn't cover improbable edge cases, for example.
However, assuming that you're accurate in your statement that your projects were unfinished, then it would appear that you need to question why that's the case, as we cannot infer that the traits you've ascribed to yourself are the cause of project failures without knowing more about the other variables in the equation. For instance, the projects may well all have been failures for no fault of your own: scope creep, management interference, poor teamwork (or poor team members), or any number of other variables could be responsible. But since this is not something we can address at this point, let's assume that your project failures are indeed a result of your perfectionism.
The easiest way (in my experience) to 'cure' perfectionism in software is to follow the YAGNI ("You Ain't Gonna Need It") mantra, coupled with approaching a project from a divide and conquer perspective (yeah, pg would pretty much hate this). First break the project into its key deliverables and its 'nice to haves'. Once all the key deliverables are complete, then the project is complete; 'nice to haves' aren't factored into the completeness equation for the project. Once you know what your key deliverables are, then order them in terms of dependency: if deliverable A requires that deliverable B be completed before deliverable A can be completed, then focus on deliverable B first. Now that you know what you're supposed to be working on, you can get started on the deliverable at the root of your dependency tree, but whilst working on it ensure that you're only adding the functionality necessary to complete the current deliverable. As you work your way through your deliverables, refactor the previous deliverables as necessary to make your current deliverable work. For instance, if your root deliverable wasn't required to be thread-safe when you first wrote it, but your new deliverable requires it to be thread-safe, then work your way back through your deliverables refactoring as necessary in order to meet the requirements for your current deliverable.
By sorting your deliverables into dependency tree, you can ensure that you can properly apply YAGNI. It's very tempting for a perfectionist to turn into an architecture astronaut, and spend weeks or months mapping out the entire solution and all its edge cases before they've even started to work on a single deliverable; by keeping your deliverables in a dependency tree and working from the least to the most dependent, you force yourself out of this mindset. By applying this method, you also force yourself away from analysis paralysis, because you're not permitting yourself to consider patterns or architecture until the project's current deliverable necessitates it.
It's worth noting that this method won't work for all projects, as it requires a good understanding of what the deliverables for the project actually are before you can apply it. It also may not work for you at all, since it's all down to personal experience, but I've personally found that forcing yourself to focus only on the concrete deliverables ensures that you don't end up stalling yourself in analysis, and gives you lots of little pep boosts in the form of finished deliverables and refactorings.
Nonetheless, good luck finding a cure that works for you.
However, assuming that you're accurate in your statement that your projects were unfinished, then it would appear that you need to question why that's the case, as we cannot infer that the traits you've ascribed to yourself are the cause of project failures without knowing more about the other variables in the equation. For instance, the projects may well all have been failures for no fault of your own: scope creep, management interference, poor teamwork (or poor team members), or any number of other variables could be responsible. But since this is not something we can address at this point, let's assume that your project failures are indeed a result of your perfectionism.
The easiest way (in my experience) to 'cure' perfectionism in software is to follow the YAGNI ("You Ain't Gonna Need It") mantra, coupled with approaching a project from a divide and conquer perspective (yeah, pg would pretty much hate this). First break the project into its key deliverables and its 'nice to haves'. Once all the key deliverables are complete, then the project is complete; 'nice to haves' aren't factored into the completeness equation for the project. Once you know what your key deliverables are, then order them in terms of dependency: if deliverable A requires that deliverable B be completed before deliverable A can be completed, then focus on deliverable B first. Now that you know what you're supposed to be working on, you can get started on the deliverable at the root of your dependency tree, but whilst working on it ensure that you're only adding the functionality necessary to complete the current deliverable. As you work your way through your deliverables, refactor the previous deliverables as necessary to make your current deliverable work. For instance, if your root deliverable wasn't required to be thread-safe when you first wrote it, but your new deliverable requires it to be thread-safe, then work your way back through your deliverables refactoring as necessary in order to meet the requirements for your current deliverable.
By sorting your deliverables into dependency tree, you can ensure that you can properly apply YAGNI. It's very tempting for a perfectionist to turn into an architecture astronaut, and spend weeks or months mapping out the entire solution and all its edge cases before they've even started to work on a single deliverable; by keeping your deliverables in a dependency tree and working from the least to the most dependent, you force yourself out of this mindset. By applying this method, you also force yourself away from analysis paralysis, because you're not permitting yourself to consider patterns or architecture until the project's current deliverable necessitates it.
It's worth noting that this method won't work for all projects, as it requires a good understanding of what the deliverables for the project actually are before you can apply it. It also may not work for you at all, since it's all down to personal experience, but I've personally found that forcing yourself to focus only on the concrete deliverables ensures that you don't end up stalling yourself in analysis, and gives you lots of little pep boosts in the form of finished deliverables and refactorings.
Nonetheless, good luck finding a cure that works for you.
Sure, but that's what code samples are for. If I send you code samples, and I can't explain to you what they mean or how I built them, or describe a variation of your choice about them, then you can assume that I don't know what I'm talking about. You can do this over the phone. There are endless, quality, revealing questions you can ask about provided code samples that are far, far, far, far superior to asking the equivalent of reciting the ABCs.
No code sample? Get some. Won't provide some? Don't bring them in for an interview.
The point I'm making is that you can pre-qualify candidates in a LOT of ways before you even bring someone into the office. If I get into your office and you ask me dumb, basic questions, then you haven't screened me effectively. You should theoretically be able to make those determinations before I ever step through the front door of your office.
No code sample? Get some. Won't provide some? Don't bring them in for an interview.
The point I'm making is that you can pre-qualify candidates in a LOT of ways before you even bring someone into the office. If I get into your office and you ask me dumb, basic questions, then you haven't screened me effectively. You should theoretically be able to make those determinations before I ever step through the front door of your office.
Sure, but that's what code samples are for. If I send you code samples, and I can't explain to you what they mean or how I built them, or describe a variation of your choice about them, then you can assume that I don't know what I'm talking about. You can do this over the phone. There are endless, quality, revealing questions you can ask about provided code samples that are far, far, far, far superior to asking the equivalent of reciting the ABCs.
That seems like a reasonable idea, but we've tried that before, and it's just a terrible filter. Let me try to make a more general claim: anything that lets the candidate have outside resources or unlimited time is going to be a bad filter. In this case, the candidate can prep the code sample and be able to explain it well.
That seems like a reasonable idea, but we've tried that before, and it's just a terrible filter. Let me try to make a more general claim: anything that lets the candidate have outside resources or unlimited time is going to be a bad filter. In this case, the candidate can prep the code sample and be able to explain it well.
How do I bring in code samples when all of the code I write has been for my previous employers and therefore is owned by them? Can't I be good at what I do without spending free time away from family and hobbies doing it even more?
Wait is 7 years all I need to be a 'senior engineer'?
And what do I do if I don't like to release my code publicly? Should I not be hired by any company if I'm not personally a fan of open source (hypothetically)?
And what do I do if I don't like to release my code publicly? Should I not be hired by any company if I'm not personally a fan of open source (hypothetically)?
In fact some companies explicitly prohibit publishing code publicly without requesting special permission.
I don't think candidates should be excluded based on the lack of a github repo.
I don't think candidates should be excluded based on the lack of a github repo.
Its no that difficult to create a github project that can be completed in a weekend. I created the hacker new karma tracker and weedprices.biz in one weekend each.
But would you really make hiring decisions based on either of those projects? Software development is 'relatively' easy when your project is <1000 LOC. It becomes harder as the project grows. And it's the ability to grow the project what you should make the hiring decisions on.
Yeah but judging someone's ability to code by several good <1000LOC projects is probably better than the sorts of coding problems you have time to give someone during a coding interview.
That's actually a good point I have not though of before. I considered your Github account to be the place where you'd show off your l33t sk1llz, as opposed to show off code similar to the code you'd write during interviews.
Sure but then if this becomes a "must have simply to have the opportunity to interview" then it loses all the value it can have to reveal what the person can do. And I do believe some people have no time for this. Having worked at Apple for some time, I guarantee my sparse time, when there was some, was more outside of any coding and still I will never show outside a piece of code I have written in this company. This does not mean the coding skills I have should be considered as good or sufficient, they may or not match the one needed for a position. Having been also in the position to be on the interviewer side, especially in startup, seeing the candidate in person reminds often the deciding point.If some code on github exists, it simply can "speed up" a little this part of the process.
Personally I found the "Smart and get things done" book by Spolsky a good read on how to conduct interviews
And I could copy them with minor modifications and claim I designed it all, in only a few minutes.
I agree, but I understand its part of the game played. I have 13 years of IT experience, but still contribute to open source projects on Github, as my day job codebase can't be released/be part of my portfolio.
As soon as things like that become "part of the game" they start losing their signalling value.
Exactly why I cringe at every one of these "my awesome interview tips/tricks/hacks/etc". The very fact that you publicly stated it makes it lose significant value. Most forms of testing are high value until the test becomes the goal, then its worthless. I guess having a handful of hits on their block one afternoon is more valuable to them than a useful hiring signal.
[deleted]
I would wonder why you don't like to release your code publicly, or at least have code samples ready to show. If I asked you for code samples and you didn't have any, I'd ask you to complete some work-at-home tasks, as I mentioned in my previous post. Those code samples would probably be enough.
If you refused to send me code samples, I wouldn't bring you in for an interview.
If you refused to send me code samples, I wouldn't bring you in for an interview.
For example:
1) Work for a company that does not allow you to post code that you write at work (fairly common)
and 2) Don't have time / don't want to spend time on homework for an interview
Combined with: a) Do not code for fun at home
or
b) Code for fun, but in something so completely unrelated that it's not useful (8 bit microcontroller code, say)
or
c) Code for fun, but not seriously with any kind of quality
If you gate your interviews on who has public code repositories, you're missing out on a LOT of qualified people.
1) Work for a company that does not allow you to post code that you write at work (fairly common)
and 2) Don't have time / don't want to spend time on homework for an interview
Combined with: a) Do not code for fun at home
or
b) Code for fun, but in something so completely unrelated that it's not useful (8 bit microcontroller code, say)
or
c) Code for fun, but not seriously with any kind of quality
If you gate your interviews on who has public code repositories, you're missing out on a LOT of qualified people.
1) Not a problem and very understandable. I don't require work-related samples, just code samples in general.
2) Also understandable, but it's really no different than doing it on a whiteboard in my office. Might as well take 30 minutes to write some code in an environment where you're comfortable versus doing it on a whiteboard where you're under pressure, yes?
A would rule you out as a candidate for me. Passion is almost always a requirement. B would be acceptable -- in general, language doesn't matter. It's the ability to write code and explain it that matters. C would be a tossup. If you write crap code for fun, then why would you write better code for real? But I get that. Sometimes I write code for fun just to see if something works, and I never refactor it to make it more efficient or whatever. That's understandable. Again, it's more about the ability to master the basics to begin with.
I can teach you to be a better programmer, provided you understand the basics (which your code samples should demonstrate). I don't have time to teach you the basics (unless I'm specifically hiring an intern or something.)
Also, consider that in my original post, I said this is my process and how I do things. It has worked very well for me so far. I may rule you out, but I'm willing to bet that there are others equally as good (or better) than you that are willing to do what I consider to be far less annoying than the way interviews are conducted now.
I don't want to waste your time -- nor my own time. That's the end game here. By having code samples ready for me, you are eliminating a not insignificant amount of redundancy for both of us.
A would rule you out as a candidate for me. Passion is almost always a requirement. B would be acceptable -- in general, language doesn't matter. It's the ability to write code and explain it that matters. C would be a tossup. If you write crap code for fun, then why would you write better code for real? But I get that. Sometimes I write code for fun just to see if something works, and I never refactor it to make it more efficient or whatever. That's understandable. Again, it's more about the ability to master the basics to begin with.
I can teach you to be a better programmer, provided you understand the basics (which your code samples should demonstrate). I don't have time to teach you the basics (unless I'm specifically hiring an intern or something.)
Also, consider that in my original post, I said this is my process and how I do things. It has worked very well for me so far. I may rule you out, but I'm willing to bet that there are others equally as good (or better) than you that are willing to do what I consider to be far less annoying than the way interviews are conducted now.
I don't want to waste your time -- nor my own time. That's the end game here. By having code samples ready for me, you are eliminating a not insignificant amount of redundancy for both of us.
Sorry, but that's silly. We don't expect doctors to do amateur surgery at home. We don't expect pilots to fly their kids to school in a microlite, and we don't expect lawyers to sue people for fun.
"Codes for fun" is HR-compliant jargon for "20-something, no kids, willing to work unpaid overtime" and it'll be caught out as soon as some "sues for fun" lawyer can be bothered to mount a case.
"Codes for fun" is HR-compliant jargon for "20-something, no kids, willing to work unpaid overtime" and it'll be caught out as soon as some "sues for fun" lawyer can be bothered to mount a case.
Asking some one to work for free before you interview them does not give a terribly good signal as to how good you would be as an employer.
I'm not asking you to work for free. I'm asking you to provide code samples. There's a big difference. It's no different than coming into my office and coding on a whiteboard for me.
And for your other argument, I have a full time job but will sometimes take very short term (5-10 hours of work) contracts for interview purposes. Usually this is a last step before getting a job offer, more as a way to gauge whether I'd work well with the team than whether I can code in general.
And for your other argument, I have a full time job but will sometimes take very short term (5-10 hours of work) contracts for interview purposes. Usually this is a last step before getting a job offer, more as a way to gauge whether I'd work well with the team than whether I can code in general.
It doesn't have to be for free. I know someone who would "hire" potential candidates for a 2-week contract, and based their skill on the code they write during that time. If the candidate doesn't end up getting hired afterwards, he still gets paid for his time. It's a win-win.
Doesn't work if you are employed already though.
In the case of my company, if you're not a fan of open source, you wouldn't have a place.
I agree with most of these points, but my team lead brought up an excellent point while we were interviewing someone - my team lead had the candidate do a stupid easy algorithm question just to see whether the candidate was the real deal, and explained to the candidate is that anyone could list a Github profile as part of their resume.
The candidate was understanding, and did it - he didn't have to have exact syntax, I was happy enough seeing psuedocode since I already took a peek at the Github profile that was a part of his resume.
It only wasted a few minutes of his time whiteboard coding, and it wasn't intense, so it gave him a nice easy way for him to explain his thought process. I asked relevant questions to the code that he wrote, and it lead to a good discussion on some things.
I felt that we were mutually happy with the experience, as he subsequently accepted our job offer.
On the whole though, asking stupid questions is a waste of both side's time.
The candidate was understanding, and did it - he didn't have to have exact syntax, I was happy enough seeing psuedocode since I already took a peek at the Github profile that was a part of his resume.
It only wasted a few minutes of his time whiteboard coding, and it wasn't intense, so it gave him a nice easy way for him to explain his thought process. I asked relevant questions to the code that he wrote, and it lead to a good discussion on some things.
I felt that we were mutually happy with the experience, as he subsequently accepted our job offer.
On the whole though, asking stupid questions is a waste of both side's time.
I think anyone can list a Github profile as part of their resume, absolutely. That's why I said you should ask questions about the contents of that Github profile. Explain why you built X and how Y works and if you could do Z differently, what would change? What were the biggest problems with this project and what did you think would be hard about that project but turned out to be easy? And so on.
IMHO, there's no need for whiteboard coding.
Having said that, if you are going to ask me to do some whiteboard coding, I would greatly prefer something like you described -- a high level response that tests my thought processes. You can see my code on Github, I shouldn't have to write some on a board. But I'll be happy to explain thought processes while solving a problem.
IMHO, there's no need for whiteboard coding.
Having said that, if you are going to ask me to do some whiteboard coding, I would greatly prefer something like you described -- a high level response that tests my thought processes. You can see my code on Github, I shouldn't have to write some on a board. But I'll be happy to explain thought processes while solving a problem.
I can see both POVs, and they definitely have merit. In my own interview for my current job, I was very happy to not have to code anything - the team leads who interviewed me already found it obvious that I was extremely smart & knowledgeable despite having less than a year of experience.
Not that I would have minded coding on the fly or answering stupid brainteasers - I grew up figuring those things out. Those leave me with negative impressions of the company though, and may lead me to demand a higher salary to accept a position.
Not that I would have minded coding on the fly or answering stupid brainteasers - I grew up figuring those things out. Those leave me with negative impressions of the company though, and may lead me to demand a higher salary to accept a position.
"Know that they can code" and "know how they code" are different things, and it's possible the latter could effect how well they fit into your team. Whether an interviewer can actually do a good job assessing that is another question...
Excellent point. Those are definitely two different things and are both important, but I would argue that you can determine the "how they code" component during the interview as questions about previous projects, rather than making them write code in front of you. And again, a short-term contract would also work to solve this goal while not wasting my time.
Very good point, though.
Very good point, though.
"How they code" can be slightly answered by looking at the commit history of their code samples (Which they have on github / bitbucket / other site... right?)
Not really. I'm talking process more than result. The question is whether their process and your processes mesh well, and watching them work on something could well provide information that static commit histories lack.
As mentioned, I'm a bit skeptical that an interviewer can reliably extract that information.
As mentioned, I'm a bit skeptical that an interviewer can reliably extract that information.
THIS - So true, I am a Ruby developer and could probably earn an extra 20k if I changed jobs tomorrow, however I will not sit through an interview being asked stupid questions like "What is MVC", "solve this big O problem" or implement some algorithm that I will only ever need to use during interviews & can then forget about...that type of interview is very telling of the companies work environment & the type of people you will have me working with.
I will send you code samples or show you my contributions to open source projects so that you know I can code, happy to discuss these until you are happy.
What is far more important is to find out about me, do you like me, can you work with me & tell me honestly about your dam culture - do you expect everyone to be at there desk at precisely at 8am, work a minimum of 80 hours per week? How is productivity measured? Do you expect me to attend some "team building" weekend nonsense when I could be spending time with my wife instead.
I will send you code samples or show you my contributions to open source projects so that you know I can code, happy to discuss these until you are happy.
What is far more important is to find out about me, do you like me, can you work with me & tell me honestly about your dam culture - do you expect everyone to be at there desk at precisely at 8am, work a minimum of 80 hours per week? How is productivity measured? Do you expect me to attend some "team building" weekend nonsense when I could be spending time with my wife instead.
>In that case, send some problems for them to work on at home. Hopefully, these are dumbed-down but real-world problems your company has faced in the past.)
As an entry level applicant, I can't stress how important this was to gaining insight into both how I function when given a deadline and what kind of work is in store for me. It also lets me know what I might need to study in the future or what I need to study immediately.
As an entry level applicant, I can't stress how important this was to gaining insight into both how I function when given a deadline and what kind of work is in store for me. It also lets me know what I might need to study in the future or what I need to study immediately.
As the last round of a 3-hour interview I met the engineering manager whose first question was, "Do you know Perl?" and I said no and he said "Sorry, we need someone who knows Perl" and sent me home. After 3 hours of wasting my time! Not naming names, but Screw you and burn in hell for eternity SAP!
Please allow googling in an interview. How many people today actually write code without a Google search? I bet 90% of the Google engineers do that and still able to write really brilliant code.
Love this! Was in a coding interview once where they just gave you a problem and you were given laptop and time to code out a solution using whatever you would normally use ie stack overflow. First interview I've had where I felt like it was a fair test of my programming capabilities.
Of course this requires that you design the question in a way that is not completely google-able, but real world programming is not just about solving a trick question but being able to be resourceful enough to find a real working solution.
Of course this requires that you design the question in a way that is not completely google-able, but real world programming is not just about solving a trick question but being able to be resourceful enough to find a real working solution.
I guess I should say restricted gooling. I like take home interviews. It's harder because you are given more time and more personal space and psychology tells us we will try to design the best algorithm, the most scalable, yet complex solution. If I were to conduct such interview, such solution can be a red flag.
But you know, interview is hard. I also think interview questions don't have to change a lot. I heard Box always asks people to design an evaluator. I thought that wasn't so hard but when I started thinking about an evaluator, I started getting distracted by all the cases, even when I wanted to just implement a state diagram.
But you know, interview is hard. I also think interview questions don't have to change a lot. I heard Box always asks people to design an evaluator. I thought that wasn't so hard but when I started thinking about an evaluator, I started getting distracted by all the cases, even when I wanted to just implement a state diagram.
I had an interesting question once: They gave me a whiteboard problem that I'd studied about a week ago.
So I told them. "Look, I did this problem on my own a little while ago." They chuckled and made it harder, which was fine. :-)
So I told them. "Look, I did this problem on my own a little while ago." They chuckled and made it harder, which was fine. :-)
That's definitely the way to go. If you try to "remember" an answer you read or even previously completed while in an interview there's a good chance you won't instantly recall the answer and often the problem is slightly adjusted from your first encounter. It makes it difficult to see the problem with new eyes http://lesswrong.com/lw/k7/original_seeing/
There are some serious benefits to bringing up your prior exposure to a question in a positive light. When sending out problems interviewees are likely to encounter again I include the group's "déjà vu guide" http://codingforinterviews.com/seen-question-before
There are some serious benefits to bringing up your prior exposure to a question in a positive light. When sending out problems interviewees are likely to encounter again I include the group's "déjà vu guide" http://codingforinterviews.com/seen-question-before
I am at the "write a function that reverses a string without creating a new string" question and this is the answer on the site:
def reverse(str):
left_ptr = 0
right_ptr = len(str) - 1
middle = len(str) / 2
while left_ptr <= middle:
# swap
temp = str[left_ptr]
str[left_ptr] = str[right_ptr]
str[right_ptr]= temp
Not to mention, strings are immutable in Python.
You can't even assign by index with strings
str[0] = ... will trigger an exception
str[0] = ... will trigger an exception
I see that and want to do it by appending backwards off the end of the string, then move the pointer to the new beginning. Is that "creating a new string"? Or just making a poopy on the floor for the garbage collector?
"Double the length of the old string and then cut it in half" isn't against the rules, right?
"Double the length of the old string and then cut it in half" isn't against the rules, right?
I don't know if it is against the rules, my approach was a recursive function.
[deleted](1)
I would answer :
def reverse(str):
return str[::-1]
That creates a new string (the one returned) :)
Thats what I would do. Then again, I always get rejected when I do these type of interviews...
def reverse(string='abc123'):
for pos in xrange(-len(string)+1, 1):
string += string[abs(pos)]
return string[len(string)/2:]
Woops--yeah, that's pretty bad. Somehow this one made it through testing. Fixing!
Yup.
Nice site, could not do the practise questions though since I am not member of any of the social sites needed. Suggeting the option to proceed without the saving feature.
Any time I've been a part of hiring new talent, I'm looking at three things:
1. How you process information. I'm not going to be impressed if someone at the table says 'Microsoft' and you cringe. 2. Can you admit to not knowing everything? You'd be shocked how big of an issue this is. 3. Are you willing to adapt? In a smaller team, you have to bend and be willing to take on new challenges.
1. How you process information. I'm not going to be impressed if someone at the table says 'Microsoft' and you cringe. 2. Can you admit to not knowing everything? You'd be shocked how big of an issue this is. 3. Are you willing to adapt? In a smaller team, you have to bend and be willing to take on new challenges.
This is a really comprehensive list of tips, thanks Parker!
Definitely including this in next week's Coding for Interviews newsletter.
Definitely including this in next week's Coding for Interviews newsletter.
That was very useful, thanks. All pragmatic, useful advice and no generic bs.
Edit: Annoying that you cannot try practice questions without logging in though.
Edit: Annoying that you cannot try practice questions without logging in though.
The key point from the article: Communicate well.
This is really very true in the corporate world. The better you know how to communicate, the more likely it is that you will succeed in your chosen profession.
This is really very true in the corporate world. The better you know how to communicate, the more likely it is that you will succeed in your chosen profession.
For http://www.interviewcake.com/question/largest-stack
There's a simple solution that requires no additional space.
Disclaimer: Code is not tested or given the love it deserves.
There's a simple solution that requires no additional space.
Disclaimer: Code is not tested or given the love it deserves.
Class Item():
def __init__(value):
self.value = value
self.next = None
self.next_largest = None
Class maxStack():
def __init__():
self.top = None
self.largest = None
def push(value):
i = Item(value)
i.next = self.top
self.top = i
if value >= self.largest:
i.next_largest = self.largest
self.largest = i
def pop():
v = self.top.value
if self.largest == self.top:
self.largest = self.largest.next_largest
self.top = self.top.next
return v
def getLargest():
return self.largestThis solution takes O(n) additional space...
Just as a heads up, after I finish an interview question neither button works (I'm an expert or review later). Clicking on each doesn't seem to do anything. The only way for me to see additional questions is to head back to the homepage and re-click 'run some practice questions.'
I think this error is fixed now. Thanks for the report! Let me know if you're still having trouble.
Thanks for the report! Having trouble reproducing on my end ... are you logged in?
Yes, I am. Here's what shows up in the dev console when I click "I'm an expert"
PUT http://www.interviewcake.com/api/v1/viewings/ 403
(FORBIDDEN) angular.min.js:99
(anonymous function) angular.min.js:99
n angular.min.js:95
l angular.min.js:94
DjangoRESTResource.(anonymous function) angular-django-rest-
resource.js:12
DjangoRESTResource.(anonymous function) angular-django-rest-
resource.js:18
$scope.updateViewing base.js:31
$scope.markAsComfortable base.js:13
$scope.feelExpertPress base.js:15
(anonymous function) angular.min.js:72
(anonymous function) angular.min.js:144
e.$eval angular.min.js:88
e.$apply angular.min.js:88
(anonymous function) angular.min.js:144
x.event.dispatch jquery.js:5095
v.handle
PUT http://www.interviewcake.com/api/v1/viewings/ 403
(FORBIDDEN) angular.min.js:99
(anonymous function) angular.min.js:99
n angular.min.js:95
l angular.min.js:94
DjangoRESTResource.(anonymous function) angular-django-rest-
resource.js:12
DjangoRESTResource.(anonymous function) angular-django-rest-
resource.js:18
$scope.updateViewing base.js:31
$scope.markAsComfortable base.js:13
$scope.feelExpertPress base.js:15
(anonymous function) angular.min.js:72
(anonymous function) angular.min.js:144
e.$eval angular.min.js:88
e.$apply angular.min.js:88
(anonymous function) angular.min.js:144
x.event.dispatch jquery.js:5095
v.handle
Got it. Digging into this now. Meantime, you might try another auth method? There's also this secret page to walk through the questions by hand: http://www.interviewcake.com/all-questions
Sorry about that!
Sorry about that!
Selecting cancel during the login results in a 500 error and long list of django debug information that you might want to tidy up.
Thanks for the report. Fixed, and keys cycled.
Same problem. Looks like we're getting a 403 posting to the server after the initial question. I'm logged in with G+.
I'm also having the same error
Nice article, but not that good site design. Not to mention the solutions for most of its problem are either flawed or fundamentally not correct.
Author of the site wrote solutions in Python, but obviously he/she doesn't understand Python. Isn't that against what the article suggested?
Author of the site wrote solutions in Python, but obviously he/she doesn't understand Python. Isn't that against what the article suggested?
Doesn't look like there's a whole lot of coding in that coding interview. Apparently the article assumes that "coding interview" involves a whiteboard, rather than a keyboard.
We segment our interviewing into different sections. One person will do a specific functional competency evaluation which consists of writing code in an IDE to see whether you can write code. This portion of the interview is not about analytical thinking skills, people skills, or "tell me about a problem you've solved". It's about writing code. The interviewer is looking to see how many hints you need to get at working code, how well your solution is structured, and getting an overall feel for how you program.
We segment our interviewing into different sections. One person will do a specific functional competency evaluation which consists of writing code in an IDE to see whether you can write code. This portion of the interview is not about analytical thinking skills, people skills, or "tell me about a problem you've solved". It's about writing code. The interviewer is looking to see how many hints you need to get at working code, how well your solution is structured, and getting an overall feel for how you program.
> Leave yourself plenty of room. You may need to add code or notes in between lines later. Start at the top of the board and leave a blank line between each line.
That's a good idea I'll adopt. It looks messy when you start trying to shoehorn in a missed line somewhere.
That's a good idea I'll adopt. It looks messy when you start trying to shoehorn in a missed line somewhere.
This is why I wish all programming interviews would just put me in-front of an Ubuntu machine and let me start up vim.
Also, someone should develop a vim & emacs clone with super big font so it'd be good on a big-screen for coding-interviews.
Also, someone should develop a vim & emacs clone with super big font so it'd be good on a big-screen for coding-interviews.
You can change the font size.
This reads even better as a "how to be a more insightful and incisive thinker and presenter", and anyone who just wants to use this excellent advice for interviews is missing the point!
Also found this book helpful for more practice questions & solutions: http://interviewsolutionsmanual.com/
I think if you offer to code in interview its not right and dont resume good Man and company lost cool thinking programmer. In root its going from escape from peoples - such company not need with anybody. They must offer not coding, the must offer work and good things. Programming solve not coding it solve to make effective and easy. Coding in interview is monkey fun.
I'm just glad I work in python mostly and no longer have to deal with off by one errors...
quiz != interview
This is aweasome
Congrats!
Not to mention that this is not exactly an obscure trick. If you've seen it a few times it is trivial to remember the trick and apply it. It's been awhile since I've looked at the 'interview questions exposed' type books or websites, so it didn't leap immediately to mind. Would you really select against me because I haven't read such things?
edit: my phrasing was way to strong and unfriendly. I reworded the first sentence.