|
DONT THREAD ON ME posted:I mean, I feel like I can often tell if someone is bullshitting me. People who have spent a lot of time actually programming will have actual opinions about it and will be able to engage me in an informal and interesting discussion. If I can succeed in having a real discussion with them, I often don't feel the need for them to 'prove it' by writing a for loop. Agree, IMO it's really easy to find out how good someone is by just talking to them about computers and software and stuff. It's way more effective too. Literal FizzBuzz and things like of that level of complexity are a useful filter for the people that can't code *at all*, but whiteboarding and even take homes are basically useless at determining how good someone is beyond an "has a basic level of competence". I'm pretty happy with current jobs process, which has a take home and 4x 45 min 1:1 interviews (one about the take home, one team specific one (for our team, talk about ops and linux and debugging), one high level system design, and one about teamwork/collaboration). Had a discussion with my coworker the other day about the take home, I grade them really easily as a binary pass/fail because in my opinion it's purpose is FizzBuzz out complete morons, and set up a shared code base to discuss in the interview. He wanted to grade them really harshly to weed it down to the absolute best programmers, which I think is really misguided and error-prone (both false negatives and false positives).
|
#
?
Feb 3, 2019 21:05
|
|
|
|
| # ? Apr 25, 2024 07:34 |
|
|
New Yorp New Yorp posted:I have had great conversations about programming in interviews and then seen the candidate go on to be unable to solve FizzBuzz. Being able to bullshit convincingly is a soft skill that some people have honed, especially if they've done consulting before. But maybe they couldn't get through FizzBuzz because they suck at white boarding? I'm one of the people who really struggles with white boarding in an interview (but I have no problem doing it with real coworkers). I could see myself failing FizzBuzz in an interview setting, even though it's a trivial problem that I can solve in minutes in a comfortable setting. I am perhaps an extreme case, but I've no doubt many others struggle a lot with this. DONT THREAD ON ME fucked around with this message at 21:50 on Feb 3, 2019 |
|
#
?
Feb 3, 2019 21:10
|
|
|
Che Delilas posted:I should also note that these people never seem to have anything to show as an alternative to whiteboard coding, and they can never talk in specifics about what they did at their old jobs and why they made some of the decisions they did. It's all bullshitting on every level. I hate coding questions, for all the reasons mentioned, but it certainly feels like there are a lot of frauds who don't want to lose their seat on the gravy train in this industry. How the hell do we weed them out if we don't ask at least one question about one of the core job duties they're going to have? It's not just coders. My company had one UI guy interview who couldn't manage to give us anything at all on his working process beyond "I would make an initial mockup and then iterate with feedback" even when presented with fairly specific "we're not really sure what to do here???" UI problems we currently have. DONT THREAD ON ME posted:But maybe they couldn't get through FizzBuzz because white boarding sucks? Fizzbuzz doesn't need a whiteboard. "Oh, you loop through, if clause modulo 3 equals zero and 5 equals zero fizzbuzz, if clause modulo 3 equals zero fizz, if clause modulo 5 equals zero buzz, else print number." At least personally, that's literally all I'd be looking for an interview with one of the real shallow fizzbuzz-type problems. Roadie fucked around with this message at 21:52 on Feb 3, 2019 |
|
#
?
Feb 3, 2019 21:49
|
|
|
Anyhow posting because I'm looking for a job and want to change directions a bit. I feel like I'm going through a second level of imposter syndrome. I'm self-taught and the companies I've been at have all been great stepping stones for me, but I've never really worked somewhere that I felt was actually competent. So even though I've been an important member of the programming teams I've been on, I still have a lot of doubt about whether I can hack it at a 'real' company. Obviously this is mostly a dumb feeling which is why I'm posting. Right now though i'm focusing on whiteboarding because that's the area that gives me the most anxiety in interviews.
|
|
#
?
Feb 3, 2019 21:57
|
|
|
DONT THREAD ON ME posted:But maybe they couldn't get through FizzBuzz because they suck at white boarding? Yeah I feel this 100%. “I know there are lots of bad candidates because they fail my process, so I need my process to weed out all the bad candidates” is not exactly bulletproof logic.
|
|
#
?
Feb 3, 2019 22:00
|
|
|
I also just don't approach an interviewee as if they're actively trying to deceive me. Perhaps that is naive. I have been openly deceived in interviews, and in the two cases where the candidate was hired, they were fired very quickly due to terrible performance. These were contractors at BIGCORP who we could get rid of easily, though, so I get that it's not an approach that you can always take. Also it was really HRs fault for making us interview lots of lovely unvetted candidates from TEK SYSTEMZ. On the flip side, giving people the benefit of the doubt has resulted in some really, really great hires. DONT THREAD ON ME fucked around with this message at 22:16 on Feb 3, 2019 |
|
#
?
Feb 3, 2019 22:09
|
|
|
DONT THREAD ON ME posted:I also just don't approach an interviewee as if they're actively trying to deceive me. Perhaps that is naive. I have been openly deceived in interviews, and in the two cases where the candidate was hired, they were fired very quickly due to terrible performance. These were contractors at BIGCORP who we could get rid of easily, though, so I get that it's not an approach that you can always take. Also it was really HRs fault for making us interview lots of lovely unvetted candidates from TEK SYSTEMZ. 
|
|
#
?
Feb 3, 2019 22:17
|
|
|
I think the problem is that teams always apply a "one size fits all" approach to interviewing people. I think some people do really well with white boarding, some people do really well with open discussions, some people do well with take homes, some people have so much github activity and you don't even need to vet their coding skills at all. When I approach an interview, my goal is to help the candidate prove that they're a good fit for the position. Ideally, I'd ask them how they like to be interviewed, and customize the interview to their needs. This is, of course, more costly than other approaches. But honestly, it's not really that hard to develop a few different interview tracks. To put it another way: companies generally customize the interview process to their own needs, and I think they'd get more mileage out of customizing the interview process to the candidates needs. Of course, the companies needs are very important as well, but at the very least, we should be at least be considering the candidate's needs. DONT THREAD ON ME fucked around with this message at 22:39 on Feb 3, 2019 |
|
#
?
Feb 3, 2019 22:25
|
|
|
DONT THREAD ON ME posted:But I think it's the right way.
|
|
#
?
Feb 3, 2019 22:27
|
|
|
wins32767 posted:What are you trying to optimize for? DONT THREAD ON ME fucked around with this message at 22:36 on Feb 3, 2019 |
|
#
?
Feb 3, 2019 22:32
|
|
|
Mao Zedong Thot posted:Literal FizzBuzz and things like of that level of complexity are a useful filter for the people that can't code *at all*, but whiteboarding and even take homes are basically useless at determining how good someone is beyond an "has a basic level of competence". Well first, we're asking something a little bet more involved than fizzbuzz, but not by much, and basic competence is all we're assessing with it. And a lot of people don't make the cut despite a decade of experience on their resume. The majority of the interview is generally having conversations about their previous experience, what contributions they made, "tell me a story" kinds of questions. We don't spend hours on a battery of CtCI tests and we try to keep it as relevant as we can. For instance we're doing "old nasty monolith -> something maintainable and scalealbe" right now (and will be for some time), and so we ask them about their experience doing that kind of thing. But at the end of the day we also want to know if they can code. And my previous post had a whole paragraph about how these people never have any alternatives, either. If they could show me an example of their work and have a conversation with me about it, great! That's good enough for me, and I've skipped coding questions in the face of that kind of evidence before. The people I'm complaining about never do. All that said, we're aware we could improve our process. I just honestly don't know how. TooMuchAbstraction posted:That said, a six-month ramp-up period is not great. Ideally you'd be making substantial contributions (proportional to your experience level) in three months. You're being way too polite about that - it's rancid poo poo and everyone knows it. We got in some new management last year and they've finally given us the mandate to spend some time demolishing a lot of the nonsense, and the authority to tell management to pound sand if they start asking for hacky shortcuts to meet deadlines. It's a nice change but we have a long way to go - we've got 15 years of short-term decision making to overcome.
|
|
#
?
Feb 3, 2019 22:47
|
|
|
Che Delilas posted:Well first, we're asking something a little bet more involved than fizzbuzz, but not by much, and basic competence is all we're assessing with it. How do you know this?
|
|
#
?
Feb 3, 2019 23:59
|
|
|
remote interviews update Flew to Nashville last week. Flight there was nice. Met with senior director dude, asked about my experience, we talked about the company and the direction it's taking. The only "skill check" he asked was "how would you secure an API?" to which my response was to use HTTPS, and use a cookie or bearer token. Seemed to pass his test. The second round was with a few line-level engineers, they all seemed cool. No whiteboarding, just trading stories about stuff I've done, stuff that their teams have done, and a little shop talk about the take-home project I did. They all seemed nice. Third round was with two managers which was more high-level company stuff, followed by a whiteboard-type question that wasn't "write some code on the board" but instead went a bit like this: "I'm the CEO and you're my engineer. I have two buildings with a wire connecting the two. The amount of data being sent is more than what the wire can handle. I need this fixed in two weeks. Will you commit to solving this problem, and how will you do so?" I came up with a dozen or so strategies, one of which he said he'd never heard in 20 years of asking the question. The punch line to the question is, after exahusting options, the CEO still says "we can't do those. Will you commit to resolving this?" to which the Right Answer is "no". The idea was to test that the interviewee is willing to say no to authority. Guess he hadn't already picked up that I have major authority issues. Anyway they seemed to like me, I'm expecting to get an offer this week. In the meantime I'm meeting in-person with a remote worker in my region for another company tomorrow. Should be fun  E: interview went over and I very narrowly caught my flight home that day. Scariest part of the whole deal lol Careful Drums fucked around with this message at 01:40 on Feb 4, 2019 |
|
#
?
Feb 4, 2019 01:15
|
|
|
raminasi posted:How do you know this? I still don't really believe it but apparently a lot of people who get paid to write code can't write fizzbuzz on the spot. if that's true then it's probably really good to filter out duds quickly.
|
|
#
?
Feb 4, 2019 01:15
|
|
|
Careful Drums posted:I still don't really believe it but apparently a lot of people who get paid to write code can't write fizzbuzz on the spot. if that's true then it's probably really good to filter out duds quickly. No, I'm trying to make the opposite point. fizzbuzz itself is in kind of a weird spot because it's so widely known, but how do we know that other problems of its class effectively serve as a dud filters? What is the evidence that fumbling with fizzbuzz-esque problems means that someone is going to be an unproductive developer? Because I've never seen anything concrete; it's always supposed to just be obvious, somehow.
|
|
#
?
Feb 4, 2019 01:27
|
|
|
raminasi posted:No, I'm trying to make the opposite point. fizzbuzz itself is in kind of a weird spot because it's so widely known, but how do we know that other problems of its class effectively serve as a dud filters? What is the evidence that fumbling with fizzbuzz-esque problems means that someone is going to be an unproductive developer? Because I've never seen anything concrete; it's always supposed to just be obvious, somehow. Oh okay. I see your point, and idk. There's no concrete evidence AFAIK. I wouldnt hire someone that couldn't fizzbuzz. But I'd probably get a useful code sample in one of half a dozen other ways first.
|
|
#
?
Feb 4, 2019 01:38
|
|
|
I kind of feel like being able to talk about your plans and describe why you think you have a workable approach is an important general skill in team-based software development. It's pretty rare to have a non-trivial problem where the solution is to just dive in and start coding with no preamble; in my experience, when you do do that you tend to get large amounts of technical debt because of poorly-thought-through decisions. In other words, most of the time you should at minimum rubber-duck your plans before you start implementing them. To the extent that whiteboard interviews test that skill, then, they're pretty relevant.
|
|
#
?
Feb 4, 2019 01:45
|
|
|
raminasi posted:No, I'm trying to make the opposite point. fizzbuzz itself is in kind of a weird spot because it's so widely known, but how do we know that other problems of its class effectively serve as a dud filters? What is the evidence that fumbling with fizzbuzz-esque problems means that someone is going to be an unproductive developer? Because I've never seen anything concrete; it's always supposed to just be obvious, somehow. Fizz buzz tests either: A. Having previously read any of a number of articles explaining it. B. That the interviewee has knowledge of —a. Loops —b. Conditional statements —c. The modulus operator It wasn’t designed as a test of being a _productive_ developer; it was designed as a test of being a developer _at all_. Loops and conditionals are common in roughly all sub fields I’m aware of. The modulus operator is less universally useful, but common enough and included in all languages I’ve seen used to build useful systems.
|
|
#
?
Feb 4, 2019 01:47
|
|
|
TooMuchAbstraction posted:I kind of feel like being able to talk about your plans and describe why you think you have a workable approach is an important general skill in team-based software development. It's pretty rare to have a non-trivial problem where the solution is to just dive in and start coding with no preamble; in my experience, when you do do that you tend to get large amounts of technical debt because of poorly-thought-through decisions. In other words, most of the time you should at minimum rubber-duck your plans before you start implementing them. I’m trying to move a team to a more methodological team-oriented approach instead of just immediately shoving their first thoughts into an editor. Any advice other than that fixing the team isn’t worth the stress? Management has been sympathetic and supportive of the initiative, but lacking a bit of follow through.
|
|
#
?
Feb 4, 2019 01:53
|
|
|
leper khan posted:I’m trying to move a team to a more methodological team-oriented approach instead of just immediately shoving their first thoughts into an editor. What I've done a lot is use shared docs. Basically, "before you start this thing, please write up a doc describing your plan, and share it with the team." This could be an email I guess, but docs are easier to track and archive and make useful artifacts for demonstrating your job performance later. Writing the doc is the most important part, but having people read the docs is also pretty helpful. Fortunately in my experience if you say "hey I have this doc about my plan to do X, could you read it and let me know what you think?" most people are willing to help out, especially if they have any interest in X or it impacts their job.
|
|
#
?
Feb 4, 2019 01:58
|
|
|
leper khan posted:I’m trying to move a team to a more methodological team-oriented approach instead of just immediately shoving their first thoughts into an editor. This strategy kind-of-sort-of worked for me once: I'd push for code reviews. If you can't set up code reviews with your teammates' code, you could ask them to review your own commits. That would start to establish the team practice of code reviews. If your teammates know that their code is actually going to be _read_ and might be constructively criticized, they might suddenly be more willing to talk and think things through ahead of time.
|
|
#
?
Feb 4, 2019 02:42
|
|
|
leper khan posted:I’m trying to move a team to a more methodological team-oriented approach instead of just immediately shoving their first thoughts into an editor. Have them come up with a plan and run that plan by another developer before they start implementing it. Basically the aforementioned "write a document" answer except don’t write a document because now you have incorrect and largely unhelpful documentation sitting around once the task is complete.
|
|
#
?
Feb 4, 2019 03:47
|
|
|
i used to handwrite some design docs, tape them up to the wall, take them down once i finished and toss them. transcribe them if i really really had to. you get diagrams in handwriting for free, and nobody actually wants to update docs so the transcription is a great point to update them to the actuality of what actually exists
|
|
#
?
Feb 4, 2019 03:59
|
|
|
Thanks all for the recommends and sanity check on CtCI. I’ll give that a whirl. Also appreciate the suggestion of HackerRank. Going through a few of the Data Structure and Algorithm exercises was a good challenge but frustratingly I haven’t had to think about this kind of coding or apply these concepts in a very, very long time in my professional programming career. Is this a sign my skillset is not rich enough? Or too shallow? Am I a fraud?! Seriously though as an exercise in possible interview experiences I cannot see myself ever doing well on this kind of exam.
|
|
#
?
Feb 4, 2019 14:56
|
|
|
It just takes practice. And no, it's not at all uncommon to have a job that doesn't use the kinds of skills exercised by most interview questions. Your average software job mostly involves permuting lists, maps, sets, and structs to arrange data into various useful formats for transmission and display. The intersection between that and interview question territory can be pretty small.
|
|
#
?
Feb 4, 2019 15:26
|
|
|
New Yorp New Yorp posted:I have had great conversations about programming in interviews and then seen the candidate go on to be unable to solve FizzBuzz. Being able to bullshit convincingly is a soft skill that some people have honed, especially if they've done consulting before. Hey man, stop doxxing me.
|
|
#
?
Feb 5, 2019 14:32
|
|
|
Remote job search update Nashville recruiter emailed me this evening saying he'd like to chat for five minutes, which seems really specific. He's going to call me in the morning. I can only assume he's going to start negotiations, if they decided to turn me away he'd just email me and that would be that. Seattle in-person-with-remote-people went great, waiting to hear back if they're going to have me Skype with more management or ask me to fly out. Based on my interviews I'd be stoked to join either company, so it's going to come down to what they want to offer me. Good problem to have
|
|
#
?
Feb 6, 2019 05:20
|
|
|
Roadie posted:Fizzbuzz doesn't need a whiteboard. "Oh, you loop through, if clause modulo 3 equals zero and 5 equals zero fizzbuzz, if clause modulo 3 equals zero fizz, if clause modulo 5 equals zero buzz, else print number." At least personally, that's literally all I'd be looking for an interview with one of the real shallow fizzbuzz-type problems. So, what would you do being given this answer as an interviewer?
|
|
#
?
Feb 6, 2019 17:29
|
|
|
tortilla_chip posted:So, what would you do being given this answer as an interviewer? If it were me, I would be relieved and continue the interview. I've told this story before but we asked for a homework assignment that we didn't think was terribly complicated - iirc it was a command line app for playing rock-paper-scissors against the computer (take an input, do a random output of "rock", "paper", or "scissors", compare input and output, output "You win" or "You lose" accordingly). None of the candidates even submitted code that would run. I was telling a friend in a similar role about this and he had a similar situation. He, however, had one candidate who was like "Seriously? That's it?" and submitted a working homework assignment within the hour. There are truly a lot of people applying for programming jobs who cannot code even a little. I don't know if it's because there are no actual professional standards / certifications or if that many people just have a "fake it til you make it" attitude, but filtering out the non-coders is a very real part of the interviewing process.
|
|
#
?
Feb 6, 2019 17:55
|
|
|
Even though it doesn't work? E: Without getting too pedantic, it's important to establish what you're prioritizing with a FizzBuzz-esque question. Is it working code? Familiarity with the problem? Time to write a solution? Ability to test/validate said solution? tortilla_chip fucked around with this message at 18:22 on Feb 6, 2019 |
|
#
?
Feb 6, 2019 18:13
|
|
|
tortilla_chip posted:Even though it doesn't work?
|
|
#
?
Feb 6, 2019 18:31
|
|
|
tortilla_chip posted:So, what would you do being given this answer as an interviewer? I would tell the candidate to write actual code on a whiteboard and run some test cases. You can use any language you want and if you forget some random function that's not an issue, but if you can't write something approaching real code with correct logic then I'm going to fail you.
|
|
#
?
Feb 6, 2019 18:51
|
|
|
asur posted:You can use any language you want and if you forget some random function that's not an issue, but if you can't write something approaching real code with correct logic then I'm going to fail you. This, the whiteboard isn't an IDE and I'm not a compiler. As long as your intent is clear and your approach/concepts/understanding is sound, then you're golden. If you're unsure if you can handwave away something you've forgotten the specifics of, just ask. The fact that you ask indicates you're aware of it, and 9 times out of 10 I'll happily let you abstract it as long as it isn't the central point of the problem. You're unfortunately bound to run into some asshats out there that will nitpick your bracket and semicolon syntax, but gently caress those guys. That shouldn't be the intent, and that's not how I conduct interviews.
|
|
#
?
Feb 6, 2019 19:17
|
|
|
leper khan posted:Fizz buzz tests either: We just did a round of interviewing (for a junior-mid front-endish position) with a written and fizzbuzz section and we had at least two people who just wrote something along the lines of' "foreach loop?? // brackeds here maybe? .... { *indecipherable*" then just gave up. Both of these people were claiming 2 years JS experience. Oh and NOONE we interviewed knew the difference between POST and GET. My company is weird though because the average level of coding experience is upwards of 20 years, and getting junior coders who can hack dealing with so many crotchety graybeards and do battle with our elderly QA staff just to do some lovely frontend dev is pretty tricky. We gotta put them through their paces.
|
|
#
?
Feb 6, 2019 20:55
|
|
|
Dumb question: I've never worked with a recruiter. I heard from one today who was up front about some available positions and indicated the firm they're at, though asked me directly if I'm interested to see the postings. Is there any kind of catch to this, or just a formality for introduction?
|
|
#
?
Feb 6, 2019 21:03
|
|
|
I can't help but think this is all some elaborate troll. You guys don't actually ask FizzBuzz, do you? Or worse yet, sit there while the candidate writes out a solution? Describing the problem and having the candidate write it out might take 10 minutes, which in an hour-long interview where you also want to talk about their background and have them ask questions is a significant amount of time. And if they do end up solving it, as hopefully most candidates passing your HR screen do, it's a completely useless signal for determining whether the person is actually a good coder. There are so many better softball questions to ask, I can't help but feel anyone asking FizzBuzz shows zero value for their own time.
|
|
#
?
Feb 6, 2019 21:05
|
|
|
People will stop asking FizzBuzz when people stop failing FizzBuzz. It should be a waste of everybody's time, but here we are.
|
|
#
?
Feb 6, 2019 21:11
|
|
|
No, I'm saying it's fine that people fail FizzBuzz. But it was an exercise literally designed for testing the very bare minimum of competence in coding. If someone passes it, okay, you just spent time establishing they are at least the very bare minimum competent at coding. Why would you not want to ask a problem that is at least closer to the minimum of competence you are looking for in the position?
Pie Colony fucked around with this message at 21:18 on Feb 6, 2019 |
|
#
?
Feb 6, 2019 21:15
|
|
|
GeorgieMordor posted:Dumb question: I've never worked with a recruiter. I heard from one today who was up front about some available positions and indicated the firm they're at, though asked me directly if I'm interested to see the postings. There's no catch. The worst that can happen (and it usually does) is that you waste your time, but nobody's trying to trick you into anything. If it's an internal recruiter (i.e. someone informing you about positions at the company they work for), then definitely follow up if the positions look interesting. If it's an external, and they named the companies whose positions they're shilling outright, and the positions seem to match your background, and you're looking for a new job, then following up is probably worth the effort.
|
|
#
?
Feb 6, 2019 21:17
|
|
|
|
| # ? Apr 25, 2024 07:34 |
|
|
cynic posted:Oh and NOONE we interviewed knew the difference between POST and GET. My current CTO, unfortunately, puts all the data in the URL for POST messages. Pretty sure he doesn't know the difference either.
|
|
#
?
Feb 6, 2019 21:23
|
|
