fantasize of all the ways I can hand in my resignation.
Then 3 months go by and still no offer, lower the bar and fantasize of all the ways I can hand in my resignation - but nicer
If it’s a video or phone interview I take a shot 10 minutes before start time, loosens me up and helps me to be less in my head. Hate encouraging alcohol use to anyone, but it’s always worked for me
HAHA I wonder how many people do this. Does sound kind of useful.
Booze lowers inhibitions, that’s not always a good thing, but in a situation where you really want to impress it’s not uncommon to be stiff and visibly nervous, which is counterproductive. Smoothing that edge a bit when the situation calls for is using alcohol as a tool, just remember any tool can be dangerous if used improperly
Hate alcohol but some klonopin an hour or two before is magical. I swear it's been the reason I've gotten offers. CBD tincture or a joint with like 9:1 CBD:THC can also do wonders.
Wow this might actually really help me.
Head over to the website of the company go to the about section and read about their values. They usually list something like teamwork, communication, working autonomously, speed, or quality. You pick 2-3 of these values and that's what you talk about when they ask about yourself.
For the actual technical part it's hard to prepare for. Most people don't actually care about you being perfect but just want to see if you actually are familiar with what you said you are. So as long as you have an idea what you are talking about you will be fine.
Even if you don't know the answer, just come up with something that could work. Don't just say you don't know. Explain your train of thought as to why your solution could work. And any other ideas you might have.
I disagree with not saying "I don't know". I've interviewed people who refuse to say it and it's pretty easy to tell. And I've worked with people who don't know something and are afraid to admit it - often at the 11th hour, they have to be rescued. It's pretty aggravating IMO
Ultimately, I'd want a team member who was comfortable with admitting that and then had methods to find the answer.
I had this just the other day actually. I am in SRE and the overwhelming majority of the code I write is terraform, instructions for a Dockerfile or CI pipeline, or just some random ass bash to compile information.. I don't actually do that much coding at all and what I do end up doing is pretty rudimentary.
EVERY job interview I go on though wants to do some leetcode style code puzzle. The one I got the other day I just said to the guy, "I honestly don't know how to do this. The code I write isn't fancy or clever. It's mostly just to get things done." We worked through it together though and I understood the logic by the end but they were mostly holding my hand. What I was doing was throwing out ideas and trying to work out pros/cons with the interviewer. That was enough apparently because he green-lit me for the next round..
These type of interview questions really annoy me because they are not representative of the job in any way. In addition to work, I also have a life that does not involve computers. After putting in a 40 hour week on engineering stuff, grinding leetcode over a weekend is a hard sell.
They said "don't just say" so they mean like "I don't know but I think I've heard of that and blah" or "I'm not certain but I've worked on X which is similar so I think I could pitch in easily"
I'm sure individual interviewers have their own styles, but yeah I'm with you here. Few things are more frustrating for me during an interview than wasting 30 minutes going in circles on something because the candidate isn't being honest with me.
Our role (low level software) is going to be full of things they haven't seen before. I would rather have a candidate who can quickly identify that they don't understand something, and likewise quickly try to fill that gap so they can move on to the next thing, than have someone try to bluff their way through.
I understand that there's a level of "fake it til you make it" during interviews, but the goal of the interviewer is to get as much signal on you as a candidate as possible. Admitting you don't know something may not feel good, but then it gives the interviewer the opportunity to test you on different things that could really highlight your skills. For example, we ask questions on multithreading during our panel. If you don't know how a semaphore works, and you tell me that upfront, that gives me the opportunity to explain the concept to you and see what your process is like working through new information.
I take what they're saying as "don't just give up/refuse to answer" - it's fine to say "I don't know, but I have a guess on how I'd start/find out" and try to work through that. In a real working environment, this is more how it'd work, and if someone truly didn't know where to start, usually the co-worker would try to help, which is not always how interviews go.
How do I handshake over Zoom?? lol
A half shot of Scotch goes a long way
As long as you're interviewing remotely, yes absolutely just a little dram to take the edge off of your nerves can do wonders.
I generally read through my resume and prepare extended blurbs about the projects/responsibilities I've written about - after all, that's really all they'll know about me at first.
Then I think of more detailed things throughout my career so far that wouldn't be resume-worth, but that I'm proud of or learned from or whatever. Just to have a bit of a script for that side of things.
I make sure I've got good enough answers for the basic interview questions: biggest strength, weakness, hobbies, projects outside of work (and why I don't do them), best project, worst project and why, etc.
I try to have 2-3 questions to ask them at the end. Sometimes I don't really have many good ones, so I make a note to make some during the interview itself - asking about tech stack details is usually a good springboard. And I genuinely will make a note to myself to remember that because I know that I can flip into autopilot and not be very chatty.
The rest for me honestly is just rehearsing that basic script enough to let it flow casually so that I can spend my energy on listening and interacting with the interviewers (and being in a good headspace for any technical questions that pop up).
When I've not done that step, because of the nerves from being on the spot and with new people, I tend to come off kinda stuttery and unsure of myself. And it's all about confidence, babyyyyyyyy
*Edit: this is interviewing for a job where I'm comfortable with the roles and responsibilities. If I wasn't as confident in my abilities, I'd also spend significant time doing general studying on those parts. But I'd also be ready to say that I didn't know something yet, but I have a track record for being a fast learner, such as when I blah blah blah...
I usually skim the Gang of Four design patterns because that's something people love to ask about despite it not necessarily being something folks need to memorize for work.
I think the most important thing is to think of or look up interpersonal questions like "tell us about a time you got negative feedback" and have moments ready to talk about. If someone is asking me about HTTP verbs I know a lot off the top of my head but things like that I usually have to actively think about to remember.
I have a couple. The first one is the easiest. Absolutely not a god damn thing. I just chill. That's gotten me offers. That works for me because when I over think it or over prepare, the part of me that's actually good kind gets buried under all the shit I'm trying to remember.
I've never once had slamming leetcode shit do a god damn thing for me.
For the "culture fit" aka behavioral interviews, they almost always just ask you to describe some projects, and then poke around so to speak. Sometimes they ask dumbass questions but it's fine, it happens. This is where preparation is helpful if you're anything like me, because for me, once a project/feature is done, it's on to the next thing. I don't spend time writing down my accomplishments and I think it's gauche. But if I did, it would be very helpful for these interviews. What I've begun doing since the market has been so garbage is organizing using a note app (logseq). I make an outline with sections for types of projects or type of positive attribute the project/task would showcase. then I write myself a little story (they basically just want to hear a story that confirms what they're looking for). I have examples for being able to "hit the ground running", mentorship/leadership, and projects. For projects, my most comfortable flow is to describe the business practice before hand, the goal or reasoning behind provisioning the feature/change, the part I had in it, and the impact it had. Here's the trick. Just make it up if you don't remember. Embellish. Don't be moron because they will ask clarifying questions. for example they love to hear concrete specific numbers. They're not gonna check but it adds that extra something. Just btw make sure you're very comfortable with the embellishments you make. Like don't make up that you invented a compiler for rust that improve efficiency by %2,000. But don't diminish your own accomplishments just because every last detail isn't crystal clear to you several months or years after the fact.
I’m here because I’m interested. I’ve put in so many applications but have had no interviews despite 3 years of experience and a masters degree. Y’all let me know
Post your CV
I think you can phrase a lot of these more strongly. For example,
Provided 24-hour production support resolving issues with said system one week out of every month. Resolutions involved checking production Splunk logs, issuing bug reports, and pushing bug-fixes to production
Focus on jobs that don't do white boarding
when you say whiteboarding do you include programming tests or take home problems?
I stay away from FAANG like companies but my experience is everyone asks them. I'm curious what kind of roles don't - how can I keep an eye out for them?
I mean don't bother with jobs that ask you about esoteric programming challenges or nonsense brain teasers. All questions or take home problems should be demonstrations of your ability to work with the actual material issues at the company you're going to be working for
I agree with you. practically speaking, candidates don't have a way to tell if the problem they are solving applies to the role, especially when bringing tour skillset to a new-ish domain.
That being said, hackerrank generates a report based on if you pass or fail. Hiring managers tend to only look at the metrics in the report instead judging the candidate based on their approach to the problem. And for code that doesn't run, the metrics are nearly all 0. Not to mention there is no fucking debugger to step through the code and catch the 1 off index error that is common to make when you're under pressure.
Anyway I'm beginning to rant. There are a lot of things that should be addressed but as long as someone else can solve it and the candidate pool is large, there is no point to optimize the selection process (from a company point of view). They feel as if they are getting the best candidate because they assume better experienced == better chance of passing
Hackerrank is a huge joke for so many reasons. I would rather hire a Dev whose biggest project thus far is an arduino project with 6 stars on github than looking at someone's hacker rank
my experience with hackerrank is a company will use hackerrank platform to facilitate the online assessment - NOT look at someone "hacker rank" like you mentioned.
Candidates follows a link a company sent them and gives them an in-browser IDE to solve a problem. The platform records keystrokes, mouse events (like if you left the tab) etc etc. Then when you submit your code it is complied, executed in a sandbox, and tested with test cases. Based on which test cases pass, the execution time and memory usage, hacker rank will generate a report and fwd to the hiring team.
What I was saying in the above comment is if you had the right idea but your code didn't compile or failed the test case, it's as if you failed entirely. No hiring teams sits there and reads the code. Not even garuanteed that an engineer is reviewing your submission.
Hackerrank (to my knowledge) does not parse the code to determine your knowledge of algorithms, data structures, etc etc, it inferes it from which test cases passed and their execution time amd memory usage.
The interview starts ... the interviewer asks me "Tell me about yourself." ... I respond "Did you receive my CV? I put all important details about me ... right there. What questions do you have about my past jobs?" The interviewer encourages me again to tell him about myself, my past projects, etc. ... Me: Awkward silence. ... Me to myself: Dafuq? Should I read the CV from top to bottom OR WHAT?
I’d rather they ask me a question on something for which I’m an expert (myself) and that I can prepare for, than to fire off leetcode question.
Yeah, it’s a little bit redundant, but it can break the initial tension and get the conversation going. You can also use the time to emphasize some specific aspect of your work history that you think matches up with the job req, or shows why you actually want to work there.
If they don’t ask this question/prompt, what question would you want them to ask?
They're asking not for the info, they are asking to see how you communicate (ie "soft skills"). Your response immediately demonstrates that you do not like people, are probably a PITA to interact with, and will have a hard time collaborating with any other humans who do not think exactly like you do. The good news is that soft skills are skills, and as such they can be learned and improved on.
Yes, I know this. It took me long time to figure this out. My entire life I focused on technical skills / programming / math / logic. As I deemed them most important for the job. I was like: "Hey, if you cannot program, why do you work as programmer (you stupido)?" Only few years ago I realized that even as programmer (as opposed to sales man) you really need those "meh" soft skills. And that they are really important and I should not call them "meh". I'm very good at solving problems, improving product's performance, memory consumption, discovering and fixings bugs, security vulnerabilities. But I'm very very bad at communicating my skills and communicating with people in general. I'm not able to politely tell people that theirs idea is bad, I just say "that's stupid". And I'm mostly/sometimes right (if I'm not 100% sure, I don't say anything), but the damage caused by the way I say it is often inreversible. That post of mine about the job interview and CV was half joke and half reality. I just freeze/stutter when I'm asked something that is obvious because it is written I my CV. I'm immediately thinking "Did he not received the CV?" or "Did he not read it?" "Why the fuck is he not prepared for the call? Why are we wasting time asking me what should be obvious because I sent it in advance?" I'm more robot than human. Put me in front of problem and forget to tell me that it is impossible to solve ... and I will solve it. But easy small talk ... disaster. Communicating what the problem really was ... disaster. Communicating how I solved it ... disaster. "It was not working before and now it works fine, what the hell do you want from me now?" Yes, I'm very bad in team, in collective. I didn't know the reason why, but since few years ago I know the root of the problem. It's not that everybody around me is stupid and don't know basic stuff (what I consider basic), but me unable to communicate with other humans.
You sound like you have an inflated opinion of your programming skills and sense of not belonging / being unlike others. I may be wrong, I don't know you at all, but that's what your comments makes me think - and in that case you may want to check both that ego and self-flagellation before it bites you back.
In programming jobs, there's lot of people very good at programming but less so at social skills, it's very frequent, I see those profiles a lot at job interviews. In that situation, you have to understand that many people are like you - and even those who don't for the most part are not more or less able to do their job nor less smart. People thinking they're better at programming than the rest that way are generally rightly seen as assholes, and they most often than not are detrimental to projects, as well as despised by most.
Once you get that, you have to remember to not fall into the trap of thinking that you have the higher, more important, hard skills and that this plus your poor social skills excuses you from being nice and judging questions from other as stupid or unimportant - and at interviews they're generally prepared beforehand and have mostly deeper reasons than just the question being asked. Moreover, once you realize that many other people are actually knowing much more than you without being assholes, that might be a hard reality check.
Many people are not passionate about programming, but MANY also are, and are very competent. There's nothing special about anyone that makes him/her immune from being outed for not being nice at interviews.
One pro-tip: you can hack your own mind to work better in these situations by shifting from thinking "OMG why are he/she so stupid for doing X or Y, I would do it better" to "He/she are clearly stupid for doing X or Y, let me use my superior brainpower to guide them to achieving their goals even if they can barely understand/explain what they are trying to do".
Talk about your strengths, a brief summary of your skills, maybe very briefly talk about hobbies, that sort of stuff. By the end of my interviews I normally have an elevator pitch mostly memorized just by coincidence of saying the same thing over and over.
Show up. On time.
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
